Graphical improvements

I'm working on a few little things in Q*Bert this morning. Several of
my graphics were antialiased - that is, the used a light gradations
around their edges to make the curves look smoother. This is usually a
very good thing, but if you change background colors, or use
transparency, you get a light grey outline around the object, which
looks terrible. So I cleaned up some of my graphics.
I've also just updated the coily falling routine so that if you can
trick him off the edge of the pyramid, it clears all onscreen enemies,
and you get 700 points. You are also immune to attack when you are on
a platform now.
Next up: dealing with the death of a Q*Bert.

Q*bert progress

By the way, I haven't made too much progress recently on Q*bert. I'm happy to say that I have been answering a lot of good questions and having productive conversations about algorithms for everything from rendering laser beams to differentiating between collisions with horizontal vs. vertical obstacles constructing AI for moving about a maze.
Good stuff, student-initiated, and what they pay me for! (I suspect that somebody has written Q*bert before....)
Yes, I am just writing Q*bert for two reasons:

1. To keep me occupied a little so that I don't meddle with students during class - otherwise, I start to give unwanted advice and solving problems before the students even understand what the problems are, let alone try to figure them out! (And that's not good teaching.)
2. To model the process of writing the program like the ones they are writing, for which this blog is a help.

I have made a little bit of progress, however. I am midway through writing a function in my main class that will read a file of level data. One line per level. This will determine what colors appear on the screen, the frequency of enemy appearances, the number of colors the cube tops cycle through, and the type of cycle they have. So that's a work in progress.

python info

I just found a cool thing for Q*bert - an instructional manual for somebody who owns a coin-op version of the game. Page 7 of the pdf shows statistics about the game and graphics for the characters.

I think I will move on to the file loading portion of the game to make levels.

Platforms

A late update on the Q*bert front - yesterday, I got the platforms working - Q*bert can land on one of them and they will carry him to the top of the screen. It's working surprising smoothly. Next up - I need to create a green guy who jumps down the pyramid like the balls do and resets the cubes' colors. I also need to start thinking about how I will manage levels....

Platforms

I'm working on creating the two hovering platforms that sit on either side of the pyramid and carry Q*bert to the top of the pyramid if he jumps on them. Not too much to show for it right now, though. I am borrowing a lot from the Cubes - so that I can position the platforms the way I would a cube and so I can detect when Q*bert has landed on one.

The other thing I am doing is going back and reviewing whether I am documenting my functions. I realize that I have been a little sloppy, making up functions without putting leading comments before them to remind me what they do. And that's not setting a very good example!

... Foiled again!

If you are not familiar with the game of Q*bert, you may not know that he has a bit of a potty mouth. In the game, when he gets hit by a ball or enemy, a speech balloon appears above his head with some curse characters, and a sound file plays that is sort of a grumble. I have the visual part of it working now, when he gets hit by a ball.

I don't have the snakes getting him yet, just the balls - but it shouldn't be too hard. I wonder, though, whether the snakes will be too hard to dodge. I'll have to calibrate it a bit later.

Coily AI

I've been working a bit on making the snake, "Coily," chase Q*bert around the pyramid. I came up with an algorithm for deciding on which way the snake should jump, based on where he is and where Q*bert (his prey) is:

Deciding whether Q*bert is above or below the snake is pretty easy - I just compared row numbers. But picking between the left and right was more of a challenge. Eventually, I came up with an expression:

leftRightCriteria = coilyRow-preyRow - 2*(coilyRowPos-preyRowPos)

I found that if this "leftRightCriteria" was less than zero, then Q*bert was to the left of Coily; if it was greater than zero, then Q*bert was to the right of Coily; if it was zero, Q*bert was directly above or below Coily. So now I could apply this to the decision tree.

                

Bouncing Balls

Well, I was able to get some balls to show up on the Q*Bert grid and start bouncing down the cubes. In fact, I cranked up the drop frequency so that they fell almost every frame - it looked a little bit like water flowing. After that, though, I throttled back on the balls and let them come in multiple colors:

They now come in red, green and purple (not shown).

