capital_v0.0

Posted by zen on August 20th, 2008 filed in 3D, Scratch, Strategy
Comment now »

SEE BELOW FOR DEVELOPMENT NOTES

L/R Arrow Keys = Change Facing
Up Arrow Key = Thrust Forward
Down Arrow Key = Brake/Reverse Thrust
Space Bar = Fire Cannon
Z Key = Warp

You are the captain of a large attack cruiser. You have just arrived out of hyperlightspeedgigawarpspace
space and are surprise attacked by some bad guys in another attack cruiser. Regardless of moral or social implications, you have to fight your way out.

Fire your guns at the Enemy Ship and shoot down his heat seaking missiles.

Kill the enemy ship for an extra bonus.

Use the lidar screen on the bottom of the frame to find the bad guys and their missles. Use the armour readings on the left to keep track of your lifeline. You are on top. The nearest bad guy is on the bottom.

Kick buttock and take names.

The more you fly without getting hit, the higher your score. If your armour drops to 0, GAME OVER man!

Extra points if you can convince the missile to hit the Enemy Ship.

A good tiled scrolling background example with some simple 2D motion dynamics.

Further gameplay later…

Making Capital by jmgibson

First I’d like to thank you for your interest. Its an appreciated and heartfelt compliment.

The reason Capital happened was that I was seeing a lot of discussion on the Scratch site about not being able to do scrolling backgrounds. Brad, a coworker and friend of mine was working out a different Scratch game of his and pointed out the issue to me. And I said to myself, "Self, we’ve done about as many systems for scrolling backgrounds as McDonalds has served hamburgers so let’s give it a shot and work out the details." And I agreed with myself with "Yes and maybe it will help someone later." So given that inspiration, me (who was a late-comer to the conversation), myself, and I got started on the viewing system with the rough idea of a video game to come later. That’s why its named Capital_v0.0, as the intention was to do just a scrolling example first and then move into gameplay, and the v0.0 just stuck.

The design of the scroller was inspired by the upright video games of the 1970’s and 1980’s; thus the rich and overbright color scheme. My favourite game design of that era was Sinistar, which fit into the rough framework of how I wanted the viewing system to work. Actually most of Capital was inspired by the Sinistar concept of "collect enough resources to kill the bad guy over and over again." I just haven’t gotten to the "collection" part yet as people seem to be enjoying themselves regardless.

Here is the order of the system’s creation just so you can see the topics we’ll cover, historically speaking:

Viewing and the tiling backgounds
Event synchronization
World Coordinate Space
Ship motion and movement controls
Making shipMain’s Graphics
Entering the game
Making the background tiles wrap
Missile motion and 2D inertial dynamics
The bad guy and his control "logic"
Getting hit by the missile
Shooting the missile
Shooting the bad guy
The sounds and music
Warp control
Lidar Display
Game over and intro screens

Viewing and the Tiling Backgounds

This is where I started. First know that you can’t do the obvious thing and display a larger-than-the-view background image on the Stage object. That makes sense for the original intentions of Scratch but complicates our system. That means that if we want to use bitmap imagery as our scroller source we have to use sprites for it.

So first I tried using a very very large sprite. But Scratch wouldn’t let the image be larger than the viewport. BUT I discovered that you were allowed to translate a smaller image OFF the viewport. So I diced up my original background image into sixteen tiles, each of which would fit well inside the viewport, and made them all sprites: bg_0_0 to bg_3_3 where the numbers are the 2D indices to the tile position.

Now THAT is inefficient: drawing sixteen large sprites every single frame. So I added a conditional in each sprite’s self-handler that hides the tile if it gets too far away from the center of the view.

Event Synchronization

