The world of a game development student

Character Physics

2010-03-13T16:12:00.001-06:00

When I first started using a physics library to do collision detection/response I realized that character control wasn't really just handed to you on a plate. I looked at how one would go about adding normal platformer controls using a physics set up and was a bit overwhelmed. So instead of attempt it I took an easy route and made my characters rolling circles. Granted that works for some game types but sometimes you need something a little more interesting. I've been working on adding some platform-y controls to one of my games and figured I'd share what I learned.

The following assumes you are creating controls for a 2D game with some physics library (I recommend Box2D or Chipmunk).

Body Setup
For most games it is important to be able to detect what portion of your character's body is receiving physics callbacks, for this reason we will need to set up a few shapes to attach to our body.

Torso

main collision shape (in my case a rectangle encompassing shoulders down to bottom of the feet)

Head

for movement purposes I just want a circle to help the character shrug off his cranial injuries (not get stuck on his head when falling)

Feet

a sensor shape simple to detect when the feet are touching something

Bounding

another sensor shape to help correct orientation when fallen over (not needed if fixed orientation)

From the picture we can see these four shapes. I have colored the physically interacting shapes as green and the sensor shapes as blue. It is important that the foot sensing shape go beyond the interactive portion of the character so that jump detection can work smoothly. If you'd rather your character not be able to fall over, you can always lock the orientation and the bounding box I create here is no longer needed. The next section will detail how I use this box to help orient my character.

Standing Up
If you can get away with locking your orientation you do not need to worry about re-orienting the character. However, if you do want your character flipping about then please read on!

Without any orientation correction, it is inevitable that your controllable character will fall over and potentially start walking with his belly or get stuck forever. Neither of these are all that desirable for most games so we will work on helping the character stand back up. The general idea here is that we know what orientation the body should be in and what orientation the body is in and we want to adjust the orientation to the desired one without breaking the physics simulation. Let's look at some code.

// desired angle
 float ang_desire = std::fmod( std::atan2(m_Gravity.y, m_Gravity.x), (float)Gosu::pi * 2.0f);
 //Current angle of body
 float ang = std::fmod(m_Body->GetAngle(), 2.f * (float)Gosu::pi);
 //find difference to upright (-gravity)
 float spin = ang_desire - ang;
 if (spin > Gosu::pi) { // Angle wrapping stuff
  spin = ang_desire - (ang + 2.0 * Gosu::pi);
 }
 if (spin < -Gosu::pi) {
  spin = ang_desire - (ang - 2.0 * Gosu::pi);
 }
 //apply torque to correct
 spin = spin * m_SpinAccel; // Get our force
 spin = Gosu::clamp(spin, -m_MaxSpinVel, m_MaxSpinVel); // Clamp to min/max
 m_Body->ApplyTorque(spin);

Here I wish to orient my character to my dynamic gravity vector, so I compute the angle and normalize it to be between 0 and 2*pi;. I then find the difference angle and normalize that to be between -pi and pi. Now I should have the closest difference angle to my desired orientation (no rotating over 180 degrees). I then apply an acceleration magnitude to get a force out of the difference. Here you may want to note that we want a time-sliced force so you might want to choose an acceleration and divide it by your tick speed. Of course if you don't mind having your acceleration in terms of 1/20th of a second or whatever your update rate is, don't worry about it. We then clamp this to some minimum and maximum force so that the character doesn't try and spin wildly about. Finally we apply the force to our body through the ApplyTorque method.

This can be run constantly, or maybe you want to fire it off only when necessary. Either approach is fine, it will just affect how much torque you want to apply. I have a little of both running in my version. As you run around the character will try and orient himself automatically, but if you do fall over the bounding sensor is used to detect such a situation and allow the player to prop themselves up. This is done by checking if the character is not touching the ground (foot sensor) but the bounding sensor is touching something. The player can then press jump to apply a small impulse to the character allowing the re-orientation to take control.

Walking
Walking is fairly simple compared to re-orientation. We simply want to push our character in some direction. Now if we want to only walk while on the ground we need to implement callbacks and keep track of contacts between the character's foot and the ground. I will probably cover this in a later post as doing this using Box2D's current stable interface is a bit involved. For now we can just assume we know when the character is on the ground and move accordingly.

Running
Sometimes walking just isn't fast enough and we need to get places faster but we don't have a car/airplane/trained ostrich. So we make due with running. For character control this usually just means a modifier key that signals your control code to up the velocity of the character. Nothing too complicated here.

Jumping

Now what would a platformer be without jumping? That's right, something else. Jumping itself is pretty straight forward, we just need to push the character upward when given the signal. Now what if we want something like Mario where the longer the button is held the higher he jumps? Okay now we're talking!

