Coder's Desiderata

Early March Brain Dump

It’s been a while since I’ve written a post, so I’m forcing myself to start making short updates (although short is difficult). I’ve been caught up in a line of projects since June where my free time has been slowly consumed whole with web applications and other things. There was an attempt to just take it easy and run a World of Warcraft guild, but that was short lived. That fleeting moment was enjoyed while it lasted. Hopefully I can pick it up again sometime, but it seems I need to focus on some other areas of my life and career before I can invest in leisure. I strive to bring the two together, but that is going to take time and more planning.

These past twelve months have been really interesting, and have given me some perspective. I got to experience projects as both a supporter and a leader, and while it hasn’t changed my opinions or position, it has made me appreciate how valuable communication, teamwork, and leadership are. This includes leaving the comfort of ones mind to understand another, as well as relying on trust when it is not possible to do so. Trust doesn’t mean abandoning communication, rather using a different mode. For example, communicating expectations, but leaving application to the other persons. It may sound simple, but shouldn’t be taken for granted.

The main project we worked on was successfully launched last month, followed by a rapid release of a sub-product a couple weeks later. It took a little over six months from technical planning to completed implementation. There were some interesting challenges. Firstly, this project had a hard deadline, which we typically don’t have. There was no room to push out milestones. Secondly, we started from scratch and with a completely custom framework (although later replaced). And lastly, our project lead fell ill mid-project at which point I took on the responsibility. Our team was amazing, and pulled through when defeat was all but inevitable. There was a sense of perseverance and tenacity held by everyone that made the project a success, without those attitudes we would have surely been behind by a good month, if not more.

Anyway, more updates to come. I’ll be adding some posts about the framework we implemented for this latest endeavour, along with some other stuff I’ve been meaning to post.

Canabaliced

I’ve started a game project with my wife, who is a 2d artist. Among the titles we’ve thrown around, Canabaliced (Canabal – Iced) seemed most appropriate. The premise of the game (so far) is you’re a popsicle struggling to survive the heat. And how does he survive? Just the way we do, by eating icy treats, including other popsicles!

The game’s theme was inspired from a challenge by Game Prototype Challenge.  We didn’t end up submitting anything, but we still got an idea to run with.  There’s a lot of ideas being thrown around, shot down, prodded, and dissected, but it’s gaining speed and direction. I see this game concept having a lot of potential, especially with the plethora of frozen treats that exist. But first things first, we need to settle on perspectives, game mechanics, and artsy things.

Inspirations

For perspective and game mechanics, I’m thinking of designing the levels similar to Teenage Mutant Ninja Turtles II and Double Dragon II: The Revenge. We’ll start off with the level mechanics of Turtles, and later add the more advanced level design elements from Double Dragon, like climbing ladders, and the slight change of terrain perspective/mobility where the characters can only move horizontally.

Weaponry will be another fun thing to play with, including melee, and… ehrm… projectile types.  It will be all out popsicle pandamonium. One idea is to have the player and enemy spit or vomit popsicle juice, with different colors of juice having their own effect; poison, “fire”, slow, etc. There’s room for rocket(pop) launchers, “cherry bombs”, and chocolate mint sprinkle somethings. I need to fit an ice cream sandwich somewhere in there too.

Maybe at some point, there will be a online two player mode just like Turtles, and Dragon.

Restocking Ammunition

One twist I am intending on using is to have the character’s main weapon use his health as the ammunition.  Any additional weapons will have a small supply of ammo,  meaning the player will need to be cautious using their weapons. The player will be able to restock their main weapon (popsicle spit) in two ways: by obtaining ammo deposits throughout the levels or by consuming NPCs (the good and the evil). I’m thinking of adding some type of morality meter for the second option, which would apply some type of consequence if the player decides to take the easy route and destroy innocent NPCs.

Conclusion