Next I wanted to flyover the tiles in the Sprite engine to see how well they drew so I had to build a videogame-like event loop. So when the game starts the Stage is in charge of directing the whole deal. It should be the only place you’ll see an "On-Flag" event handler in the whole of Capital. That (eventually) generates a "start" event which preps the viewport viewing system, initializes all the sprites and on the Stage goes into a "forever" event loop that broadcasts a sync’d "update" event to all the Sprites and manages the viewport. At the end of each update it waits a tiny amount of time in order for all the asynchronous event handlers (playing sounds, handling key-presses, "hit" animations, that sort of thing) time to hopefully catch up. This forever loop terminates when the sim part of the game exits exits with anything that broadcasts an "end" event.

Event syncing will be very important later onces a ton of stuff starts happening "at-once" so we may as well build the event loop here.

World Coordinate Space

Here is where I stopped using the viewport coordinate space for viewing (http://en.wikipedia.org/wiki/Coordinate_space) and started using a "world" definition. On the first frame of the simulation the two share the same origin. That is the viewport’s [x=0,y=0] is coindicent with the game simulation’s [0,0]. After that, though they differ. For those of us not familiar with the freedom that representing viewing and motion with different coordinate spaces here is the essense of what happens.

The center of your viewport coordinate space is always [0,0] and always right at the center of the rectangle representing your viewport, just as Scratch would have it. A world coordinate space is differnt. This is one where [0,0] is just where the game starts. But events can be taking place far away from that "origin". And since you want to "see" those events you have to drag the area of the world, kicking and screaming, back in front of the viewport. I don’t really want to go into what would happen if we were attempting to represent rotating, skewing or scaling worlds but for a 2D translation (motion) engine like this one, putting one space (world) back into the space of another (the viewport) its a simple subtraction of the X and Y of the center of where we want to look in the world from any world space coordinate we want to represent.

e.g. If my ship is at [X,Y] = [100,1300] and I want my viewpoint to be looking near the ship at ViewCenter = [101,1290], my viewport space coordinate for the ship is [100,1300] - [101,1290] = [-1, 10] which, tada, is near the center of the viewport.

Once you have this working your hands are virtually free. All you have to do is keep track of where you want to be looking in the world space separately than the view space and the world events. The "camera", then, or the View Center is now sort of like its own sprite but represents not what you see but where you look in the world to see other stuff.

You’ll notice that when you enter the game or when you warp, the ViewCenter starts to play a game of catchup with the ship. The ship and viewCenter positions are different and though I deliberately try to follow the ship, I wanted the viewCenter to act like a cameraman at a sports event: always trying to catch up to and center the action, but never quite doing it. The way this happens is I make the ship world coordinates (from now on I’ll only be talking terms of world coordinates) global variables and the Screen object figures out the difference between the ship coordinates and the viewCenter coordinates. Then it moves the viewCenter 0.15 (15 percent) of the way to the ship. If the ship stays still long enough the viewCenter will always eventually catch up to it.

Every sprite in the game, except for the lidar and score displays, is expressed in world coordinates and is transformed back into viewport space as a final, secondary process during its update.

Ship Motion and Movement Controls

Here is where I ran into another problem that required a creative solution. There’s no trig or linear algebra built into Scratch. This means that even though you know your facing in the world, can’t effectively record your velocity or acceleration in X and Y separately factoring in your facing. So though you can change your angular velocity on your sprite pretty easily by keeping track of its rotational velocity and adding that to the facing angle on every update, if you try to try to accelerate along that facing there isn’t an obvious way to decide what your new velocities and positions are in world space X and Y. This was trillian’s first question. How am I getting world space forward and revere thrust.

Fortunately there is linear vector algebra built into Scratch. It is hidden from you but its there. When you "move 10 steps" internally in viewport space, Scratch is converting your sprite’s facing to a vector and scaling that vector to be the length of the amount by which you want to move your sprite foward. We can take advantage of that. I use that behaviour. Let’s say I want to compute a new velocity in X and Y from an old velocity, a facing and a certain amount of thrust (or acceleration):

1) Hide your sprite
2) Move your sprite to Scratch’s (the viewport’s) origin [0,0].
2) Face your sprite in the direction you want to thrust
3) Move your sprite (foward is just positive amounts and backward is just negative amounts) by the amount that you want to accelerate.
4) The sprite’s Scratch X and Y are now your new acceleration values. They don’t mean anything else so store them and move on.
5) Add these X and Y to your existing sprite’s X and Y velocity that you can store in either global or spite-local variables. That’s your new componentized (X and Y) velocity.