For this, we need to keep track of button states i.e. press/held/release etc.. Let's assume we know these things (I will probably write a post on it later) and head on over to logic town. When the jump button is first pressed we apply a large impulse to the character upward, this acts as our initial thrust and baseline jump. We then set off a timer so we don't just let the player hold down jump and jetpack all over the level. I usually set mine to 1/2 of a second. Now, as long as that timer is not zero (don't forget to decrement it) and the jump key is held down we continually add a smaller thrust to the character. I used a ratio of 1:10 for initial to sustained propulsion which seems to work fine for me.

Extra

All this is fine and dandy but sometimes we want more, like say the ability to jump further based on current running speed or spinning around in the air or dynamically changing the animation speed with the running speed. Really this is where you have a chance to shine and make your movement stand out. With the basics down you should be able to add a number of things to help deepen your movement.

And just to see all of this in action, here is a little video of my implementation at work
http://www.youtube.com/watch?v=mvcJ9I_9oww

What I've been up to

2010-03-09T01:33:00.009-06:00

Alright, so maybe I'm not that great at blogging yet, or maybe I haven't felt like I've had anything to say for awhile. At any rate, I've been busy and I need to start updating this thing again. So without any more ado.

My Unnamed Game Engine

I've been working on creating a number of extensions and systems that I've found a need for to use with Gosu. It is all C++ since I don't really want to mess with wrapping most of it for Ruby (there are semi-equivalent Ruby solutions available), but in working on this I have certainly accrued quite a bit more experience with C++ and learned a nice set of tricks. The project can be found on Assembla where you will immediately be confronted with my unfinished stub documentation. Until recently, the code base has gone through several dramatic changes which made documenting anything a fairly needless task. However I will discuss a few of the major features here.

To start, I've built a simple game state system based on using a stack of states. The topmost state in the stack is sent the normal callbacks of update, render, and button events. In addition to these, there are also initialization, cleanup, pause and resume methods that are called on state transitions. These exist mainly for memory management (something I have not yet fully needed to flesh out). Just today, I added a pluggable factory implementation to aid the dynamic use of states. With this, it is now easy to create a new state that does not have to interfere with the core classes (saving compile times). It is also simple to dynamically create and push new states on at runtime, which eases my need for quick iteration through skipping titles and menus without recompiling (since I don't have hot asset loading yet). Information on this set up can be found on gamedev.net. The only problem I found with that particular example is that static member initialization order is undefined so in order to ensure that things work you must make your maker registry a pointer and create it in the registering function (this is detailed in the forum discussion).

Another large portion of the project are my graphics systems. Gosu itself already has a great interface to do 2D rendering, however I wanted to make a nice parallax rendering setup which required a few tweaks. In order to maintain a clean interface to rendering I needed to abstract the drawing code away from game objects. Otherwise each object would need to know how to translate world space coordinates into the screen, which can easily become hairy. I tried providing a translation function, but passing around a pointer to the translation module wasn't much nicer so I ended up pushing all rendering and sprite management into its own little unit. Within that unit, you can create sprites and spritesheets. Since the rendering itself is abstracted, each gameobject simply changes the state of the graphics objects to change how they are rendered within the manager. The sprite objects themselves are merely classes wrapping up the many parameters passed to Gosu's draw calls, listed here:

position (world space)
zoom factor
rotation angle
drawing layer
visible flag
scaling factors
image center
color modification

Spritesheets are a little more involved, since Gosu doesn't support them directly, but provides an interface to build sheets by returning a STL compliant container holding the Gosu::Image objects. This functionality is contained within my SpriteSheet class which adds support for cycle speed and all the same parameter functionality of Sprite. The parallax rendering is a full parallax implementation, meaning it supports the normal horizontal panning, but also vertical, zoom, and rotation. A demo of this can be viewed on YouTube.

JSON Configuration

Normally, text based configuration in games is done through XML. Personally I find XML to be bloated and goofy looking, despite its power and versatility. Instead, I chose JSON which I find much more readable even though it does not support schemas nor are there many nice libraries that take care of parsing, modification and serialization. The library I am using is TinyJSON, which seems to be disappearing from the Internet. The benefit of this sort of parser is that it is lightweight (aside from requiring Boost::Spirit) and fairly easy to use. It does not support serialization out of the box though it is easily implemented. Because of the complicated data structures used it is quite a pain to modify the data model (the structure does make it rather easy to use normally, just a pain to modify). However, both of these functionalities have been added within the project as well as a cleaner interface to obtain parsed data.

Using this, I have established a set of configuration files to direct the flow of the engine as well as tell it what assets to load and how to use them. This ranges from establishing key bindings to window size properties to level environment arrangements. At one point I added configuration support for menus, but for now I prefer to write custom menus in C++.

UI Components

This addition is a popular sort of Gosu Extension, though at the time I started making it there weren't many available (I think everyone started one at the same time). Mine is fairly simple, you create a base object that represents your game window then add objects to that. There is a draggable window component that also supports adding components, but the hierarchy doesn't go much further than that. Alongside this scheme is functionality for what I call pages. A page here is a context for the UI containers that allows the user to use a single container for multiple interface configurations that can be switched between. This is not the most elaborate or feature rich UI system, but it suits me just fine.

Physics

The final addition I will talk about here is the inclusion of box2D physics. There aren't a great number of C++ 2D physics libraries around, but even if there were box2D is a fantastic one to choose. It doesn't have too many frills which makes it easy to get started using. Plus, it is actively developed on by a number of people who know game physics. At this point, my inclusion of it within the engine is pretty minimal. I have a few callback listeners set up to notify objects of collision events, but with the upcoming new version that API will change to simplify my implementation. For the most part I haven't had too much need to wrap any particular functionality or build any crazy contraptions. So I'm going to just let those things build up over time as I need specific things. I will probably be creating a particle emission system at some point that will make use of box2D, but for now I don't really need it.

Game Projects

Now, obviously there isn't much point in building all of this if I weren't creating some games. At this moment I'm working on two projects in my spare time. The first is a reincarnation of my "Circle Game" or Hamsterball Galaxy. The point of doing this is that originally I wanted to open up level creation to the users and add several graphical tweaks to the game. These additions were limited to my implementation however since I built my levels as static arrays (holy crap) and didn't spend much time working on the graphics code. This time around, using the engine should make these things much more feasible and hopefully allow me to take the project to a higher level where I'd be more comfortable with attaching a price to it.

The other game project is just now coming out of prototype phase and into a formal birth. Sometime last year I toyed around with doing Mario Galaxy style movement in 2D and found a nice starting point to accomplish it using box2D. With that, and more brainstorming I've come to believe that this style of movement would work amazing within a Metroid style run 'n gun - dungeon crawler game. There are still some tweaks that need to be done with movement to make it squeaky clean, but things are still looking promising.

Wrap Up

