Game Geek Speak

I hope to not have many deadlines that are this crushing, but it sure as heck is making me productive!

I’m working at a breakneck pace: 12-18 hours per day, and I have to thank my wonderful wife and kids for their unconditional support. But–oh my goodness–I’ve built a full editor, the second half of my alpha game engine, and all kinds of game logic in just one month. It sucks, but the pain is temporary, and I’ve got a nice chunk of code to start with for the next project and beyond.

Here’s another ugly screenshot using placeholder art stolen from freebies out there and a few things from my own archives that Greg has done. So, disclaimer: This isn’t what the actual game will look like at all. It’ll look a lot better. You can find out in about 3 or 4 days.

That’s me getting blown to smithereens.

I keep lusting over this amazing looking tool. You can bet that I will be getting my grubby paws on it eventually. There’s simply too much potential there!

Unity3d is one of the many reasons I wonder why big companies are still making boxed retail games at all. For that matter, I often wonder why small indie developers are making downloadable games at all! I will never make another non-browser game in my life, unless there’s a huge incentive or it’s an optional download version. It just doesn’t make sense anymore to put up a barrier to entry like forcing a download and install.

There are two things I don’t like about Unity: 1) the development tools run on Macs only, and 2) I can’t use Java even though the tools use Mono (which supports Java).

First point, I have nothing against Macs (heck, I own one). It’s just not my development platform of choice. I have a bunch of nice tools already that I’m comfy with on my Windows machines. I don’t wanna have to build all that up again. That said, Unity holds enough potential that I would.

Second point, I don’t dislike C#. It’s a lot like Java, maybe even better in some ways. The reason I don’t want to move away from Java is because that’s what all the server code is written in, and it would be really nice to only write the classes etc for one language! Again, though, I think Unity has enough potential that I would bite the bullet and do it anyway.

Oh, point three: it costs $1,500 bucks. Ouch. I know there’s a cheaper version, but it’s too crippled for me–you can’t even publish to Windows! So, really there’s only one price point. Like the other two problems, I think I can overcome this one because I am so enchanted by what I could do with this engine. Lila Dreams in 3d? You never know….

Well, I was just distracted for a few minutes (again) by the tropical demo, so I wanted to get this off my chest.

Update: Sweet goomba! I just learned that Unity 2.5 will be the first Windows release for the authoring tools! *weeps with joy* But also the indie license will allow publishing to Windows now. And the indie version costs $200. *faints* Discovering Unity has blown my mind. It solves so many problems. I must have it!!

Here’s a quick post to show the entity panel of my game editor (click for full size version).

So on the left is the map view, where you see a really, really hiddeous jumble of a test map. The interesting thing there is the little heart with lips (a placeholder icon I borrowed from a casual game I made a couple years ago). That’s the entity icon, which in this case is a player spawner. That is where the player will start in this map. Yellow means that’s the selected entity, and the white square is where the cursor is (though the mouse pointer isn’t visible since pressing Print Screen doesn’t capture it).

On the right side, things are a little more fun. Those entity properties you see are generated dynamically. This is a really cool thing that I have wanted to try for a long time. The entity’s components define what is exposed and editable in the editor. The editor then builds the UI based on that. So I don’t have to add code to support editing new components; I just add the property definitions to the component, and the rest is magic. I’m hoping this will save me time in the long run. So far? It rocks.

In case it didn’t slap you in the face, the editor is an AIR application, which means I get to do all kinds of file system stuff like load and save maps and assets without security restrictions.

(Maybe in the next post I will finally show a map that isn’t just random lines.)

When you are in a Big Huge Hurry to finish a project (like I am now), and you are building new classes, here’s a simple bit of advice that isn’t easy to follow: keep your constructor parameters minimal. If you don’t, things could end up getting insane fast.

All the trouble begins, of course, when you’re programming at 90 miles per hour and what looks to be the quickest way to do something ends up being a bad way to do it. In my case, I was giving some constructors too much data all at once. I was sending stuff to be initialized that should have been deferred and separated into other functions.

For example, tile layers were being given view constructs (like the view camera). It’s clear to me now, after I’ve been forced to re-examine it, that assigning the camera reference at the constructor not only 1) forces a dependency on the constructor which limits how I can use it, but 2) it isn’t really useful at that point anyway, and 3) it’s plain bad design! If I just stick to good principles of software architecture, I would have realized right away that this is destroying class cohesion and I’m only on the constructor function! What’s going to happen to the other member functions?

(In reality, it’s not that simple. These additional parameters were added over time as things grew and got more complex, incrementally. But that’s even more reason to be mindful of this issue!)

So instead, I took that out and added an attachCamera() function. Now I’m more free to construct the tile layer in various places (there are different initialization sequences/environments in the game and in the editor, so this became a problem). But also it’s better design, because my constructor should only ever receive parameters that are critical to the creation of the class instance. To finish with the example, a tile layer doesn’t need to know what camera it’s using when it’s first created because it’s not even in a tile map yet. Duh.

But this stuff is easy to forget when you’ve been going for 12 or 14 hours. Had I not needed the editor use case, I might have not realized the damage I was doing so I could undo it now rather than later. *whew*

Well, it’s not much. It’s certainly not representative of the real thing. But it shows some progress. Box2d handles collisions, game entities are defined in XML as a series of component definitions, and soon there will be much more interactivity in this little game world.

(Hrmm. WordPress seems to shrink the images even when I tell it not to! The one I uploaded is slightly bigger and less fuzzy than this one. Do a “right-click->view image” and you’ll see the slightly larger one. The engine version is wrong. It’s more like 0.3.0 now, but still Alpha.)