Now when you update the position of your ship in world space you just add the resulting velocity to the world position variables of the ship during the update to get your new position.

After all of the above, to make the "coasting to a stop" behaviour I scale down all velocities to 0.95 of their initial values for each update. This is of course not the normal behaviour of space ships, more the behaviour of a ship in a resistant medium, like a boat in water. But its more fun this way. And hey, its my game and I like it this way. Phttt!

The above technique is most-represented by the Missile sprite.

Making shipMain’s Graphics

I am an expert Houdini user. shipMain took about 20 minutes to model, texture and light for both standard flight lighting frames and for autocannon fire lighting in Houdini and Mantra. I used the free "Appretice" full-featured version so I had to roto (erase) out the Houdini watermark image from the sprite graphics after the fact. I did the same with the explosion sprite animation and sometimes you will get glimpses of where you can see part of the H from Houdini left over in the bigger parts of the explosion.

Entering the Game

By now I was representing all of the motion of the ship with facing velocity and positional velocity so to bring the ship into the game (and eventually to warp) all I had to do was generate a fun random velocity for both and let the ship do what the ship was going to do in the simulation. This applies to both shipMan and the bad guy, shipEnemy.

Making the Background Tiles Wrap

Here is a forum link to a Photoshop script I set up for dicing up tiles and a rough description what I did here: (link to forums)

Once you bring the tiles in you treat them as the other sprites in world space. The diffence is that they are only shown (not hidden) when they are near the viewCenter and they only move when they are outside the viewing locale. And the only reason they move is so that you have a continuous and infinite image. If your image only covered world [-500,-500] to [500,500] and your ship was at world [1000,500] you would be over a black background. But if your ship were travelling to [1000,500] and you wanted to put a background there, you’d want to go grab the appropriate background for that area and put it there before the ship arrived. This I do during the update for each tile. I use a modulus on the world space coordiates of the viewCenter to find out, regardless of map iteration, what part of the whole map I’m over for that iteration, then I subtract off the coordinates of the begining of that map iteration in world space. That tells me where each tile is in world space for that viewing locale. And that is where they are displayed for that update.

Missile Motion and 2D Inertial Dynamics

As above all the dynamics of the missile are represented with componentized velocities. It, however does not use a facing velocity. Instead it just faces its target…sort of. What it really does is put itself into the space of its targe ship. That is, a space defined by the ship being at [0,0]. It then predicts which direction and how much it needs to thrust to compensate for its own velocity by moving itself (without chaging its world space position quite yet) in that ship space by its velocity. That tells it where its going to be relative to the ship on the next update. From THAT position it faces the ship at [0,0] and thrusts by a fraction of the distance between itself and the ship, shipMain. This way its always trying to thrust such that on the next update it will steer closer to its target.

The Bad Guy and His Control "Logic"

shipEnemy is terribly, embarrassingly simple. He takes advantage of the fact that the player is distracted by the missile and that he is its launch device which makes it look like he has enough confidence not to just get the heck out of your way when you come flying in, autocannon blazing. Nope, what he really does is what the player does. Whenever the player hits a key, shipEnemy hits the same key 2 seconds later with slightly different acceleration characteristics. Lame but effective. Why does this work? 1) The motion LOOKs intelligent. 2) The missile distracts the player from what is really happening and 3) the resulting motion is different because its a different ship with different motion properties.

Getting Hit by the Missile
Shooting the Missile
Shooting the Bad Guy

