That being, to showcase our games to potential sponsors and licensees, so that they’ll buy customize versions and thus the cycle of capitalistic life will be complete, hooray.

More incremental updates will trickle in from here, but by and large the design is complete.

We’re closing in on a Primary sponsor for our latest game (Now with 3000% more ninja goodness), and once the negotiations and customizations are completed, that one will finally be unveiled to the world.  Good times.

The process of creating this game has been very enlightening for me personally, and has opened some doors that make the prospect of cranking out content at a much faster rate a real possibility.

I’m a coder/designer (and marketer) really,  anything that involves picking apart logic problems and discerning patterns to ferret out solutions is my wheelhouse, not so much with creating unique art from scratch.

Sure, procedurally generated assets are do-able, and abstract interface elements are something that my skillset allows for (hence the site re-design) but character drawings, compositing a landscape, or sketching out pretty much anything that lives and breaths just ain’t gonna happen.

Recognizing that limitation, the soon to be announced/released title is the first project on which I’ve worked with an artist, rather than trying to stretch my skillset in that, rather painful, direction.

The presentation and design of the game as well as the design and development process have all benefited, and I  am very pleased with the results.

The artist and co-designer I’m working with is an old friend who happens to be a ridiculously talented, Alex Rodriguez.  We’ve already moved on to design and development of our next title, so keep an eye on this space for further announcements about the soon-to-be-released and future project updates.

-Joe out.

I haven’t really chatted on here about the Plunk Pool games, which is an unfortunate oversight on my part,  as they really have been an interesting experience, from which I have learned a bit about the business of flash games.

To be honest, my first love is the more involved and intricate games, an RTS, a dungeon crawling adventure, something along those lines.  The Plunk Pool games are essentially an exploration of genres that I myself wouldn’t get deeply into (puzzle and/or sports games) but that I know do well and have a wider appeal.

So far, the ”franchise’ has done pretty well.  The original Plunk Pool game has registered well over 3 million plays, and the second plunk pool will no doubt do the same (once a few key portal versions go live later this week hopefully)

They were really fun games to make, much to my surprise, and writing the physics engine taught me alot about geometry and Actionscript optimizations.   I may be coming back to these games eventually, if time allows, but the next project will have more in common with the dark and scary theme than the family friendly generic game theme.

I’ve put LotD2 on hold for the time being to work on a couple slightly less ambitious projects that are in the chute now.

The most immediate project is still too early in production to announce, but if all goes smoothly, it will be the first project on which I have collaborated with an honest to bob artist, rather than relying on my unpracticed art skills to get the job done.

More to come…

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.

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:
  • OLD: NEW:

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!

Rolled out the first iteration of the new site design for Luncheon Of The Dead.

This will represent the new template within which all the future games will be published.

As it uses PNG for all the graphic resources, IE 6 and below does not look very good at all. Get Firefox.

Go check it out

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.

Oh yeah, I did retool the attack cycle mechanics so that the units will attack at the first opportunity rather than waiting for their arbitrary attack slot. I’m most probably the only person on the planet that will notice this.

That is all. Go Play.

-Joe

That means improvements to the game generally speaking, but the core gameplay remains relatively unchanged.

The biggest difference is that there are now 4 difficulty levels to choose from, hopefully satisfying the power gamers and the n00bs alike.

I had to overhaul the High Scores database to accommodate this change, and have updated the High Scores Page (in a ham-fisted sort of way for the time being) to display the new tiered score system.

An overhaul of the main site is in order shortly, to replace the fairly amateur looking front page that I threw together in between the ticks. Keep an eye out for that.

I think that sums it up for now… Go Play.

I’ve just finished implementing a MASSIVE update to the game engine, effectively changing the entire focus of the game. The quick and dirty version of the changed is that I’ve added a ‘tech tree’ giving players an upgrade path for almost every tool in their arsenal of zombie killing goodness.

Now for the more detailed breakdown.

These upgrades (outlined in the embedded instructions of the game) allow you to update global properties of Debris (making it tougher) and Molotovs (giving them a larger area of effect…kaboom!), as well as upgrading the raw firepower of your individual Defenders (in the form of damage per shot, and rate of fire), as well as their max health and scrounging skills.

The Max health is a relevant change for survival as well, I’ll go into that in a second.

So basically these upgrades (which have a cost per level in Ammo, Medikits and Debris) give you something to do with the mounds of supplies harvested that exceed the bare minimum needed to survive. The Defender upgrades are applied on an individual basis, so you can make a few super-soldiers and a few harvesting machines, or spread the love around evenly, or anywhere in between.

Now, as for the max health, that relates to a change in the mechanics for taking damage. Previously, if a defender was damaged, and reduced to zero health, it would still heal the damage if there was a ready supply of medikits. NOW, if a defender takes damage that DOES NOT REDUCE IT TO ZERO HEALTH, healing will still happen. However, if a defender is ‘killed’ in one hit, that’s all folks. So you have to upgrade toughness to keep from being one shotted by powerful zombies as they get tougher as the game progresses.

Oh yeah, I’ve also redone the graphics for the zombies and defenders, so they are not quite so small, and are more well defined. The stores have been opened up just a tad, and I think that should eliminate all of the cheesy terrain exploits that were inherent to the more closed floor-plan of yore.

Numerous small bugs have been fixed as well, such as the problems reported with lazy defenders that had to be jump started from time to time, and an option to set graphics quality has been added to UI. So for those with slower machines, try toggling to ‘Low’ quality to increase framerates.

There are a few miscellaneous polish items added as well, but not worth enumerating here.

That should sum it up… now Go Play.

Essentially, I reintroduced some higher res sprites, that I had previously down res-ed in my quest for performance, turned out I was optimizing the wrong bottleneck. So that mistake has been repaired.

Also, the embed size of the flash movie at the game page has been restored to it’s full size 800×640 glory. I am assuming that the type of folks who will be playing this will have monitor resolutions larger than 1024×768 so as to accommodate the larger size, if not, comment and I will see what I can do.

I got rid of the Chiller font in the in game HUD items, as it was not terribly readable I don’t know why I had clung to that choice until this point…maybe just amateur petulance. Live and learn.

Also, I changed the selection mechanic for Defenders so that it auto-queues the move command when selecting units. Subsequent move command must be queued up normally, or one can re-click the unit to re-select it and re-queue the move command. Confused? Just try it out and it will make sense. This was the compromise brought about by the fact that Flash monopolizes the right click in it’s player context menu (right click normally being used to issue command in a RTS) and the left click (typically used to de-select all units and do camera movement or building placement in RTS) is the only way to interact mouse-click-wise. So I had to go with this less than perfect compromise. But it is an improvement, so life goes on with another note made in the ‘Idiosyncrasies of Flash Game Development’ list I keep in my head.

That sums it up for now. Now Go Play