This is but one side of my current status, next week-ish I will try to write a post about my graduate work.

Walla Zombies!

2009-04-19T20:00:00.006-05:00

So I've finished my game for the Ludum Dare contest. Today I spent a few hours fixing my graphics to not be so shoddy.

The buildings don't really match up to the scale of the characters, though I'm not really worried about that. As for code changes, I gave both the zombies and player simple momentum for knockback when being hit. For the zombies, this also helped smooth out their movement. I've also put in some simple particle effects on damage. The effect shoots out 10 colored balls which fly out in a random direction and slightly up. They have basic gravity and will bounce when hitting the ground (z=0). For the zombies, I colored them a stale red-near brown. Donuts emit brown, and the player red. This gives a nice effect and really does make the game more interesting. Another small graphical change is that characters turn more red as their health goes down. This is more visually stimulating than modifying the alpha.

A larger update added today is a melee attack. You can see from the screenshot that the character is holding a rolling pin. If zombies get too close to the character, he/she can right click the mouse to swing which will hit surrounding zombies and push them back a bit. This is nerfed to reduce players' attempts to rely on it though, by limiting the speed to 1/5 of a second and only hitting ten zombies(this also reduces some sound effects clutter as I didn't build a sound manager of any sort so sounds are played for every action).

As for optimization, I gave the zombies a timer to stall updating the field which is staggered among all of them. After the initial delay, it will reset to 5 ticks on each count down. This way, with 50 zombies on screen only 10 or so will attempt to update the field at any tick. Adding this did not seem to harm the zombie behavior, and the game no longer crawls after throwing many donuts. The targeting has also been optimized, before they would attempt to update the field for each available target that was close. Now they find the nearest object and update the vector field based on that object only.

All in all, I believe the game is a success. It started as a quirky game with some interesting developmental elements, i.e. vector fields for AI movement.

Almost forgot links to the game.
OS X application
Windows executable
Source
For linux, grab the source and install Ruby+Gosu as per the README (unless you already have it)

Ludum Dare

2009-04-18T21:38:00.004-05:00

So I found out yesterday that the Ludum Dare competition was Internet based (hooray for making assumptions!) and now I'm participating with the Ruby/Gosu crowd. If you are not familiar with the contest, it is a solo contest where you basically get a theme (Advancing Wall of Doom this time) then build a game from scratch (outside of several accepted frameworks for code). My idea is a combination of word play and sleep induced story.

A friend of mine jokingly said something about "walla" which turns out is a word, and a city. As a word, it means the incoherent rumble of voice that comes from a group of people. It is also a city in Washington (Walla Walla). From that, my game is a "walla" zombies in Walla Walla. The point of the game is to survive a horde of zombies by running and tossing donuts (y'know cause zombies like donuts). Don't ask why donuts, I don't know. I was half-asleep when that idea came to mind. Now, the main character is a baker and that just happens to be all that he has on hand.

For mechanics, the zombies move according to a vector field, ala Ronald C. Arkin's paper "Motor Scheme - Based Mobile Robot Navigation". The map is split into 10x10 pixel cells, with randomly initialized vectors pointing where to go. On each update, the zombies pick up this vector and move in that direction. There is a three in ten chance that they will just move randomly, adding noise to the field in case they get stuck, and to make their movement more erratic. If they are close to a target, they will build a local vector map pointing towards the target and update the map. If they are touching (very close) they will "hit" that object, which will either return 1 or -1 if that target is the player or a donut. This way they can gain health from players and lose from donuts. Over time, they will die on their own (starvation) which is the objective of the game.

Because I like making things difficult, I decided on using a simple array based collision map. Normally, this is a fair idea but instead of storing this data in an image or something convenient I just used text. This is mainly because I don't have the RMagick gem installed and don't really want to install it. I would also rather keep my Ruby dependencies to a minimum as I don't want to make it difficult for any judges to run my game. My window is 640x480 pixels, which works nicely with a 10 pixel unit space. This leaves me to author a 64x48 array of ones and zeros. To keep from driving myself mad, I'm just going to limit my game to one map and design that map so that most of the space is solidly open or blocking. From the screenshots below, you can see that the horizontal middle of the map is where most of the action is.

The engine for the game is built on top of Gosu, with a minimal state stack to separate the logic of title sequence, gameplay and credits. Using a nifty trick from another Gosu enthusiast, I've extended the core Array class to catch undefined method calls and feed them into the array elements. This makes it simple to do things such as @objects.draw

class Array
def method_missing(method, *arg)
self.each { |item| item.send(method, *arg) }
end
end

I've also extended the Image class in Gosu just to simplify calling draw with a bunch of re-used parameters, and also to enable simple animations for rotations and alpha changes.

On my laptop (1.6 GHz Pentium M, 2GB RAM, ATI x300 radeon mobility) I can easily have fifty zombies running around. Though this slows down pretty significantly with the vector field updates when you toss out several donuts. There isn't a whole lot I can do about this, as the work is being done in Ruby and I don't really have time to write some C code to fix such a specific thing.

For graphics and sound, I was initially going to use the sprites from lostgarden.com. However, using graphics not made by yourself is against the competition's rules. To cover this, I just traced over my background. Not really a good solution, but I'm fairly handicapped when it comes to art. Sound was built using GarageBand and sfxr both incredibly useful for projects like this.

To introduce the game, I created a title sequence that shows a few screens giving the backstory (the little that exists). After that there is a sequence zooming into Walla Walla starting from a view from space. To do this in 2D, I found several images starting with a picture of Earth, a colored map of the United States, a map of Washington's counties, then a map showing Walla Walla within the Walla Walla county (I'm not making this name up, I swear).

Without any further ado, here are some screenshots.

shapes and crap

2009-04-05T21:49:00.002-05:00

