Need some help implementing interactive TicTacToe game

[SnShine]

Hey everyone,

I am trying to implement interactive TTT game and stuck at a problem. I have completed till this far (Taking user input by clicking on blocks).

You can view the source at https://github.com/SnShine/aima-python/commits/addInteractiveTTT (last three commits).
Is there any way to execute a python method after getting user_input from html onclick event. I can execute python commands from Python.notebook.kernel but unable to pass methods here.

Any idea how to do it? TIA

[reachtarunhere]

Yes @SnShine my code exactly solves that problem. There are two issues that need to be handled for this. I can surely help you in this once @norvig can tell me if what I have done is ok/useful or not. Otherwise it will be a waste of effort for both of us.

[SnShine]

Yeah, it's alright. I haven't played with your implementation of interactive blocks yesterday. Now that I have installed ipythonblocks, I figured it out.
And once interactive blocks is finalised by Norvig, we can build TTTgrid, searching algos and stuff like that on interactive blocks.

[reachtarunhere]

@SnShine yeah that would be great. I will try to add a couple of more demos today. They should serve as good examples if we are going to use interactive blocks in the future. Also there are a couple of thing I need to do so as to get the agents working. So I'll try do all this asap.

[Chipe1]

@reachtarunhere How do you plan to implement structures that are not grids. Can we use ipythonblocks to show graphs like the map of Romania given in the book and do dfs on it.

[SnShine]

@Chipe1 I think we can't use ipythonblocks to represent graphs like Romania. If we are visualising that graph, we need have places separated to each other to scale. We can't do that with ipythonblocks. We can always use graphvix or some other library if we want to implement graphs like that. But, do we need to interactive with Romania map? We can have visuals for different searching algorithms, but there is no need of interact with the map/graph itself.

[norvig]

I have a question about ipythonblocks: I know I can have a grid of blocks, and specify colors. But I think we'll need to be able to put text labels on blocks for many applications, and for other applications, we'd want each block to be a canvas, or at least have the option of having a block display an image. I don't think ipythonblocks can do that? If not, it might be better to find a package that can.

[norvig]

@SnShine makes a good comment: I think there are three types of visualizations:

• Static: still pictures, generated by a program, like a picture of a graph.
• Animations: a series of static picture snapshots, with buttons for play/stop/rewind, but no interaction with the content, like the sequence of a state space search.
• Interactions: an animation, but the user can change what happens, like a tic-tac-toe game.

It would be nice if one package enables all three, but not necessary.

[norvig]

@reachtarunhere I'm not sure what "once interactive blocks is finalised by Norvig" means -- is there something you want me to look at? I don't see a pull request.

[reachtarunhere]

@norvig by making some modifications it is possible to place images,text inside the grid cells. I am working on that right now and will comment here when that is ready. By "once interactiveblocks if finalized by Norvig" I meant your opinion on utility of interactiveblocks for AIMA code. I wanted you to give a look to the demo I made here https://github.com/reachtarunhere/interactiveblocks that tries to present a solution for interactions in relation to our discussion on the original IPython Notebook Issue #75 . The idea is that the user need not deal with JS to get this working.

[reachtarunhere]

@norvig for static images and animations we don't require a separate package. I am not sure if there is some plugin for IPy that has the play pause rewind options but I'll give it a look. Also for clarification "interactiveblocks" in above conversation refers to the implementation which I have linked above.

[norvig]

@reachtarunhere I do like the interactiveblocks! The Lights Out game demonstrates most of what we want to be able to do. But I'm still a little confused. First, there seems to be too many names: CustomBlock, CustomGrid, BlockGrid, GridWorld -- it is not clear what's what. I'm also not sure that we gain a lot by building on ipythonblocks -- if you have to override most of the functionality with custom stuff, would it be just as easy to implement everything in intractiveblocks and not use ipythonblocks at all? I'm not sure.

As I understand it, the way you have things now, there is a grid of background blocks, and then you can add things to the grid. Maybe it would be conceptually simpler if there was no distinction between background and Things? I'm thinking there should be an overall background for the whole grid (a color or a jpg/png image), and then if you want some cells to be green for grass and others blue for water, say, you add a 'Grass' or 'Water' thing to the location.

Also, while the AIMA Environment class may be in flux, and could be changed as needed, I think we need a good architecture for how to separate out the graphical parts from the running-the-environment part. Usually, one does this with a MVC framework, where there is a model (like the Environment class) and a view (like the blocks of some form) but we don't try to put both things in one class.

