This is a read-only archive of the old Scratch 1.x Forums.
Try searching the current Scratch discussion forums.

#1 2007-09-23 13:43:03

jumpstart
Scratcher
Registered: 2007-05-29
Posts: 14

Understanding how games work

Hi, all,

In our lab, which is K-12, many children want to make games in Scratch. Unfortunately, games are very challenging to build.

I usually start by having the child download a game from the Web site that they're interested in and then modify it. This strategy, called "modding," is widely used by game educators. But we often hit a ceiling with it - particularly when it comes to understanding how sprites "know" what to do in a game. I assume this gets into the "artificial intelligence" that robot-like characters are programmed with - but my understanding of this topic is pretty minimal.

Anybody have a terrific strategy for overcoming some of these hurdles with learning about games?

Best,

Gary Greenberg
Middletown, Ohio

Offline

 

#2 2007-09-23 20:05:23

archmage
Scratcher
Registered: 2007-05-18
Posts: 1000+

Re: Understanding how games work

jumpstart wrote:

But we often hit a ceiling with it - particularly when it comes to understanding how sprites "know" what to do in a game. I assume this gets into the "artificial intelligence" that robot-like characters are programmed with - but my understanding of this topic is pretty minimal.

Sprites? Are you referring to to user controlled sprites or computer controlled sprites? Because player controlled sprites usually have no A.I. Player controlled sprites actions depend on the user's input. Also most A.I. controlled sprites in scratch are very simple and usually comprise of a few blocks of code.

An example of an enemy A.I. code would be something like this:

<when green flag clicked>
<forever>
//if the enemy is to the left of player move left
<if><( <{ playerx }> <>> x position )>
<change x by(- 5)
//if the enemy is not left of the player move right
<else>
<change x by( 5)

Last edited by archmage (2007-09-23 20:05:51)


Hi, I am Archmage coder extraordinaire. I do Scratch,pascal,java,php,html, AS2 and AS3. Leave me a message if you want coding advice. Also check out my personal website, lots of good stuff about web development, Flash, and Scratch (v1 and v2) !

Offline

 

#3 2007-09-24 08:09:40

EdnaC
Scratcher
Registered: 2007-08-28
Posts: 100+

Re: Understanding how games work

AI can vary from simple to complex.  One simple approach that you'll see a lot is "point toward" (player's sprite) and move.  This makes for a predictable enemy, but is easy to do and works well.  If you remember "Asteroids Deluxe", the enemy ships that resulted from hitting a "cluster" behaved that way.  Mixed in with the asteroids, and other enemies that were more or less "random", this was pretty cool, but if nothing else was going on it would have been boring.

The AI in "StealthFighter" http://scratch.mit.edu/projects/EdnaC/33613 (a game with two airplanes shooting missiles at each other), had to be more along the lines of "what would I do?" to look realistic.  If the enemy plane always turned toward you, it would be predictable and easy to "shoot down".  So the question becomes, "how do I make the enemy appear to act intelligently with as few rules as possible?"   If you examine what the "Stealth" plane does in one player mode, you'll find something like:

If the other plane is in front of me (within some range), turn toward it.
If the other plane is close and in front (within a narrower range), shoot at it.
If the other plane is right behind me (within some range of angles) and far away, turn toward it.
If the other plane is close and behind me, do something random to try to get away.
If the other plane shoots, do something random.
Otherwise, fly straight.

This isn't really "intelligent", and doesn't always result in the best strategy, but it looks like the other plane is being pretty smart, and "looks" is what counts.  ("Looks is what counts" is good advice in general when it comes to games, the "physics" doesn't need to be correct either, it just has to "look" right.)  So, to finally attempt an answer: When "designing" AI, think about how a human player might act in the various situations that might arise, and define rules accordingly.  You don't want "AI" that is unbeatable, and you don't want "AI" that is totally predictable, so a little bit of "Random" mixed in when the "situation" doesn't have a clear cut "rule" is a good idea too.

Please give the StealthFighter a play, then have a look at the "code".  I'd like to know what you think.

-Mr Ed

Offline

 

#4 2007-09-24 16:42:15

jumpstart
Scratcher
Registered: 2007-05-29
Posts: 14

Re: Understanding how games work

Thanks Archmage and EdnaC.:

I was referring mostly to computer-controlled sprites, but anything more I can learn about user-controlled really helps too. Appreciate the examples from both of you. (I will get to StealthFighter soon...)

What do you both find the most difficult to explain to children about how games work?

Best,

Gary
Jump Start

Offline

 

#5 2007-09-25 09:07:19

EdnaC
Scratcher
Registered: 2007-08-28
Posts: 100+

Re: Understanding how games work

There are a couple of things that are tough for new programmers.  First is coming to the realization that you (the programmer) have to make things happen.  There isn't a "Keep Score" block that you can drag out and drop in place, or a "Control Sprite Movement in Just the Way I Imagine it Should Be" block that will accept user input and do just what you want.  Follow this thread for a great example: http://scratch.mit.edu/forums/viewtopic … 8124#p8124

The other stumbling block is that there are many different ways to write the program.  Some may be "better", because they are a bit more "elegant" or require fewer variables, or whatever, but a LOT of different approaches will work.  For someone new to programming (or designing machines or presenting information, etc.) all of the possible choices can present an overwhelming decision.  Sometimes you just have to dive in and try one and not be afraid to throw away your work and try something different.

With Scratch, you can try something, and if it's "close" but not quite what you want, you can just move the script down and out of the way, then disconnect it from the "Start Hat".  Then try a new approach.

You might try starting with a very simple game idea:  Have Students choose a Sprite they like, and get it moving up and down on the edge of the screen.  Choose another Sprite and get it to move along the opposite edge, responding to user input.  Use spacebar (or whatever) to have the user Sprite move to the opposide edge (or "throw" a third Spite).  Then add looking for a "collision".  Then add scoring.  Then add a time limit.  Some searching in the galleries will turn up examples of this.

Offline

 

#6 2007-11-29 07:35:02

jumpstart
Scratcher
Registered: 2007-05-29
Posts: 14

Re: Understanding how games work

Hi, EdnaC,

RE: Programming. Thanks for the thoughts. Your suggestion about moving the code "out of the way" and starting fresh is just the kind of practical thing I need. I will check out the thread you posted.

Best,

Gary
Middletown, OH

Offline

 

#7 2007-12-28 06:03:19

redware
Scratcher
Registered: 2007-05-21
Posts: 92

Re: Understanding how games work

I have documented a simple game for scratch novices. There is quite a lot to it but individually each stage is straightforward. Please try it out and let me know if it works. Note that the documentation is designed for the trainer or older kids to be able to help novices build the game.

http://scratch.mit.edu/forums/viewtopic.php?id=2709

Stamati Crook
http://www.redware.com/scratch

Offline

 

Board footer