These are basically the same. Each shot and the missile are independent Spites. The autocannon shots move in a straight line in world space and the missile motion is discussed above. When the shipMain sees that it is within some small distance from the missile it fires off a "missleHit" broadcast which the missile Sprite picks up and updates the Score and prepares itself to fire again. The explosion sprite also gets the "missileHit" broadcast and starts animating at a random size and rotation at a fixed position in world space. The explosion sprite is separate because it can be on the screen and have different motion at the same time as anything that can cause an explosion. We get away with one explosion for the whole game. Cheap, of me, I know, but it works.

The Sounds and Music

One of my favourite things is sound design. I love the sounds. For this I ripped off a couple of acquaintances of mine who work on Battlestar Galactica. You can’t hear much of Bear’s music, other than the percussion but all the sound effects are taken from the pilot reel of Battlestar Galactica. There is a loop of sound effects and music that constantly plays during the sim. Other than that I play the Viper guns sound effect any time the autocannon is fired, the Viper launch sounds for the warp sound, the shuttle steering blasts for turns, another Viper launch for engine thrusts and a generic explosion sound for all explosions.

Warp Control

Warping is just the same thing that happens when you restart the game but with a random offset position relative to the current position and with a few fun graphics effects as it leaves its current position. The viewport’s catching up to the new position of the ship adds a lot of drama to this effect and basically sells the whole idea. The effect is polished off with a cool "engine up" sound effect.

Lidar Display (a.k.a. the radar at the bottom)

Again, with everything stored and sim’d in world space this is SUPER SIMPLE. You just draw tiny sprites with locator lines over everything else in a new space which we can call "lidar" space. This is a space defined by placing the center of its view at shipMain’s position and scaling that space down to fit most useful data onto the lidar view area. Each lidar sprite is a mirror of its mirror in the world and starts each update by using its coordinates. Everything, including the lidar frame graphics, is shifted down out of your primary viewport’s frame center, down to the bottom-ish part of the viewport.

Game over and intro screens

Lastly, we keep track of the staging state by using global variables to remember if we are currently "running" the simulation and if we "canStart", as in start the simulation with the ’s’ key. The "game over" graphics (which are crap right now and will change) and the intro screen are the same sprite as they are just different states of the same progression of staging. But I let the sim continue to run during the game over stage so that the music and sound effects can finish and the game doesn’t have a jarring conclusion, animation wise, but instead coasts naturally to a stop. Otherwise we just use broadcast event to traverse each stage in the staging processes.

3D cube test

Posted by zen on August 19th, 2008 filed in 3D, Scratch
Comment now »

Move the cursor near the center of the screen, then move around slowly.

I was trying for a real time shaded cube.

This method is not practical since it basically will only work on cubes, and it’s slow.
But it was fun to make.

It might be possible to speed it up some. Feel free to change/fix it.

Challenge: Try to figure out how the shading part works.
The 3d points are placed on your 2d screen much like these projects:
(link to project)
(link to project)
(link to project)

The same game

Posted by zen on August 19th, 2008 filed in Scratch
Comment now »

This is a test for a game that’s the same as Same Game except it’s in Scratch.
http://en.wikipedia.org/wiki/SameGame
www.andkon.com/arcade/tetris/samegameflash”>http://www.andkon.com/arcade/tetris/samegameflash
Kuniaki Moribe gets credit for the original same game called “Chain Shot!”

HOW TO PLAY:
Click a color that’s neighboring another color.
Wait a while before you can click another.

HOW I MADE IT:
This is growing on the cursor and grid/cell techniques I learned from making the “Gui combo box” and the “Conway’s Game of Life”. It also borrows somewhat from the drawing array technique. (I’m not sure who started that.)