There are a few typos in GridWorld where you have self.thing but you meant self.things. I fixed those, and I tried my_grid.add_thing(Thing(2, 3, 'Circle'), 2, 3). Using my_grid.list_things_at(2, 3)[0] I see that it did indeed add a circle (a big 500x500 circle), but my_grid.show() does not display the circle.

Also: I think GridWorld and other objects should have __str__ / __repr__ methods that do a .show(), the wayBlockGrid` does..

[norvig]

Some more things from my wish list:

• I think for now it is fine to have GridWorld, but we should also think about ContinuousWorld -- it would be nice if all the methods work the same, but in ContinuousWorld, things can be placed with sub-block resolution.
• I worry a little about the _THINGS dict. I guess it is ok as long as it is extensible; users can add their own shapes. Really this is _SHAPES or _STYLES, not _THINGS.
• I would like to have shape/style rules that take neighboring cells into account. For example, I want to be able to say that a cell is a wall, but not be bound to having the wall fill the entire block. If there is a row of three horizontal WALL cells, then I want the wall to be drawn as a horizontal line, maybe 20% of the height of a block, that extends from about the middle of the first block, all the way through the second, and to the middle of the third. But if, say, there is another wall directly above the first cell, then the wall in the first cell should be drawn as an "L" shape that connects the wall above and the wall to the right.

[reachtarunhere]

@norvig Thanks for the elaborate reply. Below I have addressed some of the points raised by you:

there seems to be too many names

Agreed. My idea was only to expose GridWorld & Thing to the people using this code. I have another question. Do we want our target audience to go through this code and understand it? I have so far treated this is an aid that people only need to use directly.

not use ipythonblocks at all?

I think we can move away from ipythonblocks. I only read the code and used it as I was getting acquainted with the idea of representing python objects as HTML. Also if we plan to have common methods for both continuous and discrete it might actually be better to move away from ipythonblocks and work on implementing a continuous case (canvas?) and make it discrete.

Maybe it would be conceptually simpler if there was no distinction between background and Things? -

There is a caveat to this when it comes to dealing with agents. In the original notebook discussion you mentioned chess. This is an example where we need to use the drag like interaction (this was going to be the last demo in the yet unimplemented part of the notebook.) Drag and Drop with backgrounds can be very difficult to handle. Still, I will look into this if there is some other way that I might have missed. Maybe we can keep the agents separate and the rest of the environment can be background.

MVC framework

This is definitely important. One idea that comes to my mind can be doing something like.

class View:
    def __init__(self, model):
        self.model = model

class Model:
    def __init__(self):
        self.representation = View(self)

This would ensure both objects can access each other at all times. This is the first thing that came to my mind. I will do some reading and add if I find some better way.

Typos & Bugs

The code except that of interaction was not supposed to work. I should have made this clear earlier. Thank You for pointing the mistakes. Regarding the big circle it is because it sizes itself 75% of the parent. So if we directly render, it tends to occupy most of the output box width wise. I will set max width property to handle this.

we should also think about ContinuousWorld

If we want all the methods to work the same we should probably first focus on the continuous world part. Can you please add more on this specially in terms of kind of things you want working in the continuous world. Specific examples would be of great help. This way it would be easier for me to make the best choice in terms of what we can use.

I worry a little about the _THINGS dict.

Yes, I will rename it. It will be kept extensible in whatever final code I come up with.

But if, say, there is another wall directly above the first cell, then the wall in the first cell should be drawn as an "L" shape that connects the wall above and the wall to the right.

I was not able to understand this one completely.

For now I will work on implementing a continuous example . Once I am clear with the requirements and how we plan to go with the MVC idea I will try to send a PR. Also where should code for the worlds go?

[SnShine]

But if, say, there is another wall directly above the first cell, then the wall in the first cell should be drawn as an "L" shape that connects the wall above and the wall to the right.

• Let's say we have two walls in a row. How are we gonna show? Represent it as a straight line (20% thickness of block) starting from the centre of first block to the centre of second block.
• Now if we add wall to the third block in the same row, the wall in the second block extends from end-to-end, making it as that extends from about the middle of the first block, all the way through the second, and to the middle of the third.
• Now if we add another wall([1, 1]) above the first block (walls in [1,1],[2,1],[2,2],[2,3]), the wall in the block [2,1] should look like the letter "L" to connect the block above it and he block to the right of it.

[norvig]

@SnShine : also, I think we don't need fine control over red/green/blue color values. I can't think of an application where we will want to, say, vary the blue values from 0 to 255 continuously. So i propose that the API not have red, green, blue parameters, but rather have one color parameter, which we expect to be a color name, like "red", but it can also be a str like "#ffccaa". I think that's all we'll ever need.