Next up - collisions with the balls and Q*Bert, followed by spawning other critters.

Q*Bert Graphics

I had a slow moment on Friday, so I made some pictures of Q*bert:

I've got him changing his orientation as he hops around. It's good for now - he has a very light grey outline, since the graphic was originally blended with a white background. It isn't too noticeable when he is in front of a cube, but it is fairly obvious and distracting when he is in front of the black background in the game.

I'd also like to make him seem to jump more when he is in flight. Perhaps I can make his feet point downwards more.

Next up: enemies!

hoppin' around

I've got Q*bert moving around now, which was a fun little challenge. For a while, I was expecting to have to do some complicated collision detection- search through all the cubes, detect which one(s) Q*bert is touching on screen, and narrowing them down to see which ones might be involved in a collision, and which ones Q*bert is passing "in front of."

Then I realized a few things.

1. I only need to worry about Q*bert when he is moving downwards on the screen - when his yVelocity is positive.
2. If Q*bert "knows" which cube he is jumping onto, then I only need to manage collisions with that particular cube - in fact, all other cubes are problematic distractions.
3. As far as the collision with that cube, all I need to do is figure out when Q*bert's feet have arrived at a certain height on the top face of the cube.
4. ... and all this will work on most of the other critters on the screen.

To make Q*bert jump, then, I had to give him an initial x- and y- velocity (depending on which way he was moving); set a variable, IAmMoving, to True; and let him know which Cube he was trying to land on. It took a little bit of tinkering with the starting x- and y-velocities and the downwards acceleration to find values that looked right and got him to land on the right spot.

To make him stop, I checked periodically (while he was moving) to see whether he was moving down, and whether his feet were below the middle of the top face of the cube. If so, I set IAmMoving to False. (I also corrected his position to the center of that face, so there isn't any drift over time.)

So now Q*bert (or his rectangle, at least) is hopping around.

It's Alive!!!

I've added Q*bert to the screen - isn't he darling?

(O.k., So far, he's an orange box.) You may also notice that I have shrunk the boxes vertically, so they look more regular, and I can fit more on the screen - the "regulation" seven rows....

Happy Cubes

Ok. So it didn't take too long to make a Cube class, and I'm pretty happy with it. It includes a list of colors that the cubes' tops can be and a variable that indicates which of those colors is there. The Cubes look pretty good (more after the jump):

(Looking at this picture, I wonder whether the cubes are too tall - comments welcome.)

Cube Thinking

So I drew a picture of some cubes, and I added some numbers to them in a somewhat systematic way.
(The first number is which row, and the second number is the location within the row. Since I'm a computer guy, everything starts at zero.)

And I notice a few things: (more after the jump)

Python Project

I think I will work on a project to remake the game Q*bert while my students work on their games. (Here's a clearer explanation of the rules.)There are some things about it that are sort of simple, and others that should make a nice challenge.

One of the tricks will be maintaining a grid system, so that the character is always moving at a diagonal. For instance, the top row only has one square, the second row has two, the third row has three, etc. If Q*bert is on the left square in the second row, he can move left or right down to the third row, or up and to the right to the top row. He can't move up and to the left, because that is off the world, and he can't move to the right-hand cell in his row, because he only moves diagonally. So how will I be able to keep track of where Q*bert is, and where he is allowed to go?

I think I will need classes for Q*bert, the cubes, a scoreboard, one for each type of monster, the balls (generic) and the platforms.

I'll need a list of objects to draw, objects to animate, enemies, and platforms

Here are my goals:

1. Generate the cubes
2. Create Q*Bert and have him appear
3. Let the user control Q*bert around the cubes
4. Let Q*Bert change the color of the cubes
5. Create a scoreboard
6. Make the balls fall down
7. Make Q*bert die (curse!) if he is hit by a purple or red ball.
8. Make Coily and move him randomly
9. Make Coily move towards Q*bert
10. Let Q*Bert land on/ ride a platform
11. Let Coily fall off if Q*bert is on a platform
12. Create Slick & Sam
13. Create Ugg & Wrong Way
14. Add Sounds & Multi-levels