Initially the level was created by one sprite, a cell at a time. but is was slow.
So I finally narrowed it down to each column having a sprite that handles it’s column for drawing and everything else:
1. “DrawNewGame” draws the random colored balls in the column starting from the bottom.
2. “MarkConnectedBalls” starting at a region around the cursor. it senses whether one of it’s neighbors has a “MarkEmpty” dark grey color. if it does, it also stamps “MarkEmpty”. and continues. several time in this region that expands. This part needs more work. TODO: add score.
3. “DropBalls” starting at the bottom it looks for the dark gray “MarkEmpty” when it does it stamps it with a “BlackOut” to get rid of the marks. it goes up till it finds a ball, if it does, it sets “DropMoveColor” to 1,2 or 3 depending on the color, then it goes back down to where the first “MarkEmpty” was and draws the ball there. (This part can be a bit more efficient too.)
3 TODO: “MoveColumns” this will do a sweep horizontally from the far right column moveing them over if there’s an empty column,
Column 0 will handle the Row 0, column 1 will handle row 1 etc…
if row one is empty, every sprite will copy the previous column to the current one and continue till the far left.

Also I created the column sprites so that each column sprite has the same code except the column number at the top, so I can work on one column- then when I’m done, copy it for the rest of the columns-. then I only have to change the number at the top.

The cursor works like this:
It is constrained to move in increments specified by “Board-SizeOfCells” so the cursor moves always to the middle of the cell the mouse is in.
The cursor is also a sensor- if it is over a ball it ’shows’, if not it ‘hides’.
when clicked, it switches to a sensor that touches the neighboring cells, if one of them touches the same color as the current cell, it switches to the “MarkEmpty” Sprite and stamps. -which is a black ball with a very dark gray center.
The cursor also sends commands to the column sprites.

Let me know I need to clarify some of this.

TO DO:
-fix/optimize neighboring color elimination.
-make columns move over empty columns.
-add pseudorandom level generation so people can master a level and compare scores.
-add scores.
-improve graphics
-animate balls moving.

green goo

Posted by zen on August 19th, 2008 filed in Uncategorized
Comment now »

Hold space to slow the animation.

3D tank

Posted by zen on August 19th, 2008 filed in Uncategorized
Comment now »

A better 3d Tank! Feel free to use it, but gimme credit. Id love to see this made into a game! Use the arrow keys, and “A” “D”

YAY! Top Downloaded!!!

GO HERE TO GET YOUR OWN 3D MODELS!
(link to project)

Archery Champion beta 1.0

Posted by zen on August 18th, 2008 filed in Strategy
Comment now »

This is just a little fun project I did in a couple of nights, just to see if I could figure out how to make it work. I’m not a programmer, but I like to see what I can do, and scratch is AWESOME. I made all the graphics real quick, and I know there are some problems, but I figured I’d share it.

1. Just click the green flag
2. Click the shoot button.
3. Press the mouse button to stop the elivation slider. (Try ti hit the center line)
4. Press the mouse again to stop the left/right slider. (Try to stop it even with the wind flag)

Your score is at the top.

You can reset the round and score by clicking the reset button.

See how high of a score you can get, enjoy!

Spin Scratch’s new 3d tank!

Posted by zen on August 18th, 2008 filed in 3D
Comment now »

See how fast you can spin Scratch’s tank.

Just click and drag to the right or left then let go.

Grabbing it while the mouse is still, stops it.

The model is for a 3d tank game I’m working on. Don’t worry, it shoots mostly harmless hair balls. When it’s done, I’ll release the source files.

The art was made with a free 3d program called Blender, available from blender.org. It has A TON to learn, it’s interface is very different. If you want to learn. I’d suggest watching the video tutorials and getting help in the forum. I think would have learned 3d much faster if I had those tools when I started learning about 10 years ago.

Do you want to make your own spinable 3d objects? Love this and I’ll make a tutorial, and setup files that will make it easier to spin your own 3d models in Scratch.

I’d be honored if anyone was able to use any of my work in their project. Please don’t just copy- try to make something new from it and at least give me a little credit in your project notes.

To whoever designed the Scratch cat: awesome job!

If you want to see a test of the 3d game engine I’m working on: (link to project)”>(link to project)