After seeing some animation of circles spawning with random colors and growing, I started making something similar with Gosu in Ruby. After showing some friends it quickly snowballed into supporting multiple shapes, rotations, random selection and cycling selection.

Basically, you need to try it to see what the hell it does.
Number keys change shape,
R turns on/off rotations,
O randomly selects shape, and
C cycles through shapes

file:///Z:/Ruby%20Projects/Circles/Circles.exe

SDL ain't dead yet!

2009-04-02T12:25:00.005-05:00

So I've been working on a clunky 3D OpenGL engine for my OpenGL class any for myself. As far as I'm concerned the class is just there to give me time to work on actually using all this graphics stuff I've already learned. Anyway, I'm planning on having it do a bunch of basic things;

load and render an obj file with a single UV mapped texture
load a series of images and render as a skybox without seams
use a grayscale image to build a terrain, and render with some texture
support point and directional lights
tie into Bullet for physics
use SDL for various bindings

So far I have most of these things set up, I just need some game objects and start using the core of Bullet.

However, I did hit a few snags along the way. Some are just shortcomings of my current implementations, others a bit odder.

Like most of my current projects, I'm attempting to keep my code cross platform by continually building in XCode and Visual Studio and using subversion hosted at Assembla.com. Earlier this week I hit a large snag while using XCode. I had cleaned my project to get rid of several mislinked libraries and unused resources when I discovered that I was getting an EXC_BAD_ACCESS runtime error in some code that had been working just fine for a while. It was in my obj loading phase where I was attempting to push some UV data on a std::vector (like I said, this is a clunky engine). But for some reason this was failing. Oddly enough, I was using other vectors alongside this one in similar ways and they seemed to work just fine.
At first, I figured I just needed to claim some memory before using the vector just to be safe. Of course, reserving and even adding some padding data before-hand just caused the application to crash on those operations. After fondling the debugger a bit I found that the type pointer was either null, missing (what) or otherwise ill-defined. This caused some serious head to wall banging as I couldn't understand how the code even existed without knowing what type it was. I convinced myself that there was a problem with initialization of my data member, so I tried putting a constructor into the initializer list (note, I'm doing all this inside my containing class' constructor and not using a pointer to a vector so this shouldn't be a problem), but to no avail. Finally, I decided to stick this thing in Visual Studio and see what happens. Once I got the solution set up and linking to the libraries right, I compiled and.. it ran. No problems, aside from a few small differences in rendering output due to different graphics cards. So either VS was just being nice to me, or XCode wasn't compiling my code right. I gave the problem some time, and when coming back to it I started trying silly things like changing my order of declarations in the class header. Putting the vector declarations first did nothing, putting some declarations in the middle did nothing, but changing the order of the vectors themselves did something. Turns out, whichever vector was declared last would throw this runtime error. What this means I have no clue, I'm not even sure how to Google for that to find a solution. So I ended up "solving" the problem by adding one more vector member aptly named "fuckme".

Oh, here are some screenshots of the current build showing off a cube of boxmen, a skybox and working terrain. If you look closely, you might notice that the terrain texture doesn't completely match up to the terrain itself. Don't worry, this is just a proof of concept and that image wasn't intended for this use.

Simple AI design

2009-02-01T00:32:00.003-06:00

Because I have several C++ projects that I'm going to need to develop AI for, I might as well begin working through some code design.

As far as game engines go, the singleton manager paradigm is pretty useful (though only in specific scenarios). With an AI system, this manager needs to keep track of all scene objects using AI, the AI itself, and information used by each agent. To me, this means that I can create some grouping for particular sets of AI functions and for each scene object requiring AI control I just need to know what set of functions I'm using. The information, or knowledge base, for each AI/object pair doesn't need to be anything fancy, so a struct will do fine. This leaves me with three components; the AI Manager, the AI Controllers, and a knowledge struct.

The manager is a singleton (no need for several managers in one running engine) that allows adding/removing of AI to scene objects, and provides a means to update all objects in batch. Keeping track of these mappings is sufficient to be a linked list of structs containing a pointer to the object, some identifier for type of AI used, and a knowledge object. More functionality may be needed, but for now this is all I should have to worry about.

The AI Controller types need to be able to support multiple AI paradigms. Initially I was thinking about keeping the knowledge separate from the controllers. Though this forced me to limit the types of AI that I would be using. It would either have to deal with complete information or incomplete, fuzzy or crisp, etc.. Instead of that, I'm better off keeping the knowledge within each controller. Though I'll still define a struct for the different types of data that I'll deal with.

As a base for the knowledge struct I'm including the following;

player position
player health
own position
own health
# proximal friendlies
list of identified projectiles and percieved tragectories (more intelligent agents)

I have listed two fields that are redundant as each controller would have access to it's object's health and position. Though this data may not be in some particular format which the AI functionality would prefer. So I'm listing them here anyway.

Put together, I have a manager which will create an AI control object when given a new scene object to manage. The control object will construct a knowledge set updated by perceptional utilities on the scene object and use this to make decisions for that scene object.

This design is incomplete, but I'm listing it now as an initial design.

Ghosts and Goblins

2008-10-25T15:15:00.004-05:00

Since I've been using Ruby to prototype games, I'm starting to find that it is a good idea to build a minimal framework for certain types of game (catch, platformer, driving, etc.) so that I can very easily make simple games out of them. For Halloween, I took my catch game and turned it into a simple platformer about trick or treating. (you can get to the download for it from my portfolio)

To keep this game simple, I imposed a two day limit on development. It wasn't hard since I already made a nice little system for sprite animations and collisions between rectangles so all I needed to do was build up some finite state automata to drive the items, make some images and figure out some simple gameplay mechanics.

