Archive for the ‘Geekery’ Category

Oh My.

Well hello there.

I’ve been gifted recently with a rather enthusiastic group of commentators it seems, thanks for reading guys.

Largely because of their enthusiasm, I feel compelled to drop a quick update, and chat a bit about the nature of the game projects.

First off, the update:

Level Editor.  There I said it, and I’m not ashamed.  I am working on the Level Editor, and will be using it to generate all content for the games.  As development continues, I plan on integrating the editor either into the final games, or as a standalone flash app, which will push user created levels into a database for the games to consume… We’ll see how that develops.

I’ve been wrestling with a number of technical issues related to the level editor (texture placement,psuedo 3-d level objects in a 2 dimensional game space, etc),  problems which, given the side-project nature of the game development currently, present a challenge mostly in finding a large enough block of time to allow for me to load all the data into my head and get in ‘the zone’ enough to actually get work done.  I’m a natural complicator, and I tend to build engines which I then use build actual things, rather than just hack and slash my way to a working product… it’s a symptom of my day job (corporate systems programming).  Because of this, I can’t just dart in and hack together some code, then dart out again and expect anything to make sense later, so that’s been a fun challenge in it’s own way.

Now a few words about the ‘side project’ nature of the current game development…  Due to pressing money concerns, I’ve been forced to spend the bulk of my free time working on an as yet unannounced project, that stands a better chance of paying the immediate bills than casual game development.  As such, my time to work on the increasingly complex game engine has been reduced to a minimum.

So, while I do apologize for the long drawn out development cycle to those who are anticipating the game, I can’t really promise that it will be forthcoming soon, due to the aforementioned money/more lucrative projects.  At the end of the day,  my hope is that this other venture will provide the cushion needed to let me really focus on my passion for crafting games, and even allow me to focus on what’s fun (making some more grandiose games, such as massive RTSs and things like that), rather than what’s most profitable right now.

Also, I’ll be endeavoring to update more frequently here, and actually put together some articles about lessons learned.  I’ll probably even chat about the Plunk Pool game (soon to be plural), and the lessons I’ve learned there.

Stay Tuned.

Jump start.

Well hello there! It’s been a while, how’s life treating you? Good, glad to hear it.

So I’m back after a long hiatus from the game making. The short explanation for the long radio silence is that I became busy with several other unrelated projects. But the time has come to crank out the next illustrious title from Head Meat Games, hoorah!

But enough about me, here’s the interesting bits. First, I’ve been working on a sequel for Luncheon of the Dead. Well to be more precise, I’ve been working on a new game engine, from which I will build the sequel, as well as another RTS title as yet to be announced. I have just begun prototyping the actual gameplay within the engine

By way of giving some background, here’s a quick summary / post-mortem of Luncheon of the Dead, and some info about what I’ll be doing in the new game.

  • Single Level play – One of the most frequent suggestions that I received is to add more levels. Simply put, that will happen.
  • Small map – The single level that was Luncheon of the Dead was fairly small. This was due to speed and presentation issues. I’ve put alot of effort into expanding the capabilities of the game engine to handle much larger maps and more efficient pathfinding within those larger maps. To give an idea of what the difference is, if the map in LoTD was about the size of a standard CD Jewel Case, the maps in the new engine are roughly the size of a kitchen table. Naturally, this larger map will be displayed within a main scrollable view, complete with a sidebar minimap and Fog of War exploration mechanics.
  • Fixed number of Defenders in player control – The request to replenish units was a close second for the most frequent suggestion, and that will happen as well. There will most probably be a combination of rescuing and recruiting new units and possibly a more traditional RTS ‘buy-more-guys-with-harvested-resources’ type mechanic as well. This is not so much a challenge to implement in the raw engine, but a matter of creating a mechanism in the finished game to manage ‘buying’ new units.
  • Controls were…clumsy – This is something that will recieve alot of attention. One of the lessons I’ve learned is that any game working in the ‘Casual’ game space has to be dead simple control wise, or ridiculously compelling enough to warrant a person spending any amount of time learning to play. The goal is to find the sweet spot between a full features RTS style of control (multiple unit selection, assigning ‘squads’ of units to stick together, multiple behavioral ‘attitudes’ linked to commands (such as ‘Move to target’ vs ‘Attack to target’)), and a simple mouse only, keyboard optional control scheme that makes sense. I’ve put some time into general usability and UI research, and am working toward that sweet spot armed with a little more knowledge than I had going in to the first LoTD.
  • No Tutorial – This one hurt the game quite a bit, as the concept was rather complex (and in some ways poorly executed) compared to a typical click and drag casual flash game. I really needed to create a tutorial to ease new players (who probably had little to no RTS experience) into the controls and the gameplay. I intend to make a tutorial a requirement (for myself to build one in that is) for all my new games.
  • Graphics were…programmer graphics – Straight overhead, poorly detailed unit models. I’ve taken the time to make some isometric 3d models that I will be using in the new game. It looks alot less like pacman and alot more like the old school starcraft, so that’s a step in the right direction. Here’s a quick preview:
    • OLDOld_Defender: NEW:ShotgunHuman - New Engine

I think that sums it up for the game and announcement for the time being. I’m very excited about how the engine is coming together, and as much as I’d love to post the prototype here, I know that it would be exclusively show off my incomplete baby. So for now I’m going to wait until I have something more substantial to show that will benefit more than just my ego 🙂

Also, on a more geek note… (If you aren’t a programmer, you can pretty much stop reading here)

I have had to dig deep into the Flash display and event models to get the kind of performance I’m looking for, and in the interest of being a good programming citizen, I will be editing together my experiences as coherent posts in the future to share some fun knowledge. These are intended to be posts that cover more than the basics, so I probably won’t bother with creating yet another ‘how to capture mouse input’ post, as there are tons of those already.

Here’s the highlights of the topics bouncing around in my head:

  • Short Circuit the display tree for great justice – Using Bitmaps and cached Sprites to draw thousands of objects on screen super fast. Why creating a ton of sprites and addChild()-ing them all is killing your framerates.
  • Controlling your ticks – How to use multiple timer objects to control the flow of your game and rendering engine. Balancing to a consistent framerate regardless of how fast or slow the hardware / browser throttling is. (also, a breakdown of why your losing frames to the browser and how to mitigate it)
  • Need for speed – How to optimize and schedule CPU intensive operations to not turn your game into a skipping mess. (very personal example: so 2000 units all need paths eh?…all at the same time?… can you have a negative FPS?)

I suspect te bulk of these posts will be a quick overview, a code sample and alist of ‘Gotchas’ that I kept running into. That’s the sort of stuff I’d like to find when I’m researching a problem, so I’ll assume that’s what everyone else is looking for as well 😉

So that sums it up for the time being, keep checking back for more updates, and thanks for reading!

Faster and prettier

Mini update!

I fixed a glitch in the pathfinding scheduling, so that framerates should improve with larger numbers of zombies on screen (end game scenarios).

Also, after receiving some great feedback from the Mochi forums, I’ve added a tooltip feature when multiple units are selected, so one can more easily pick out the individual unit from a group.

Quick Start info has been added to the difficulty selection screen, so first time players will have some streamlined help whether they want it or not :p

Although there area a lot more features that I would like to introduc, I think anything new will have to wait for the sequel. Oh, and I’ve started work on the next project…muwahaha.

Go Play.

-Joe out.