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

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.

« Go Back — View more posts »