To overcome the difficulty of distributing Ruby projects to friends, I used RubyScript2exe to bundle up Ruby, necessary libraries, scripts and media. This works great with the given variables to help give full path when you need to open files at runtime.

Since I can't really draw, I figured I'd use Inkscape to create the artwork. It turned out pretty well. I realized that I can draw using vector programs when I made a tiny vector drawing script on Graal, of course I still can't draw well but it works when the style is relevant.

Next time I might try Flash so that I can build some animations, but we'll see how that works out.

For sound, I used a track from Colugo - Music For People. I've been wanting to use some of his stuff since it all sounds like great game music. Obviously I'll have to get permission if I use it for a larger game.

prototyping with Ruby and Gosu

2008-08-28T21:45:00.007-05:00

Now that summer is over and classes are starting again (except now I'm in graduate school) I've decided to become productive again. Go figure.

I'm using Ruby with Gosu to quickly develop prototypes to test out gameplay mechanics. The first image above is a simple catch game using my boxman character I used in a TGEA game. Nothing special, just some sprite animation and makeshift rectangle intersection stuff really. I recently finished developing a cellular automata engine for the Ruby programming language. You can find the project on GitHub here (I'm still more of an SVN kind of guy, but we'll see how this turns out). I made this for two reasons: for one I haven't written a C.A. engine before, and two I needed something to test complex rules with for our game idea.

The game itself is fairly interesting itself in terms of design. Basically you build a "virus" out of cellular patterns to compete in some pairing with another player to see who's pattern spreads the fastest. If we go with the iPhone or some other mobile device as the platform for this, then we can bring in another level of viral spread. Battles can occur in some peer to peer fashion based on locality. I.E. you can battle people at whatever public area you hang out in. If we add a server to this mix, then we can track different data on people's virii such as wins, longevity (duration of winning record), spread (real-life spatial), whatever and display this in some form.

In developing this library with Ruby, I ended up learning a few things along the way. Mostly getting to know the inner workings of Ruby itself, such as how

Array.new(N, Array.new(K) {|i| i})

only evaluates the inner block once. Since I took a course last semester that dealt with functional programming, I can now make use of really cool language tools like lambda functions. It just so happens that Ruby's functional features are quite robust.

For my graduate research I am developing a simulation to mimic human behavior in an environment with several different types of sensor networks. This is to help with an eldercare project meant to bring computational intelligense into automated systems that can detect urgent needs or various lifestyle needs of people living in eldercare facilities.

By providing formal input describing daily behavior, my system will be able to simulate days, months, or even years worth of data collection by the sensor networks used by the eldercare system. By doing this, other research that attempts to understand that data can use the input for supervised learning.

At any rate, so far it has allowed me to start using JSON/YAML parsers such as TinyJSON and Ruby's built in YAML parser. TinyJSON is interesting since it makes use of Boost's Spirit library to provide a lightweight but powerful JSON parser. Unfortunately there is a slight lack of documentation for the parser, but with a little elbow grease it's not hard to figure out.


level = boost::any_cast<>::object >::object >(*v);
m_iUnits =  boost::any_cast<>(*level["unitpixel"]);

Turns out that the json::grammar::object is a std::map which works perfect for JSON data. v above is a variant type that is used to hold the entire JSON object, which you can see on the given documentation. The real trick is pulling data out of array types. Luckily there are iterators provided and you can cast them similarly as the variant type if you're like me and create arrays of objects often.

Figuring this out was interesting for me since I haven't had a chance to really dive deep into template programming in C++, so debugging my code was a real treat with that incessant type syntax.

Mark of the 1.0

2008-04-26T19:48:00.003-05:00

I am finally prepared to call my current build of "Circle Game" (now "Spherical Prison") version 1. For some reason, I'm a fan of giving the major numbers to the major releases. This release is the one that I will call "done".

After taking the time to fix a few hack solutions with proper solutions (i.e. using a boolean to determine if the player has entered the editor to invalidate scores instead of making the score infinity, using a list to buffer the collision callbacks instead of just using the first, etc.), and committing to a decision on what levels I should include, I'm happy with the result. As far as the level editor goes, it is not viable for community sharing. I found that even with making my scene dynamic, it would still be quite a bit more work to add methods of filtering keys from walls for deleting and rotating objects. There are member data fields inside the box2D objects that fit this need, but even with that I don't feel that the implementation would be clean in the end. The design I chose did not account for sufficient separation of actions pertaining to modification of objects in the scene.

Today I've also completed my configuration for the Xcode project, so I have a fully functional Mac version that is a duplicate of the Windows version. Aside from this, a good friend of mine (who would wish to be reffered to as "Z-Dawg") wrote up a makefile for the project for easy building in Linux. So, fortunately, I'm able to say that using cross-platform libraries has enabled me to build my first totally cross-platform windowed application.

For now, I must begin channeling my game through the library communities (at first) and then see what else I want to do when I get a web page up for it.

Onward to level design!

2008-04-06T22:21:00.005-05:00

Okay, maybe not quite so energetic.
This weekend let me get a number of things done. Now the menus are about 95% complete, and I have the first three levels pretty well set.

The first level gives the player a chance to get a feel for the movement. Just rolling around and letting the physics do the rest.

The second introduces the bounce and sticky walls. By changing your speed you'll hit the wall at a different angle and thus be shot off at different angles. So far everyone that's played the level has figured it out, so I'm definitely keeping the design. The only problem with this one is that hitting the walls just right takes a bit of practice. When you shoot up to the top, you can only get back down by pressing up to shoot your self off of the stage, which adds ten seconds to your score. So the strategy is to get the lower one first.

The third introduces the magnet wall. It's a pretty simple concept, but the design of the level gives a number of options for shortening your time.

Through some testing with my friends, I'm pretty happy with the designs. I'm still not entirely sure of the difficulty of the second, but I think I can overcome this with some sort of message shown to the player during gameplay. Of course, with levels I needed to finish the logic for "winning" the game. So now I have a place for credits and high scores.

The high score list shows the top ten total scores, and lists the player's initials and score per level. This is stored in a binary file (which is just a struct written out and back in) so it will persist.

Something worth mentioning is that I used DropBox to share the executable with my online friends. Doing this introduced an interesting type of concurrency to the game. As the files shared are synchronized across computers, each player was logically using the same files to play. This meant that the scores data file was shared too. Because of this, I could no longer leave a pointer to the file open while the game was running (bad design anyway). After fixing my design, however we still noticed that if enough people were playing, and finishing the levels quick enough, the files may not sync fast enough to prevent overwriting. There's not really much I can do about that, but it was still interesting to try and compete with each other.

Things still left to do are:
build an in-game level editor (extend the lifetime of the game)
finish the rest of the hardcoded levels
animations for the man, and likely the walls

Refactoring, and moving towards level design

2008-04-01T02:23:00.006-05:00

Even though classes are back in session, right now all I want to do is build my game. It beckons me when away, and teases me when I play... (this is why I don't blab in these things...)

I just finished some refactoring, I had let myself put the world and player management inside the main class instead of the scene. Now they are where they belong, and I have legitimately separated collision callbacks from distance checks for the walls' interactions with the player. As it stands now, every wall type except sticky is near complete. After I take the time to create some animations, they should be good. I'll have to check my color choices to see if they work alright with common color blindness, or if I need worry with the choice of animations. I figure that this project ought to be as polished as possible, since the complexity of it gives me that option.

Shown here is my little test level. The absense of a clear cut or even sensible strategy should be a dead giveaway.

Circle Man

2008-03-25T21:42:00.010-05:00

Finally, spring break is here and I can devote some time to game development!

This semester has me fairly busy with web development, fuzzy inference output analysis, and so on. Which is why I'm excited to start working with Gosu to build some quick PC games. This project is also going to use Erin Catto's Box2D library. If you are not familiar with either of these, you owe it to yourself to take a look. Myself and Mike Daly (who worked with me on the DS homebrew 2d physics project) are the only ones working on this project.

The premise of this game is that you are this stick man stuck in some sort of bubble. You are able to roll it around, and are for some reason in these environments with wall portions ("interactives") that physically alter your movement. As of now, there are four types of interactives:
Bounce - propels the player away from the wall
Magnet - alters gravity to pull player toward wall while against it
Push - keeps the player from touching it
Sticky - player will stick to these, and be able to swing from them to access certain areas
With these, we hope to create an interesting play experience. The goal of the game is to find all of the "keys" (right now I don't care what they are, just that you collect something) to escape from your spherical prison.

With this project, we finally get to use C++ and test our previously inactive knowledge of the language. So far, I've established a simple class hierarchy for our levels, player, walls, and "key" objects. From a brief standpoint, these classes have four main member functions: the constructor, update, render, and destructor. I'm hoping to keep the high level logic very clean, and keep all the actual play logic inside the classes. This entails that the level objects handle any and all wall object logic (all physical operations that do not operate on callbacks, and rendering). There will likely be some helper functions created, and some variants established during the optimization phase of development.

the Web, and its desire to be useful

2008-03-04T22:03:00.003-06:00

It turns out that this semester is a busy one, leaving me with no time to persue game development (thus far). In the meantime, I might as well document some of my web development.
Currently, I am working at the Center for eResearch here at Mizzou. I am basically an intern hired to develop a video sharing web application for the University that will soon go beta. So far, I've written Ruby scripts making use of ffmpeg to automate encoding of submitted videos into FLV, MPEG, MP3 and iPod compatable MP4 formats, and a fully functional web application to facilitate sharing. Here is a quick rundown of the requirements for this application:

Students and Faculty are allowed access and can be granted administration to channels for upload of videos. Channels are delegated to schools, departments, student groups, major events, among other things. Only through owning or being a contributor to a channel can you upload video. Anyone can register an account to subscribe to channels. A subscription lets you keep up to date with a channel so you know when new videos are uploaded, new events are scheduled and the like.

As far as technical details, I will briefly discuss those here. This project is a Ruby on Rails project, effectively this means that it is a rapid development, rapid prototyping, web 2.0 eager application. The one problem with the use of "rapid" here is that this is my first Rails project, so it has taken me six months to build it up this far. Albeit, I could not have done so much in PHP given my student work schedule (10 hrs/week). Aside from Rails, we are using MySQL and of course the Prototype and Script.aculou.us Javascript libraries as these are included in Rails.

2007-12-13T00:38:00.001-06:00

After some "deliberation", my scissor creatures are now 3 times as large, and 10 times as few. Doing this allowed me to involve more complex sense and think routines as many many little scissors quickly bogged down the engine.

The perception function, only searching for the player, implements a distance check, uses the dot product to determine if the player is in front, and a ray cast to see if the player is not obstructed to determine if we can actually see the player. While this works very well for initial perception of the player, it can be easy to deceive the AI by running behind it. To overcome this, I crafted the logic so that when we have been following the player, and they run out of the field of view, we simply check the distance again and maintain pursuit if the player is close enough (most of the time).

When the AI is not chasing down the player, it will follow predetermined paths. Currently, I have 4 of these paths, with two AI spawned on each. Because of this, and the way that the AI move (quick, but slow to stop) they seem to race around some invisible track. In a way, this comes across as a game that the scissors play normally. The screen shot below shows one of these paths with the AI running about.

Within the AI, I have 4 important functions.

The first, "think", is a scheduled routine that calls the sensory "checkFOVPlayer", then carries out the simple finite state automata. The FSA has two states, following the player, and not following the player. The states are guided simply by whether or not the AI can "see" the player (or if it has "forgotten" where the player is, see above).

The second, "checkFOVPlayer", determines if the player is in the field of view of the AI. It is explained in some detail above, and is included below.

The "onCollision" callback event is being used for attacking the player. When the AI rams into the player, it will push them both apart and damage the player. Very simple response, but it is effective.

The last, "onReachDestination", is another callback which is triggered when the engine finishes moving the object to its destination. When this occurs, and the AI is not following the player (running the track), it will iterate to the next node and let the engine move us to the next node.


function scissorbody::checkFOVPlayer(%this,%obj) {
 %line = VectorSub(%obj.player.getPosition(),%obj.getPosition());
 //%dist = VectorLen(%line);
 %dist = manhattanDistance(%line);
 %cantsee = true;
 if (%dist < dot =" VectorDot(%obj.getEyeVector(),%line);"> 0.0) {
     %typemask = %TypeMasks::TerrainObjectType & $TypeMasks::StaticShapeObjectType;
     if (ContainerRayCast(%obj.getPosition(),%obj.player.getPosition(),%typemask) $= 0) {
       %obj.setMoveDestination(%obj.player.getPosition(),true);
       %obj.followPlayer = true;
       %cantsee = false;
     }
   }
 }
 if (%cantsee && ($dist > 30)) {
   %obj.followPlayer = false;
   %obj.stop();  
 }
}

Scissor AI

2007-12-03T14:27:00.001-06:00

Before I talk about AI and my current progress, I'll say that I made myself a nice little function to warp my character around the map by right clicking on it. Nothing big, but it sure is helpful.

Alright, so the main antagonist to the boxman character is a race of scissor people. Fitting, right? Now, they don't need to be all that intelligent, basically just chase the player out of their area and chop him up. Ancillary behaviour is to just roam around (with some range of speed to establish different amounts of "determination") and probably have them sometimes fight amongst themselves, as they are vicious scissors. I would also like them to have a very simple learning scheme where they are capable of mapping limited states to good or bad outcomes (mostly just to learn that walking into water is bad, and possibly that a player carrying a rock is bad). I figure I can establish this by having limited state knowledge (where am I? is the player nearby? does the player have a weapon?), then by examining immediate outcomes, downplay states with negative outcome for a short time.

As it stands now, I've got some simple reflex agents that will watch for the player and charge them when they show up in the line of sight. The problem is that I'm using built in functions that set the aim object, which just happens to cause the AI to literally stare at the player no matter where they are. This is not the behaviour I want, they cannot be aware of the player at all times, they must happen to see the player then charge. To do this, I will have to build my own sight sensor function.

This morning, I was toying around with placement of the scissor race. I placed a marker out in the field and randomly placed n(100 now) scissor people around this marker. I soon found that when I let them all come at me, an interesting cluster pattern appears due to the collision amongst them. While this looks pretty cool, the collision also causes the player to become stuck. Immediately I thought I could overcome this by removing the collision between player objects. Of course, this caused the AI to combine on the field. It also did something crazy to the dynamic shadows produced for the AI shapes. You can see in the image that there is a yellow glow on the shadow. This is certainly not a desired effect, so I believe I will have to do something else to fix the sticking of the player. I'm thinking to just have the scissor people bounce off of the player, or the player from the AI or both.

Main menu

2007-11-08T21:52:00.000-06:00

Ok, so this isn't a huge update, but there's some interesting things to say.

I changed my main menu from using plain old buttons to shiny bitmap buttons, and then had the brilliant idea to add a sprite animation just because I could. I made some little sprites of my box man walking (from the side, flipped horizontally instead of rendering twice for each step) and standing still (facing forward), so I could make him walk to the button you were hovering over.

Actually, I started out wanting to make an animated cursor. So that he would "walk" as you moved left and right. But the only way I could get the mouse position was to place a GuiMouseEventCtrl over the entire gui, which effectively blocks all other items. That's when I decide to just have him walk at the bottom by the buttons.

To do this, I needed some of those GuiMouseEventCtrls to tell me when I moused over the buttons (the buttons themselves don't lend you any events). I found that if I nested the buttons inside the controls, I could get them both to work just fine. So, I used the controls to set the desired x position of the boxman (it's relative to the screensize, so it won't go nuts if you use a different resolution).

For the animation, I have a scheduled function that runs every 50 miliseconds (shown below) that checks the sprite's x position (held in a global variable, oh my!) to the desired x position and decides whether he should be walking somewhere or not. The animation is done via numbered sprites and string concatenation, and a counter. Since I only have 4 sprites per animation, I crafted another counter so that the sprite step would occur every 10 times this function runs.

Anyway, here's the code and a picture.


$mouseAnim = 1;
$mouseXPos = 60;
$animCounter = 10;

function mouseUpdate() {
if ($mouseXPos > 0) {
%boxPos = GetWord(BoxManBitmap.position,0);
%boxYPos = GetWord(BoxManBitmap.position,1);
if (mAbs(%boxPos - $mouseXPos) < position =" SetWord(BoxManBitmap.position,0,%boxPos+5);"> $mouseXPos) {
  BoxManBitmap.position = SetWord(BoxManBitmap.position,0,%boxPos-5);
  BoxManBitmap.setBitmap("ChadGame/client/ui/gfx/BoxManWalk_L"@$mouseAnim@".png",false);
}

$animCounter -= 1;
if ($animCounter < animcounter =" 10;" mouseanim =" ($mouseAnim-1)%4+1;" mousexpos =" 60;" mousexpos =" -1;" pos =" VectorAdd(playArea.position,VectorScale(playArea.extent,.5));" mousexpos =" GetWord(%Pos,0)-60;" pos =" VectorAdd(optionArea.position,VectorScale(optionArea.extent,.5));" mousexpos =" GetWord(%Pos,0)-55;" pos =" VectorAdd(quitArea.position,VectorScale(quitArea.extent,.5));" mousexpos =" GetWord(%Pos,0)-40;">

Catching up on Cardboard Land

2007-10-25T16:46:00.000-05:00

It might be useful to explain this project for anyone trying to figure out what my various mind dumps are all about.

Cardboard Land is a simple game where you are a cardboard man living in a world of cardboard. It is up to you to venture out from the safety of your village to find supplies. You must find as many as possible across the lands. These supplies are objects such as; glue, staplers, tape, paper clips, etc.. On your adventure you will encounter disastrous adversaries, such as; scissor people, water, tornados, huge piles of chewed gum, and possibly fire people.

Simple enough, I suppose. Here are some of my favorite screenshots so far.

Stay tuned for more real information as it occurs.

Tornados in Cardboard Land

2007-10-23T23:22:00.000-05:00

I started working on a wind area trigger within torquescript, and ended up creating a tornado because that is a fairly interesting effect to recreate. As this is a fairly short script, I'll just paste it here with all my comments and possibly add some stuff.
The flow is this: I create a trigger of my defined type, which should call the onAdd callback to initialise my tornado shape and particle emitter. However, somehow the onAdd isn't being called, so I'm just doing it explicitly. There are two main features of this script, a loop that runs every 50 ms when a player is intersecting my trigger, which takes the difference in positions between the player and trigger, then uses that information to build up some impulse vectors to pull the player in, and spin him around the z axis of my trigger. The second loop is independent of intersection, and is used to move the object around in a random manner. I created a momentum vector for the XY plane to keep the thing from just jumping around, and devised an "adjustment" vector to pull it towards the initial position if we stray too far from there.

Here are the two important functions:


function WindTrigger::onTickTrigger(%this,%trigger) {
  %max = %trigger.getNumObjects();
  for (%n=0;%n<%max;%n++) {
    %obj = %trigger.getObject(%n);
    if (%obj.getClassName() $= "Player") {
      //find XY distance to player
      %pos = VectorSub(%obj.getPosition(),%trigger.getWorldBoxCenter());
      %posX = getWord(%pos,0);
      %posY = getWord(%pos,1);
      %dist = VectorLen(VectorNormalize(setWord(%pos, 2, "0.0")));
      //calculate circular tangent vector and apply centripetal force to maintain circular movement
      %windX = -%posY - 5*%posX;//mSin(%posX)*mCos(%posY);
      %windY = %posX - 5*%posY;//mSin(%posY)*mCos(%posZ);
      %windZ = 10;//mSin(%posZ)*mCos(%posX);
      %obj.applyImpulse(%obj.getPosition(),VectorScale(%windX SPC %windY SPC %windZ,100*(1.5-%dist)));
    }
  }
  Parent::onTickTrigger(%this,%trigger);
}

function WindTrigger::moveMe(%this,%trigger) {
  //get our scale
  %scale = %trigger.getScale();
  %scaleX = getWord(%scale,0);
  %scaleY = getWord(%scale,1);
 
  //compute an adjustment vector to apply on top of
  //our movement to keep within some distance of original position
  %pos = %trigger.getPosition();
  %adjustment = VectorSub(%trigger.startPos,%pos);
  %adjDist = VectorLen(%adjustment);
  %adjustment = VectorNormalize(%adjustment);
  %adjX = 0;
  %adjY = 0;
  //stay within 25 units of original position (or try to)
  if (%adjDist > 25) {
    %adjX = getWord(%adjustment,0);
    %adjY = getWord(%adjustment,1);
  }
 
  //random(-.25,.25) with a step of .01
  %trigger.mvX += getRandom(-25,25)/100.0 + %adjX;
  %trigger.mvY += getRandom(-25,25)/100.0 + %adjY;
  //cap movement to [-1,1]
  if (%trigger.mvX <= -1)
    %trigger.mvX = -1;
  if (%trigger.mvX >= 1)
    %trigger.mvX = 1;
   
  if (%trigger.mvY <= -1)
    %trigger.mvY = -1;
  if (%trigger.mvY >= 1)
    %trigger.mvY = 1;
   
  //find our new position
  %posX = getWord(%pos,0)+%trigger.mvX;
  %posY = getWord(%pos,1)+%trigger.mvY;
  %posZ = getTerrainHeight(%posX+5 SPC %posY-5);
 
  //move trigger
  %trigger.position = (%posX) SPC (%posY) SPC %posZ;
  %trigger.setScale(%trigger.getScale());
 
  //adjust to center for inner objects
  %posX += %scaleX/2;
  %posY -= %scaleY/2;
  %pos = %posX SPC %posY SPC %posZ;
 
  //update StaticShape and ParticleEmitter positions
  %trigger.myTornado.position = %pos;
  %trigger.myTornado.setScale(%trigger.myTornado.getScale());
  %trigger.myParticles.position = %pos;
  %trigger.myParticles.setScale(%trigger.myParticles.getScale());
 
  //make sure we get called again
  %this.schedule(100,"moveMe",%trigger);
}

It works pretty well, but I haven't added anything to turn off all this simulation when the player is not near the tornado area. I think I may just put a large trigger around the area to enable/disable the tornado set when the player enters and leaves the area. I'll have to play around with this to see if it is sufficiently useable, otherwise I might need to turn down the delays so it doesn't use up as much resources.

Primer

2007-10-23T23:04:00.000-05:00

Well, I guess I should start documenting my development in ways other than filling up my desk with post-it notes. So, this place is as good as any. I believe I will start with my Cardboard Land game, and just go from there instead of trying to catch up (and remember various thoughts that have slipped through the cracks). So stay tuned, listeners (haha, radio) for information will establish itself right here.