Scratch

Pacman, then!

Also, Pac-Mac AIs might be cool; each AI controls a Pac-Man and we let 'em loose on a big 10x10 maze with some ghosts and a coin on each empty square. When all coins are collected (or all Pac-Men ghost-eaten), the Pac-Man with the most coins wins. That will need only one round, needs a very basic framework, and is rather cool in my opinion. What do you think of that?

I think you might need a bigger maze, depending on how many players you get... Can the players hurt each other?

And I disagree that it's very basic... Hex was a lot simpler by comparison 

MoreGamesNow wrote:

I found two people at my school playing a different variant that I thought was really cool.  The board was the same as yours, but, when each player went on a square, the opponent had to make a move on a corresponding game.  Er, that didn't make sense, diagram time:

1  2  3
4  5  6
7  8  9

If someone puts an "X" in square 3 of game 1, the opponent (who goes next) has to make their next move in game 3.  If they play 6:3, the original player has to make their next move in game 6.  This means that, when you make a move, you have to look at what options that opens for your opponent.  It also means that, if your opponent can force a win on one board, you can still win/tie the game by simply avoiding that board.

This game sounds so cool... 
But let's agree on python for speed of writing&executing, ok?

sparks wrote:

roijac wrote:

But let's agree on python for speed of writing&executing, ok?

I think the main reason that Javascript was chosen for this tournament is that a lot of people know at least the basics of it, if not more. Python, whilst still widely used is still less known on Scratch than Javascript it seems to me. Also, it requires no software installation to take part.

What Sparks said; more people know it, simply. Although I'm with you on Python being faster to write...

And JS is pretty quick nowadays; particularly if you use the right JS engine 

Last edited by blob8108 (2012-05-31 16:45:35)

Also, using my ninja-skills, I can allow coding in the following languages:
JS
Python
Objective-C
BYOB

Using remote sensor connections and sockets. But I'd rather have everyone code in JS. 

No, sorry.

If we've decided on PacMan (I'm assuming we have for now, if anyone disagrees please post now or forever hold your peace) I should be done with a basic framework in JS by this week; all I need is to assign "PACMAN" objects and a "MAP" array, then pass those as parameters to your motion scripts. 

EDIT: That was my 1900th post. 

Last edited by Hardmath123 (2012-06-03 06:35:36)

amcerbu wrote:

How are you going to make the map fair?  Will it be symmetrical? 

Also, I've had a few ideas for the ghosts (that I was thinking about the other day): 
You build a ghost class, and instantiate some number of ghost objects.  Each instance of the ghost class has a method that can calculate the path from the ghost's current position to each of the four "PacMen."  A ghost chooses to target the nearest PacMan. 

But here's the catch: a ghost can't ever make a 180-degree turn while it's in a corridor (it can if it "runs into a wall").  This would prevent the ghost from sitting still or moving quickly back and forth on the opposite side of a barrier with one of the PacMen.  So, the ghost has to keep going straight until it comes to a place where it can turn left or right.  This is legal.  However, the ghost can only turn back the direction it was coming from (180 degrees) when it reaches a wall perpendicular to the direction it was travelling in before. 

This will also improve performance, since the program won't have to call the computationally expensive pathfinding algorithm as often. 

I hope that made sense.

Seriously, can I at least code the ghosts on my own, without ideas from everyone? 

Ghosts will be special types of cells on the (symmetrical) grid, along with Wall and Empty.

amcerbu wrote:

Okay, sorry.

No problem, I'm usually receptive to new opinions. It's when those opinions are better than mine that I begin to get upset... 

blob8108 wrote:

Hardmath123 wrote:

amcerbu wrote:

Okay, sorry.

No problem, I'm usually receptive to new opinions. It's when those opinions are better than mine that I begin to get upset... 

So what you're saying is you like being able to ignore other people's opinions, because they're bad... 

...

That's your opinion. 

Last edited by Hardmath123 (2012-06-06 10:44:44)

amcerbu wrote:

I've gotten all the physics stuff to work.  What I came here to ask: does anyone have any tips on elegant ways of programming AI behavior?  The ComputerPaddle is a static class with a few methods: PhysicsConstraints(), SetDestination(), etc.  The Puck and PlayerPaddle are also also public static classes (with most members public).

Cool stuff! Do you mean the interface to the AI code, or the AI itself?

I use Python/Pygame; but I think the design ideas are non-language-specific. For the interface, I have an abstracted Controller class with subclasses for keyboard control, and potentially joysticks, etc, in future. The class handles things like key-to-control mappings (so the user can change the keys used for each action; but that's a separate issue).

All the controller classes share the same interface: I have get_axis() to return x,y values and get_buttons() to return a list of True/False pressed values for each button (currently only a single "fire" button). (I should probably change this to just be a single method...) Each Player object gets a Controller (subclass) instance and uses these methods to get controller input and use it in the physics stuff.

For an AI, I just make a new Controller subclass, AIController. The controller subclass gets a reference to the Player object which it can use to look up the current position, other objects, etc, to make the decision of which controls to return. The advantage of this implementation is you guarantee that the AIs have the same physics model, so it's completely fair.

For programming the actual behaviour itself; that's up to you, as it's very dependent on the game. I hope some of that is interesting/useful, anyhow 

amcerbu wrote:

Thanks!  I'll take your advice on implementing control input!  I may upload the project to some site when I've finished.  Since this competition is at a standstill, it might be neat to do an Airhockey AI programming challenge...

I tried a long while ago... (please excuse the noobishness).

Dunno.