This basically encapsulates the initial concepts and ideas. I have some developments I will be sharing in some future posts. I think the biggest challenge with this game will be not to make it too serious, or filter the concept. After the idea settled, and reason began returning, I had several parental sensors going off in my head. The same ones I have to ignore when watching Adventure Time (which much of the humor is or will be inspired by). It’s not meant to be serious, it’s meant to be fun. Even so, I still want to give this enough depth to make it more then a game that you play for a few minutes and never touch again.

I’ll be posting more as we progress, including some tutorials and AS widgets. Stay tuned!

Game Jam #5 Takeways

Here is a takeaways review for last month’s game jam. This builds off of the last entry in this series, from Game Jam #4.

This last game jam was a lot of fun, and I enjoyed it quite a bit.  There’s always a lot of good ideas out there, and I’m impressed at how imaginative and innovative people can be. Thanks to the Sacramento Game Jam meetup and 5th Planet Games for making this possible!

I entered this game jam with a couple objectives in mind. First, to use what I know, and second, to complete a game within the allotted time. Now let me tell you, both of these are challenges! When you enter a jam, you don’t know what other skill sets you have available, and with this being a social event, it’s difficult to consider working by your lonesome. But that’s exactly what happened, at least at first. I could have worked with Unity, currently a very soft skill, or in Java with a framework I’ve never used before. There was even an existing team using ActionScript (my skill of choice), but there were already quite a few members. All were -very- tempting, as I was really seeking out a collaborative effort, but in the end I started off by myself. Luckily, a designer found his way to me, and I became a team of two.

The end result was a nice prototype of a top down action game we titled “Alien Blitzer”. We had a HUD, as well as terrain and player/enemy graphics. The Flixel/Power Tools helped create a functional prototype relatively fast. It was really nice how things just slid in place towards the end. We were successful in the sense that we had a functioning prototype that included the core mechanics and game play. More can be read about the prototype itself in a previous post.

Lessons to apply to the next Game Jam

The outcome was no accident.  It was a result of experiencing two previous jams/hackathon where things didn’t go exactly as planned, some research, and most importantly, the application of these things. Just like the previous jams, there are a few key things that I have taken away from this jam through trial and error, and will continue using or improve on in preparation for the next game jam.

1.) Have an idea what you want to do

Have an idea what role you want to play, and what skills you will be offering. Going in without any plan can make it difficult to form a group, and can set you up for failure. This doesn’t mean everything must be set in stone, just have a rough plan. It’s tempting to be ultra flexible, and acquire new skills on the spot, but it’s more important to produce a prototype, so try your best to make use of what compatible skills are available. In addition, if you’re up to being a leader, be ready to be step up at the very start.

3.) Create a prototyping kit

Take your framework a step forward, put together a kit that’s fast and flexible, so setup takes less time and doing  comes sooner in the prototyping phase. To emphasis, these jams are meant for prototyping. The less time you spend implementing (coding)  something the better. This means you have more time to work on polishing mechanics, content, etc. A kit that at least has the basic environment setup, player controls, and a splashscreen would be great. It should be setup in a way where it’s easy to remove unneeded features just by removing a few lines of code, you don’t want to go too crazy.

I’ve started a Flixel/Power Tools/Dame kit on github.

4.) Bring a big pad of paper, and some writing utensils

Planning is really important, and it’s easy to become lost in the flurry of  activity. Ideas, goals, and thoughts can become meddled when they’re just floating in your head. Use something physical to keep everyone bound to one reality and understanding. This would include sketches, lists, or written words.  Something to avoid misinterpretations or deviations from what really needs to happen. Putting things down on paper helps out a lot, and I know for at least myself, it helps eliminate fuzzy logic that sounds good at first, but falls apart when it comes time for implementation (doh!).

5.) Map out your time

Time runs out fast, like super crazy fast!  It’s crucial to plan out how you will be using that time. Make milestones, set check in points to touch base either individually or as a team. Break out the project into parts, and then iterate through each part throughout the jam in cycles. Select the most relevant pieces first, estimate how much time it should take with some fudge room, and communicate that to all team members. When the time has past, evaluate the progress, and if the feature isn’t complete, decide if it needs to be rehashed, or if it’s best to continue plugging away at it. There should be a beginning, middle, and end to the complete development cycle. Make sure to segment time before the end of the jam so you’re not making a mad dash to get everything together last minute!

