Coder's Desiderata

Out of Phase: Global Game Jam 2015

This is the first post in a series that will reflect on the project from various stages, covering pros and cons of the creative process and implementation of the game. This review is a long time coming, it was originally started right after the 2015 Global Game Jam.

In January I broke a lull by participating in the annual 48 hour Global Game Jam. Prior to this jam, it had been some time since prototyping a game of my own. Game jams in general are a great opportunity to break creators block and start fresh.

I started a project called Out of Phase. The original idea was to create a two player game that involved a series of puzzles contained within chambers, similar to Portal 2. There was a twist, where the environment was slightly different between the two players, requiring them to communicate between each other to solve the puzzles.

At the end of the 48 hour jam, I produced the first version. While not complete, it still gave an example of the general concept with a couple puzzle examples. Two players were supported through a local co-op mode, where chracters were toggled by hitting the tab key.

For this post, I’ll give a general overview of the tools and design ideas that took place at the Global Game Jam.

Framework

It’s a good rule of thumb in game jams not to build your own framework. Your focus is on producing a game, not a toolset. Phaser.io is a real snazzy HTML5 game engine/framework. It comes with a tilemap loader, collision detection, WebGL support, and a plethora of other goodies to make life easier.

Another guideline with jams is to know your toolset so that you’re not wasting time figuring out how to use the tools. I only had a little experience with Phaser.io prior to the jam, so I didn’t follow this one completely. However being very experienced with JavaScript and the concepts that Phaser.io is built on, I was able to get started very quickly and iterate through ideas easily.

One problem I ran into early on was selecting the wrong physics engine for collision detection. This set me back a little, but helped me learn the differences between the P2 and Arcade systems. In Phaser.io, you can actually have more than one system active, so they’re not exclusive to each other.

Continue Reading »

Game Jam #7

Reeeally late in posting this, but I’m determined to post about my game jam back in July where the theme was time manipulation. The dynamic was a little different, I had an “idea person” to help move the creative process along and blocks. I was paired up with Jacq, sound engineer and creative mind. After a few iterations of rehashing the fundamentals of our game, we finally came up with a platformer that fit  the theme. From this experience I had some takeaways to apply to my next jam.

Idea People are AWESOME
Having a person to handle the brainstorming while you’re coding has its benefits. It’s easier to cut and run when hitting a wall, as the other person has already been thinking into alternatives, opposed to wasting time on something that just isn’t working because you don’t have any better ideas.

Skillsets can become dusty
This was a frustrating lesson to learn. After not touching Flixel for a month and a half, working with basics like movement and sprite placement was more difficult than it should have been.

There’s an easier way to prototype
My toolset has been pretty low level. I use ActionScript, and while I utilize the Flixel framework with libraries, it still requires a lot of coding. At the end of the jam I surmized I would have developed my prototype faster with a prototyping framework such as Construct 2 or Stencyl.  Both allow the rapid prototyping of platformers, such as this one without coding.

For those interested, the source and demo can be found here:
Source
Demo

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.

« Go Back — View more posts »