The red-tinted parts show the “entity” layer where all the fun stuff happens. The other layer is “above” the entities and so they can appear to be under it. No technical limits on the number of layers, and each one doesn’t add much to the rendering workload since the engine only renders the strips that appear when a tile-boundary is crossed (ie, vertical or horizontal strips on the edges of the screen).

The tiles are something I got from RPG Maker, I think. The avatar is by Greg (Lila Dreams’ visual designer and my long-time collaborator).

Here’s the editor, first showing tile editing mode.

And here is map “attribute” mode where you define what tiles are blocked or not. Eventually this will be expanded and refined so that you can create Box2d polygon shapes right in the map, but that’s a long way off. For this game project, the needs are simple, so this does fine.

I am keeping mum as to the nature of the game being made, but expect to see more of it as things progress this busy month.

I came across a pretty handy regular expression cheat sheet today. I do not use regular expressions very much, so when I need them, I always have to look up the syntax every time. So this seems like a pretty good thing to have a quick link to for those times.

Have a look-see: regular expression cheat sheet.

One little snafu in Flex, specifically, is to remember the second parameter when you create an instance of RegExp. If you need something like “g” (global) in a plain regular expression, you’ll want that in the “flags” parameter or it won’t do much.

I’m probably boring the world here, but I figured I’d follow up on the last post to show some progress on my editor. It’s still really ugly, and this isn’t anything more than a throwaway map scribble, but at least I can say that it’s running and I have conquered the Flex issues I ran into. So there.

(The magenta is transparent in the game engine.)

The editor also has undo. It’s hard to live without, so I implemented it now instead of later. It also saves maps as XML, which I will usually embed into the SWF, but doesn’t have to be there. The asset manager can handle either case, which makes life easier for test phases when you are changing the maps a lot.

I hope to get some “real” test maps put together and get right to testing things by this weekend. All depends on other demands on my time, of course.

How about a little self indulgence? After the amount of hair I lost wrangling with Flex, I deserve it!

I admit it: this is butt ugly. It’s just plain old Flex. I didn’t add any styling at all. Who has time for that?! And the screenshot is tiny (better ones will be bigger, promise).

Anyway, what you see is the new map dialog, where you enter some parameters for your new map. To the right you see the edit bar, a tile set, etc. This is laid out like the Lila Dreams editor, but the code is only slightly based on stuff I did previously (handling user prefs, finding asset directory, etc). It won’t actually make a new map yet, but I just need to hook that up to the UI.

Let me summarize: five hours of trying to figure out why Flex didn’t like my custom components and associated .as files. Finally I just decided to inline all the code, to hell with keeping it separate. I have always thought Flex is very tedious to use. It’s a love/hate relationship. Maybe in seventeen thousand years, after I have used it a little bit, I will feel more on the love side. Today… not so much.

On the positive side, it is coming together pretty fast despite these kinds of frustrations. There’s a chance I can achieve my goal! More updates to come.

Addendum:
http://www.adobe.com/cfusion/communityengine/index.cfm?event=showdetails&productId=2&postId=7142

*Screams*

Well, at least now I know that you can’t subclass Canvas and expect it to behave like when you subclass UIComponent if you are trying to add a child Sprite to it. What I mean is, if you create a custom component that subclasses Canvas, it will throw an exception when you try to addChild() a Sprite. But if you subclass UIComponent, it will let you addChild() a Sprite.

*Slaps self silly, then gets back to work*

I’ve been on an epic quest to figure out how to best structure my game loop. The game loop is the one place where all your game’s logic should be updated. It’s the control center.

I’ve used delta time before, and that works fine in many cases. It’s where you measure the time since last game tick (aka frame) and tell all your objects how much time has passed so they can scale their responses accordingly. This is simple, and it works for very simple physics models. The trouble starts when you’re using a complex physics simulation to control objects.

I’m using Box2d, and for a physics sim, you want every update to use the same delta time. Fluctuations can cause the simulation to get all wigged out and blow up. Lucky for me, on the game I’m working on (not announced yet), I’m mostly only using Box2d for collision detection. There are no stacks of boxes or whatever, so there’s not a lot of simulating happening, and that makes it more tolerant to variable tick durations. Still not ideal, because it can cause weird collision glitches, like tunneling.

My view camera, though, tends to be very sensitive to update time fluctuations, and if the player moves more one frame than in the last, he jitters. It’s very annoying, and makes the whole game look jerky and twitchy, even at respectable framerates.

So my quest has been to find a game loop that can smooth all this out.

One thing I did was enforce a constant framerate. This allows the rendering to happen at a steady rate (like 30 fps) by sleeping for a few milliseconds if it’s rendering faster than your desired framerate. You basically measure if the last frame took more or less time than what you want, add (sleep your timer) or subtract (don’t sleep) that time from the current frame, and that evens them out.

So I had the physics decoupled from the rendering, but even with the steady framerate, the physics was updating at varying speeds to keep a steady 60 updates per second. So, for each frame (at 30 fps) the physics would typically update twice. But sometimes the interval since the last update would be more than that, so it would update 3 times, or maybe only once. Again, this causes jittery movement and makes the game feel really terrible.

So I’ve decided to just frame lock the physics and rendering. That means when there’s a frame rendered, there’s a corresponding physics update. As long as you have the CPU to stay at or above the minimum frames per second, the game will look nice and smooth.

This is great. Mostly. The problem happens when the computer can’t keep up with your desired framerate. Since things are on a fixed time step, the whole game slows down. Slow motion is only fun if you mean for it to happen! But I haven’t found a better solution, and I’m on a tight deadline. This’ll have to do for now.

Some linky goodness:
http://www.8bitrocket.com/newsdisplay.aspx?newspage=10248
http://gafferongames.wordpress.com/game-physics/fix-your-timestep/