6.) Take snapshots

If you reach a milestone (wohoo!), backup your work (on all machines) so that if things go awry, there is something to fall back on. This should be something that can be done simply, and quickly. While version control systems such as Git or Subversion may sound like a good idea for something like this, they probably aren’t. You don’t want the overhead of working on merge conflicts or other possible version control specific snags. A simple copy and paste should do the job.

Conclusion

Taking steps to organize yourself and be more prepared are ingredients for a better experience all around. I look forward to seeing the results to the next jam, as I apply these new tidbits to my next game jam.

I’m curious if anyone has extensions of what I’ve mentioned here, or any additional tips.

Alien Blitzer

It’s the year 2600, and you have embarked on a voyage to find new alien artifacts in order to advance your civilization. The only problem is, the planet you are excavating on is still inhabited, and its natives aren’t too happy that you’re trying to take their stuff!

This is the premise of Alien Blitzer, the product of an afternoon of game jamming. It was built from concept to prototype in a 6 hour period with the theme of “Evolution”. In this post I just want to explore the game itself, and influences. I will be going over takeaways separately.

The Game

Here’s a slightly cleaned up version of the game. This is what we finished up with, with the exception of bugs,  a couple minor visual things, and the intro screen. While incomplete, it was a nice prototype for the given time with two people . I coded the game in ActionScript while Josh Flash created the HUD and sprite graphics. I’ve included the demo and source below, although I warn, the source isn’t pretty.

Demo | Source

Mechanics

Core mechanics are pretty simple, you have your arrow key movement (up, down, left right), and projectile attack. Ammo is expendable, so the player must collect ammo as they make their way through the stage. And there are also aliens the player must dodge or destroy.

One of the inspirations was the old NES title Legendary Wings. It looks as though I borrowed a few ideas, although not necessarily intentional. These include player controls, enemies, and weapon power ups. It may not look as much in the prototype, but that’s where things were going.  The weapon system is intended to share the same weapon “evolution”,  giving the player a more powerful weapon as they collect items. In addition, the baddies are intended to have a more elaborate  movement, opposed to the straight lines.

Getting Technical

Alien Blitzer is built using Flixel, and a small set of other tools. Here’s a quick break out of what was used.

Controls – Player movement and attacking is handled by Flixel Power Tools’ FlxControl. For prototyping, this library makes things super simple as long as you’re looking for basic controls.

Tile Mapping – The tile map was put together with Dame Editor, and is made up of a few layers for the ground map, water, and mobs. The mobs needed some extra processing with ActionScript so they weren’t all part of one entity, and are activated by distance from the player. I was looking for something built into Flixel or Flixel Power Tools to more eloquently detect and trigger an event for when the object was on screen, but wasn’t able to locate anything in time.

Hud & Sprites – Graphics were created in Photoshop. They snapped in really nicely, replacing a bunch of  ugly colored blocks that acted as placeholders.

Intro Screen – The intro screen uses Flixel Power Tools’ special FX, and Greensock’s TweenMax for the animation loop.

Future Tasks

I’ll be using what I learned from this game towards future games, including an upcoming prototype. Here are some points of focus in the near future:

Polish – The player controls and mob speed really needs to be tweaked so that thought can be put behind shooting the baddies. Maybe even some reworking of sprite proportions. As it is now, by the time a mob comes into view, you don’t have enough time to move into position to kill it. The level itself also need to be extended, it’s pretty short.

Sprite Management – I’m playing around with managing mob sprites in Dame so that there is little need for extra coding. This will make the polishing mentioned above much easier. Dame gives the option of creating several ActionScript classes that cover the tilemap/level, sprites, and interaction between these objects and the rest of the game. I intend on playing with paths and “trigger” tiles, which can effectively guide or alter sprite behavior, but I’m not sure if I can fit those into this game.

Music – Adding music has been a struggle. At first I was running into bitrate issues, but now it fails silently. I’ll want to add sound effects, and soundtracks in the future. Overcome I must.

Conclusion

There you have it. A review of my latest prototype. It has opened up a few more avenues to explore, which I’ll be writing up posts for as I go on.

I’m curious what technologies here others are using, or maybe want to learn. Input is welcome.

Game Jam #4 Takeways

At the end of April I had my first Game Jam with our local Sac Game Jam meetup. It was loads of fun, and a valuable experience. For this jam series, all teams start from the ground up, beginning by deciding on a game concept, mechanics, and then building out the prototype. This is all done within a relatively small period of time (around  6 hours), and at the end we all demo our creations, for better or worse.

My team went with a tug-of-war concept, and we used ActionScript using the Flixel framework.  We consisted of two ActionScript programmers, and a graphic designer. Let me just say, graphic designers are awesome. We were lacking some key equipment, so we restored to taking photos of the hand drawn images using a cellphone. Low tech, but it worked out. The paper cut-outs had a neat look too! In the end we made a mad dash to make things presentable, and while we had something to show, there was more we had wanted to include that didn’t make the cut.

There are many pitfalls that can be encountered throughout the prototyping process which can snare both newbie, and experienced jammer. These traps can be enticing,  often giving the facade of being critically important (“the game will be nothing without this!”), and in some cases of no importance (“we can figure this out later”, “this will be a snap!”). These can be avoided through preparation, planning, and restraint. Here are some tips I’ve gathered from this experience that I found noteworthy and will apply in future jams.

1.) Come prepared, don’t learn the framework at the game jam

There should be a basic understanding of how to use the framework,  not mastery, but some familiarity. The key issue is you don’t want to be spending chunks of time struggling with a mechanic or feature. This will eat up what little time you have like Pacman.

2.) Prototype, quick and dirty

Don’t worry too much about what it looks like, in code or graphically. You’re strapped for time, no one is going to care if it’s all nightmarish spaghetti code (*shudder*). Ya, it would be awesome if you could OOPify things with Player->doSomeAction(enemy), but you may be complicating things, which results in bottlenecks further down the line.  Make everything public, keep it in a single file unless absolutely necessarily.  In addition, don’t worry about animating sprites, or anything like that. This is just a prototype to give the idea of what you’re game will be like. Resort to using colored blocks and shapes if need be. Prototype like the wind!

3.) Start with simple game mechanics

Decide on core mechanics within the first moments of the jam, and keep those mechanics simple. It’s really easy to get carried away with game mechanics and lose sight on your main objective. Mechanics that require conditions and checking (ex. buff/debuff system) should be boiled down to something more manageable so that it doesn’t become a hold up. Even if the mechanics sound too simple, stick with them until it’s been implemented. If they really are that simple, you will have time to expand and add.

4.) Divide up features when working in groups

Working with another programmer adds a layer of trickiness. You now have to be careful of not stepping on the other fellow’s toes. Avoid overlap, and give ownership to features. Break things out logically like movement, item collection, and enemy collision. This is a practice that should be started at the very beginning so that there is a minimal amount of duplication.

5.) Be ready to share your stuff

When working with a group, be sure you have a way to efficiently share code at any time. There are many services out there, such as DropBox, but it doesn’t have to be that fancy. E-mail will work just as well. If you don’t have something setup in advance, resort to what ever is the most effective that doesn’t take long to setup. Advanced forms of code sharing, such as version control (Subversion, Github) may be tempting, but should most likely be avoided due to complications that can arise, such automated merging, and conflicts. From a coders perspective, you should know what is being removed or added.

Conclusion

Well there you go, a handful of pitfalls to watch out for from a great learning experience that was Game Jam #4.  There will be more that I will be sharing as I journal more past and future jams.  The important thing is to keep looking how to improve yourself, and most of all to have fun.

Thanks go out to GameDevRadio.net for their podcast on prototyping (and others).

« Go Back — View more posts »