Global Game Jam 2015 - Mahou Shoujo Idol Strike!

It's that time of the year again! This was my fifth GGJ in as many years. Although I have gotten lazier when it comes to other jams organized by our game dev club, I have at least consistently participated in the biggest and baddest. Results may have varied... Anyway. Let's get into this. This is divided into a few sections - the first one is a bit more self-reflective, and it's about game ideas in a jam environment. The rest are about this year's project - which I'm sure you are dying to read about after reading that title.

1. About ideas

Let me just start by reminding that this section is kinda self-reflective and massively opinionated. So keep in mind that the most important thing when it comes to game ideas at jams is to do whatever the fuck you want - you are there to have fun after all. However, I'll be a bit more philosophical. Game jams are learning experiences and to that end, you may have some kind of a learning goal. Maybe it's to become better at your chosen profession, or maybe it's to try something new. I'm a decent programmer, but when I go to jams, I go there to work on something that has a fresh design. Therefore it is incredibly difficult for me to understand why anyone would want to spend their weekend making an underdeveloped version of a game mechanic that has already been developed by actual studios or indie developers. I do realize of course that it may be an interesting technical challenge just to see if you can get it done. Likewise if it's your first jam, simply getting any game done at all can be exhilarating.

It may be a pessimistic to way to look at things, but really, after too many jams, I seriously don't expect a jam game to be good. Like, at all. If your goal is to make a great game in 30 hours, prepare for a lot of failed jams. For me, personally, the measure of success is whether I got to try out something different or not. Probably this is why I have worked on my own idea in every jam so far - it's usually some mechanic that simply intrigues me too much. That, and a lot of the ideas of others have generally failed to inspire me. Again, this doesn't mean they are bad (indeed, the outcomes have often been more fun to play than mine) - I just feel like their owners have different goals for the project than I have. That, or I don't really see the game from the pitch. I think I actually found a way to work on the latter this year. Normally I would just think about some ideas by myself, or even leave the entire site to get some food or whatever.

This year, I was originally supposed to lead an "idea hotspot" - kind of a brainstorming table. We kinda failed at organization tho so we ended up not having them. Instead I just rotated around, asking people to throw their ideas at me and gave them some additional questions to chew on. I found this a nice approach actually. It gave me more insight into what others were thinking, and also may have helped them get a bit better grasp of their concepts. So this year there actually were a few other projects I might have joined. I'll have to admit, I kinda cheated this year. Literally three hours before the jam I was struck by an obnoxiously sticky game idea and I was unable to get rid of it. It prevented me from coming up with any new ideas of my own during the brainstorming time. I guess talking constantly about other people's ideas also kind of hindered my own thought process. So, anyway, after a lot of consideration I did pitch that idea... I felt a little guilty about it, but at least it was an idea I got on the first jamming day. Even if it was before the event started.

There was another reason too. Let me sidetrack a bit to say that the theme this year was absolutely fucking horrible. "What do we do now?" is a non-theme if I ever saw one. Either you come up with some incredibly bonkers artsy crap (not that I mind, I like those), or, well, you can pretty much encompass every single game ever made within this theme with very little mental gymnastics. The games made at our site this year didn't really connect in any way. It was just literally a bunch of random games - not take anything away of course, some of them very really good. Anyway, I wanted to bring this up because - like every single idea in the universe - my sticky idea from a few hours ago actually fit this non-theme. It even included the plural "we" in form of four characters. It still felt a bit stupid to fit an idea into a theme, not the other way around. So yeah, I decided to just throw it out there. And for the record my pitch was effing horrible.

I generally fail to attract workers to my cause because my games are described through their mechanics. I guess that's a bit unattractive, and they don't sound all that wild on paper. It's actually quite hard to see an abstract mechanic if it's being described to you - you can try this by reading a board game rulebook without access to any game components. This time my idea was inspired by two sources that typically get reactions one way or another: Asian pop music girl groups and the "magic girl" manga/anime trope. So even though I did a terrible job with my rambling pitch, I got the interest of one artist and one sound guy (who, curiously enough, hated j/kpop). Coincidentally that was just what I needed, so once again I ended up developing my own idea but this time with a team. So, just a casual takeaway: even though I mostly care about mechanics, I shouldn't rely so much on appealing to everyone else's inner designer. Instead, I should work more on sticking a crazy theme on top of my mechanical idea.

2. The game

I got the idea entirely from listening to kpop. More precisely, I was listening to Kara at the time and my tired mind wandered back to some recollections of their music videos. Suddenly I found myself wanting to make a JRPG battle system where all characters would move as a group, abiding to a dance choreography. In my mind it was more like a tactical RPG, even though the pop music connection might make most people think rhythm game. However, for me the core concept was careful selection of dance move patterns for the group as a whole. I also played around with ideas about having kpop-inspired roles for the characters (leader, lead singer, lead dancer etc.)  and the fact that the singer alternates frequently. Again, as my mind was already racing towards an RPG, I needed some connection between that and kpop. Probably as an indirect result of exposing my mind to too much Persona 4, it went straight towards "witches who use pop performances to fight evil" - there's probably a legion of animes about that already.

Since it was to be made into a game jam concept, some chopping down had to be involved. I kept the essential parts: there would be a group of characters and they would move in unison; each turn the player would choose from a handful of available patterns. The girls would need to move over specific tiles to activate their magical powers - this was intended to form the puzzle element of the game. Ghosts were added to the concept too. In the first iteration, the concept was like this: the girls would try to avoid ghosts while picking up power-ups; after doing so, they can cast magic to banish nearby ghosts. The interactions were quite simple, which made the basic game code very quick to write - a boon if you want to work on complicated mechanics that need a lot of rethinking. Most of the design complexity came from juggling two things: what happens on the board, and what moves the player has available at each moment. A bit of a rematch with problems I had when working on Pulselight Steampunk.

For once I even came up with a relatively straightforward way to make a tutorial: the first set of actions was a preset, and the player would see the key interactions by performing them in the given order. So at least in theory you could just tell players to press 1, 2 and 3 in succession and watch what happens. In practice the game is a bit harder to understand because the player has to follow four different characters at the same time. That in itself is fine, and gives the game a healthy dose of cognitive challenge. It became a bit problematic because for most of the development time the game felt insanely random. Only four actions were available to the player at a time, while there were like 40 actions total. The chances of having only useless (or worse) actions was staggeringly high. It didn't help that everything spawned on the board in random locations. Often, after just a couple of moves, the player was stuck with no way out.

Figuring out solutions for this problem became the essence of my game jam this year. I quickly changed some of the interactions; primarily, the girls were now able to defeat ghosts by running into them in addition to casting spells, and the ghosts could only spawn at the borders. This called for a new lose condition, and I ended up with "defend the center". So the ghosts would try to conquer the center of the board. I also fiddled around with how moves were offered to the player. I divided them into a few different categories and then made the game rotate between categories, basically guaranteeing different kinds of actions regularly. The end result feels mostly like a game where the player can actually control stuff. Still, the feeling of getting screwed over by the game is too frequent. I'll outline some next level ideas to improve the game in the next section. Before that, just a few words about its development.

Our team of three people worked quite well. Which, of course, is quite simple to do when everyone has a clearly specified set of tasks. The game's core was also really fast and easy to implement - it was pretty much done in like four hours. This is something that I highly prefer because it leaves a lot of time for fiddling around with design concepts. I also had time to code all kinds of luxury functions like support for animated visual effects. We were initially going to include a tilted perspective instead of a straight top-down approach, but improving the design took priority in the end. That, and one arcane bug that I managed to include in the code. Despite locating and fixing two different instances it, it's still present somewhere in the code. As usual I only have myself to blame for that. It's just one of those "what could possibly go wrong" things when writing game jam code.

I have found CraftyJS to be an amazing library for jam development - if you have learned it beforehand that is. There are two reasons for this: its component-entity model, and its event model. Crafty keeps track of all created game objects, and allows the developer to query them based on their components. Which means there is never a need to keep track of references, because you can always fetch them from the core object. I hate passing references so much in object-oriented programming. Passing a new reference down a few function calls already requires modifying code all over the place. Using events handlers over method calls has the same advantage. You just register a handler, and then can trigger the event from wherever you want instead of - once again - messing with annoying shit like references. Overall, not giving a damn about references speeds up development and makes it generally more relaxed.

I do think there is a downside to sticking with CraftyJS though. It only does 2D, which is a bit of a hindrance these days. Not that I'm particularly interested in making 3D games, but I should at least be able to do so just in case. Of course another problem with the library is its horrible documentation, which makes it hard to learn - definitely not ideal if you work with other programmers. So yeah, one day I should really learn how to use Unity3D.

3. Idol Strike! Next!

After the jam I thought of some ideas to make the game feel less random. Having too many random things in jam games is one of my personal faults. It's just really tempting to generate stuff randomly because actually designing levels takes a lot of time and it's not exactly as exciting as creating new game mechanics. However, I don't really see a way to make this year's game better without seriously chopping down on the randomness. Furthermore, if it were to find its way into its original role - to become a battle system for an RPG - it needs to incorporate way more customization options for the player. First of all, instead of being an endless score attack, the game needs to have clearly defined levels with specific challenges. Moreover, things like power-ups should be in fixed locations to incorporate any sort of actual planning into playing the game. Probably the same should be done to enemy spawns.

Something definitely needs to be done about randomizing available actions too. I want to stick with the idea of dance routines on this one. Instead of offering random patterns, there would be four different dance routines, each with its own fixed sequence of moves. Each turn, the player would choose one dance routine to follow, and could then choose to follow another on the next turn. The key here is that there would be a way for the player to see ahead at least a few moves or the entire routine (which could actually be just four moves actually, and then loop). To encourage further planning ahead, there could be some bonus for sticking with one dance routine for an extended period. Overall the key to making this game better is to a) provide the player more reasons to try to move to specific parts of the board; b) provide the player better means to get the girls to go where they want them to.

This way would eventually turn it into a puzzle game where the player would try to complete levels. Once the basic mechanics are neatly fixed, the concept can easily be expanded. More types of enemies are a no-brainer. Likewise, there could be more than one spell available in the game. For instance, there could be other banishment patterns than just the present "surrounding tiles" approach. After that, it's not a huge leap to make the girls individual by giving them different advantages. Thinking about extensions too much is generally detrimental though, so we might as well stop here. This section was just a short demonstration how exploring a game mechanic in a game jam game can lead to further discoveries and may, in the end, be a more valuable result than a more complete, more conventional game would have been. Contrast this to my "easiest" jam game Umbrella Dream (simple platformer) - sure it was easy to understand and kinda enjoyable to play, but I gained nothing at all from making that game.

Conclusion

So, there's one more game jam under my belt. Once again I worked on something that deviated from standard genre conventions and as a result had my hands full trying to juggle everything into a game. Success in making an actual game was partial. The jam itself on the other hand was fully successful. We were able to bring a new mechanic into light and see how it worked - which it did. This time the game around the mechanic just fell a bit short - but that is also a success because I was able to pinpoint how it went wrong and at the same time understand better why I've experienced similar failures in the past. That said, the chances of actually continuing development are kinda low based on prior experience. I do consider this particular project to be among the more interesting ones in that regard though. Nevertheless, just thinking about game experiments I have made in a reflective fashion at least keeps me in the right mindset.

Anyway, I think that's enough about this year's GGJ. It's time to get back to the side of games I am more comfortable with: playing them, and writing about them. Thanks once again to Stage for setting up the jam site, and of course to everyone who was there contributing to the atmosphere. This year's jam site had just enough space and people filling that space.

Global Game Jam 2014: Squared Interactions

I wasn't particularly enthusiastic about this year's GGJ because I have been so tired lately. Something to do with the Finnish winter perhaps. At least I went there, and even finished a project. I have skipped a few game jams due to various reasons from lack of energy to health problems in the past year and I think the last one I actually went to was last year's GGJ. Once again I had grandeur plans of joining someone else's project to save myself some headache...

Here's the game (webkit browsers recommended)

1. Theme and concept

This year's theme was a phrase: "We don't see things as they are, we see them as we are." My mind was pretty much screaming to do something artistic, something with a healthy dose of mindfuck if at all possible. I was chatting with some random people about possible concepts and among the more interesting ones was a bureaucracy game in the spirit of Papers Please but it was deemed too content-intensive. In my head the concept was somewhat reminiscent of Brenda Romero's Train - can the player see through all the paperwork what harm will befall the applicants if he follows the rules blindly. Other concepts I thought of were somewhat similar; the general idea was: it would be up to the player to decide what the game is about. The final piece of the brainstorm puzzle came from the diversifiers. 

The diversifiers were published a few days before the jam. Initially I was thinking one of them felt like it didn't belong to a jam: the Bechdel test one. I felt that way because dialogue is very rarely something you want in a jam game. Naturally I chose to pursue this diversifier but not through written dialogue: I wanted to make a game that's an abstraction of a conversation. My inspiration was The Marriage and I also wanted to use nothing but simple boxes for my graphics. I figured the game would have two squares representing two women (originally pink boxes) and one representing a man (blue box). The squares would move based on some rules that allowed the player to guide the conversation. If either pink box ever hit the blue box, the game would end. I wasn't entirely sure what the exact mechanics would be but I felt it was a concept worth pitching.

Pitch we did. Once again I was slightly disappointed at how ordinary most of the concepts were. Platformer, point-and-click, area control... some sounded also a bit too ambitious. There were two other concepts I considered working on instead of my own: a fridge magnet poetry game and a button mashing game that where the idea was to use player inputs throughout the game to produce a song or something like that in the end. We had some plans to form an art game coalition but nothing game out of it ultimately. At this point I was still not sure if I really wanted to even do this jam but I stayed on the site to see what people were up to. I didn't even take out my computer - I just worked inside my head and shared some design ideas with one organizer who I recruited as a co-designer. 

In the final design I actually combined all three of the more artistic game concepts. Unfortunately I didn't find the person who pitched the poetry game idea earlier but I proceeded to assimilate the mechanic anyway. So the final design: the squares would move independently to depict the living nature of a conversation. The player would influence the behavior of the squares by dragging words from a word pool into the topic area. Placing a word would change something: size of a square (ego) or its speed (enthusiasm). Finally I decided that ego-inflating words would also push the other square away. Likewise, ego-reducing words would attract the other square. Enthusiasm was affected by discussion topics - each square liked a random set of topics and disliked the rest. The dynamics I planned were quite a bit more complicated than what you'll see in the outcome but the concepts of ego and enthusiasm are there. 

2. Development

I once again chose to use CraftyJS. I have tried a few other JS game libraries in the past year but there has been no real advantage over Crafty with any of them. Best stick to what I know. I worked with a rather lazy pace on this one. The concept itself was very easy to implement but like always, I managed to create some hard to detect bugs. I had great plans for how the squares would move, including having them connected to each other with a rubber band. Ultimately I didn't feel like dealing with all that math and went for something very simple. Honestly it doesn't matter that much in the outcome. There's really not that much to talk about development this year. I was done in about ten hours which is like twice as much as a project of this scale should have taken. I took the laziest possible path in every turn and my code was really sloppy.

I didn't use any obvious color does for the squares and it's probably very hard  to figure out how the game works or what it's all about. I dropped some hints like the game ending in failure if any word that somehow means a man is chosen. When the game ends through one of the squares touching the third one, the end screen has another hint: "The third party interrupted". The fact that I ticked the "The Ultimate Bechdel Test Survivor" diversifier is another hint for those who actually look at the game's GGJ page.

3. Hindsight

The game turned out very hard to really control so to a casual player it will seem completely random. It was not intended but it doesn't really bother me that much either. In a way it's a meta-commentary about by jam games in general... they are always too hard to get. In a sense the real focus of this project is the word game. When the game ends, the words the player put on the topic area are brough to focus and it can read as a very weird poem. There's a lot of room for creativity because words can be placed freely, and there are a lot of words for each game mechanical meaning. As a mechanic it feels new. It's also a different perspective into game outcomes: the outcome is not the final game state in itself - it's made of the player's input history instead. I think it was crucial to bring the "poem" into focus when the game ends. This draws the player's attention to it, and makes it feel more like their creation.

I really liked this dynamic between gameplay and creativity. If I were to do this game again, I would change what the game is about to something less abstract and random in order to give the player more incentive to think about which words to choose. This word mechanic is also excellent soil for all kinds of easter eggs. For example, choosing the word "end" actually ends the game. Similar hidden meanings could be attached to more words which would make the game more delightful to explore. In a sense there would be two layers to the word game instead of one: each word represents a category, but they also occasionally do something else. Whatever the game concept for this control dynamic would be, it definitely needs to be slower than what I did in this jam. Choosing words is a ponderous action, but the squares move constantly and pretty fast too.  

Conclusion

Although I didn't spend even half of the allocated time, I'd call this GGJ a success. The game I made is not much to talk about, but as an experiment it was successful. In a way this game is truer to the GGJ spirit than any of my previous games (well, excluding this) because I really tried something different with no fear of failing. It's hard to break free of doing games with familiar mechanics. Especially in your first game jams, you probably want to really make a game that's fun to play instead of some crazy experiment. Familiar mechanics are easy to implement, and they have been proven to work. Experimental mechanics might be easy to implement like in this case, but making a functional game with them is another story. It is however worth trying.

As a final note: it's not always necessary to tire yourself out using every minute you humanly can in game jam. It's perfectly okay to have a shorter project and get more sleep. After all, most game jam games are done for their creators and will be forgotten by everyone else anyway. Just do whatever you want. 

Global Game Jam 2013: Pulselight Steampunk

A new year, a new Global Game Jam and a new game! Hindsight is fun, so let's do this post mortem thing again too. Once again our local game development club Stage came through with the arrangements, and we got ourselves a jam in a perfect location. I think this was our biggest jam so far, which was cool. There were also more jammers who were not university students, which I also found to be nice. It's nice not feeling like the only ancient mammoth when getting a decent amount of sleep during the jam.

1. Theme, concept, pitch and teaming

GGJ continues its (new) tradition of artsy themes. Last year was a picture, this year a sound. The sound was a human heartbeat. When browsing through the jam games this year, expect to see a lot of hearts and blood. The same happened last year with the Ouroboros; there was a snake in a whole lot of games. Any good theme can be interpreted in a wide variety of ways. Since I immediately knew that a lot of ideas will be focused around the "heart" part of heartbeat, I decided to put more emphasis on the "beat", or - as you might guess from the title - pulse. I have been playing quite a bit of Stepmania recently, so my mind immediately rushed to think about rhythm games. Quite soon I was once again on my way to a puzzle game design, where the player would need to perform actions while staying in a given rhythm somehow.

The idea quickly started to form around a pulsating light, in the middle of the screen. The player would have to do something with the pulses sent out by the light. But what? Well, how about guiding each pulse to one or more targets? At this point there was quite a lot of Pipemania in the design, so much that the name was indeed dropped during my pitch so people would have an easier time following what the f I was rambling on about this time. The challenge in the game would be to build the power grid fast enough to hit the targets. The challenge for me personally was to somehow present this idea to people so they could understand it. That was quite the challenge indeed because no whiteboard was available during pitching (we had one, but we were supposed to write our project working titles there).

The problem with pitching is often the inability to convey a mental image of the game being developed. Especially if it is a more abstract thing. It is easy enough to convey an image if the game is "platformer with this and that gimmick" (which covers what, 30% to 50% of all jam games?) Of course sometimes the designer doesn't really know yet what the game is. My tip for pitching your game idea in a jam is to tell what the player does in the game. That is the most important thing; without that knowledge it is impossible to see the game. Some people don't need to see the game to get into an idea of course. Indeed a lot of people will be happy to just hop aboard some cool thematic aspect or a general concept of the game. Then there are people like me who want to get an idea of the game's mechanics. I call us "mechanics first" designers. What the game is about bears little importance.

In my game this year, the player places pipe sections. That is the entire mechanic. The real challenge of course is in, well, the challenge. What makes the player want to place these pipes? Moreover, what makes the player want to place these pipes as fast as possible yet into sensible locations? These questions are very hard to answer without a prototype, and really, that is what game jams are all about. The good thing about this design is that it is relatively simple to implement and should therefore afford quite a bit of time for tuning the design. This did not turn out to be exactly the truth, mostly thanks to the niceties provided by javascript (aka. the language from hell when it's time to debug).

I did initially team up with guys who had another concept in mind (mostly: alien organism that does something) and we did a bit of brainstorming to combine the ideas. As usual though I ended up being grumpy designer and shot down a lot of initial ideas. I started the work by making a grid; whatever game we were about to build, there would be a grid so making one can't hurt. After completing my basic grid code, I went to sleep. Come morning I still didn't see much of a game around alien organism. There were also a couple of programmers in that project already, and I wasn't sure a third would be needed that much. Hence I just went back to my original idea and started working by myself. This is the fourth jam in a row where I have been a one man designing/programming team. I didn't even have an artist to start out with this time.

2. Game is hard

The title of this section is my new trademark. Looking back at my jam game catalog, I have a tendency to make games that are hard to get at first. This is something I need to work on because the initial impression usually matters a lot, and if players feel like they have no idea what is going on... well, it's not very optimal. I think the only game I have developed that has needed no explanation whatsoever was Umbrella Dream from last year's Vectorama game jam (and now I recall there is no post mortem on that one) because it was a platformer with a gimmick. Abstract puzzle games are always harder. Even if the player has some idea of what are the possible actions, the game also somehow needs to make its goal and its scoring principles known to the player. Building suitable indicators for these things is tricky. This year in particular my game was highly dependent on some animations to make it somewhat understandable (and it still isn't...).


Here is a screenshot of the game (release version, except there was a bug with scoring while taking this shot so I have 0 points, lol).

The coils around the edges are the targets, and the "heart" in the middle is the power generator. You can see a pulse traveling through the network as a white flash in the screenshot. The more lit the coils are, the more urgent it is to get power there. There is also one blackened coil in the bottom row; this one has been burnt. The "lightning" that strikes through the network from the core is aesthetically very pleasing. Overall I think the game looks very good (except the shading on some of the pipes seems to be on the wrong side). I do wonder if the game would be easier to understand if all coils were initially lit and would start to lose those glowing rings when they start to fail. This would possibly have a stronger mental image of the coil needing power from the generator.

The game's design had a lot of challenges. The rhythm idea flew out of the window almost immediately. The process of building the pipes is simply too slow to really afford really fast-paced gameplay. The initial idea was to allow the player to stack pipes to create intersections where the path would split. However this proved to be technically challenging the way I tried to implement it, so for quite a while I worked without stacking. Game was hard indeed! I allowed the player to rotate pieces to overcome the handicap. Back then the game also had delete pieces come up from the piece queue, and because stacking was not possible these pieces were really important. Granted, less so after rotation was introduced. Without rotation game was very hard indeed! With this composition the game kind of worked and I could see that it could be made fun but there were two issues.

First of all, the game was now very close to Pipemania and there was nothing really new about it. Another problem was that, given time, the grid would be full unless the ratio of delete pieces to normal pieces would be made 1:1. It was also kind of a frustrating experience to wait for delete tiles to come up when they were needed. At this point I was somewhat stuck. I had counted on the stacking mechanic as an important aspect of the game and I wasn't able to implement it. Well, I wasn't, until I did what should always be done when problems arise: I took a break. Immediately upon leaving the site I figured out a new algorithm to implement the path splitting. Sure enough, when I returned to my workstation, I had path splitting working in no time. This combined with rotation created another problem though: now game was too easy! An apparent problem with this design was that you could theoretically just create a network that hits every single border tile, effectively being capable of hitting all targets that appear.

The game over mechanic was designed to combat this issue (I did foresee this on Saturday morning already): hitting a "burnt" target overloaded the system and led to defeat. However, it was quite easy for the player to simply create a network that hit every tile that was not burnt and keep generating infinite points. Not good. The mechanic changed briefly when I failed to implement stacking: fail to hit a target in time, you lose. That was however kinda lame, and I liked the original game over mechanic much more, so I put it back into the game. I removed rotation to make it harder to create an all-encompassing network and in general harder to hit all targets in time which would burn out at least some tiles. There was another mechanic to combat the issue but it felt really artificial: occasionally, burned tiles would spawn to random locations. This meant that keeping a network connected to every border tile was risky.

The mechanic that is present in my GGJ deliverable does not have this limitation mechanism. The targets spawn pretty fast, but if the player is fast enough, they can create a network that is able to generate infinite points. This is a common problem with puzzle games at game jams. It is hard to find out the right balance in such a short time. Hamsters and Plague, my very first jam game had a similar issue: there was a dominant strategy that was not only clearly superior but also very opposed to the game's design philosophy. Took me a couple of weeks to figure out how to destroy that strategy with a solution that didn't feel completely artificial. By artificial I generally mean a mechanic that has been put into a game as a direct counter to some obvious dominant strategy but that doesn't really fit into the design's big picture. Tetraic had similar issues and I still haven't figured out a solid solution.

I already have some ideas I want to try out for this game. The fact that it runs in a browser makes it a little bit more appealing to continue the design because people might actually play it as opposed to both HaP and Tetraic that are originally XNA games and need to be installed (HaP is presently in Python, but the same problem applies, especially for Windows users). The first change that I did is not yet in the release, but it might make the game more interesting: since the entire system a rather archaic device, the copper pipes are likely to overheat and melt if exposed to use too much. In game mehcanic terms this means that whenever a pipe section is used, there is a chance the tile it is in will disappear. This would be a counter-balancing force to large networks because large networks = more maintenance (by replacing destroyed pieces). It would put pressure to the player to avoid shooting power all across the board "just in case" because wider coverage means wider destruction.

One possible problem would be that this solution might be too chaotic. This could be addressed with an animation for tiles that are being destroyed. Overall, a few more graphical effects would make the game clearer I think. I am still also kind of obsessed with the idea of making the rhythm of the pulse generator have more meaning in the game. Now it just shoots pulses at fixed intervals. It is of course great to throw around improvement ideas; implementing and testing them is the hard part. I still have 6 other jam projects in need of this, so although I have some interest, I am not holding my breath. That said, this might the most probable one to get an update because it is in the browser, and the code is surprisingly clean and modular for a jam game so it is actually quite easy to modify.

3. Working solo, the hindsight

For a lot of people game jams are about making games together. However - for I am grumpy designer - for me game jams are still first and foremost about honing my game design skills. Next time around I just might wear a "will work for design credit" tag. The biggest "pro" in working solo is that you can do whatever the f you want and can do in the given time. However looking at the creations of other teams it is quite clear that with more people a lot more can be done. Of course I scope my solo projects for my solo capabilities but it often leaves very little time for polishing anything. Jams are generally not about polishing, but it would be nice to produce something that is actually great to play from the get-go rather than after several design patches (which have a high chance of never coming out).

The fact that more people = more results might seem rather obvious but of course it is not strictly so. It really comes down to whether there is actually something for everyone to do or not. This project for instance really did not have much that another programmer could have done. Some UI widgets and the scoring system, but those took me about an hour to create. It has largely been the same with a lot of my previous solo projects; the core mechanic is simply not divisible into any sensible units that could be developed independently. The question is though: am I scoping my ideas into solo projects already in conception, or do I limit the idea after I don't have a team? Something to pay attention to I guess. Maybe in the next jam I will work with a bigger team. Another thing to work on is to pitch my ideas even better. I should probably make them seem more crazy. People like crazy stuff!

Conclusion

Another game jam is behind me. That makes eight! I wonder how many it takes to get the title "veteran jammer". Although I am not completely happy with the result this time, it shows a lot of promise and has a code framework that does not immediately repulse improvement ideas. I know from experience that if any improvements are to be made, I should make them in the coming one or two weeks. Otherwise the entire thing is likely to be just forgotten. We are likely to have yet another game jam later this spring; there's been talk about this one being a jam for polishing previous jam games. My problem of course is that I have 7 to choose from, and at least 3 or 4 of those are prime candidates for continued development. Which shall it be?

Oh and about the name: it's my homage to metal songs that have cool sounding yet nonsensible names (e.g. Blacklight Deliverance). The latter part comes from the game's art style, the first, obviously, from the initial design idea of a pulsating light.

I also finished Dragon's Dogma yesterday so the next piece will be on that. I have also been playing alarming amounts of Dota 2, and I figure I should analyze what the hell happened. Xenoblade Chronicles is sitting on my living room table waiting for its turn too...

Tetraic - Yet Another Game Jam Post Mortem

Stage organized yet another game jam. This time it was a Windows Phone 7 game jam in collaboration with another club. It was also my fifth game jam in a time span of 14 months. Traditionally I've written about my experiences and/or my game, and this time is no exception.

1. The Concept


Our theme this time was "opposites". I was at my friend's housewarming party when the theme was released. It's not really the best environment to come up with game ideas but at least I was able to ask a lot of people for different pairs of opposites. The game I ended up with uses opposites in a couple of ways but was more or less inspired by the possibly most ridiculous idea "left and right". My actual game idea originated from Triple Triad, which to this day is the best minigame ever. For those who don't know it, it's a collectible card game in Final Fantasy VIII with absolutely elegant gameplay. Cards are laid down on a 3x3 grid. Each card has a value from one to ten on each of its sides. When placing a card, it flips over any cards that have lower values on opposing edges. Keyword: opposing.

No one was really interested in my idea after the pitching session. Most teams had been formed before it anyway while I was at the party. Fortunately for me, a group of us went to get some pizza to further develop our ideas. I refined my idea while rest of the guys were eating and started explaining it in more detail. It sounded pretty crazy at the time. The concept in all simplicity was Triple Triad meets Lumines. Tiles will drop in square blocks of four. Each tile has a number on each of its sides. Upon falling down, a tile eradicates all tiles that have lower numbers on opposing edges. Blocks will break down like in Lumines so that tiles will never hover in the air. Tiles that have equal numbers on opposing edges form chains; if one tile in a chain is destroyed, the entire chain goes with it. The concept sounded like it had enough mindfuck to be worth a try.

There was just one little problem. Displaying numbers on each side of a small tile would look *messy*. First we thought to use different colors, but they would be rather hard to learn. The best idea won: use different shades of grey. It's easy to learn that the darker the color, the stronger the number. This also had another benefit which was discovered later. We judged that this project had work for only one programmer, which would be myself, so setting up the project was easy. Without even starting my laptop, I decided that there was enough of a plan to go with, and went back to the party. Here's a piece of wisdom: even though 48 hours is not a lot of time, quitting early on the first day is often a good idea. You'll have a much more refined idea of your game when you come back after a night's sleep and you still have a lot of time to work on it. Just make sure you really want to work on this idea before quitting and that it seems feasible to you, all things considered.

2. Tetraic


I love block dropping puzzles and their relatives. They are challenging to design and fun to play when done well. Here's the result from this game jam.

The working title was TetraBlocks (because the blocks have, well, four significant sides) and since the tiles together look like a mosaic, coming up with the final title was easy. The design on the other hand was only a partial success. The way the game was designed, i.e. tiles become active (able to destroy other tiles) every time they move, resulted in combos that made it really hard to lose. Next to impossible really. Nevertheless, the game is in fact quite nice to play and using shades of grey it is not actually that confusing. Sure, it's still a little hard to keep up with everything that's going on, but that's part of the design. Notice how using shades of grey allowed us to highlight chains with other colors.

In the beginning there was one glaring problem: due to my choice of mechanics a block that has a strong value on its bottom side will typically just smash through everything else. I had to implement a mechanism against this that was not very elegant: the bottom side is weakened every time it defeats another block. The less elegant part is that this doesn't apply for other sides (again for gameplay reasons). I'm still trying to come up with ideas to put challenge into the game without adding complexity and exceptions. The key mechanic itself is promising enough to warrant further design effort. This is another lesson for jammers: don't expect a great design from your game jam. A functioning concept is often enough and really all you'll get done.

3. Love debugging, or else...


Last time I was doing programming at a game jam I burned out pretty bad. This time it might have happened as well. While the game concept is quite simple in Tetraic, all sorts of rules for dropping and erasing blocks can cause a lot of bugs. And it did. I spent like half of all the time I had for debugging on Saturday. A few bugs took hours to solve. But somehow I didn't get frustrated like I usually do. The thing is this: when you are in the right mindset, debugging is in fact pretty damn fun and rewarding. Sure, you're still cleaning up your own mess but... try not to think about it too much. Everyone makes mistakes in programming - in fact, if you don't, then you're probably not learning much. Game jams are typically recipes for arcane bugs that can drive people insane. I always start with great intentions and good code design, but the end result is usually pretty far from it.  There is not time for complete refactoring when it's called for.

From my experiences, the best way to deal with a tough bug is to share it. It doesn't matter with whom, just talk about the bug aloud. Explain what you think happens. Doing this will help you get your own gears moving. When explaining something aloud, your brain can no longer fill in the gaps that existed in your theory while it was only in your head. This also applies to design. We have a tendency to assume things work as intended, even though nothing in a theory or design actually takes it into consideration. In debugging, we think we know what happens in the code, when we really do not fully know. We assume it does what it was intended to do. This gets especially bad when you are absolutely sure that one particular piece of your code cannot possibly be wrong.

Of course it is always annoying to be unable to finish your game or polish enough because some nasty bug takes away hours of your development time. But this is what happens in game jams so learn to deal with it. Of course, having programming experience does help tremendously and even though starting with great code design is usually a vain attempt to keep things organized, it does always help. In particular, object-oriented programming is a staple in game development. Coding too many interactions into one object is a recipe for disaster. Finding the culprit is so much easier if every one of your screen object maps into a code object. It is also so much easier to modify game rules if all pieces act independently. Most importantly though, remember that debugging can also be fun.

Conclusion


When I have the time, I'll try and continue development of Tetraic. Turning it into a fully functional design seems like a fun challenge. I'll probably port if from WP7 to HTML5. I don't even own a Windows Phone and block dropping games are much better with a gamepad or keyboard than touch screen. With all these game jams and promising prototypes it's just getting hard to decide which one to work on. Oh and the next game jam is like three months away...

Global Game Jam 2012 Post Mortem

Having participated in three game jams last year, I didn't quite feel like doing a full-scale project this time so I kind of pre-decided to make a board game instead. This year the theme was a picture instead of a word: 

The Concept


I had lots of thoughts about infinity and cycles after seeing the theme. The snake is eating its tail - i.e. it is feeding itself. This was pretty much what I wanted to do. A short game that is played repeatedly, and each time the game is played the game itself grows. The game feeds itself. After viewing the keynote and getting the theme into my head, I bounced some ideas with other jammers and then I went home for a while to gather inspiration. Well, actually I went to eat and watch How I Met Your Mother, but hey, same difference right? When I got to the actual jam site (we had the introduction elsewhere) I had three options: a game where player powers are retained from session to session, a game where world state is retained from session to session or a game where game rules change but are retained from session to session. The game should also be impossible to win on the first playthroughs. So far so good, but where's the game?

My friend, who was in my team in the last two game jams, had an idea about a rogue-like where upon finishing the game, the player's character would become the new boss. "What about the players that don't finish?" I asked - and suddenly I had a game concept. Here it is:

The game is a cooperative board game, which takes a very short time to play. It starts as a one player game. The first player dies very quickly, but in death they gain powers depending on what killed them. The game is then started again, but now with two players: the first player is a ghost aiding the second player. The second player will inevitably die quite quickly. Enter third player, now aided by two ghosts. This will go on until there's enough ghosts to get the last player through the game. The game is meant for gaming conventions as a social game that will gather people together and serve as great passtime between longer games. Ending up with this idea was most likely influenced by the local gaming con that was going on in the same building.



The Design


So I had my killer concept. What I didn't have was a team. I really didn't have any idea for the actual game mechanics either, but I knew it needed to be fast and easy to learn, since new players would be arriving into the table every five minutes or so. Faced with these problems I actually just thought "screw this", went home and watched some more How I Met Your Mother.

The designer never sleeps. Well, not until he is satisfied with his design, or really exhausted. I wasn't actually expecting to make a game this year at all at this point. Sure enough, ideas started to come about as soon as I closed my eyes. By the time I fell asleep I had the game mechanics mostly figured out. On Saturday morning I got off my bed feeling a lot better, and did the component math while taking a shower. I had just pretty much solved all my problems and went back to the jam site, hooked my laptop and started working.



The Game 


The game's working title was Ghost Legion Death Dungeon, which is pretty much the worst name I've come up in a long time. The players explore a dungeon made of square tiles, which will look eerily familiar to anyone who's played Labyrinth. The end conditions are simple: if the players manage to defeat the dungeon boss by pushing through 9 layers of dungeon tiles and spending a bucketload of power tokens, they win. The players lose if they don't find a new hero after the previous one dies.

Gameplay ended up being really simple: monsters, switches and power-ups are printed on some of the tiles. Cubes (stolen from El Grande) of five colors represent power tokens which are the only player resource. Monsters have four statistics: the amount of power tokens that need to be spent to challenge the monster (survive its initial attack), the monster's weakness - spending power tokens of this color boosts attacks against it, kill reward - a small power token reward for defeating the monster, and finally, death reward - the larger amount of power tokens granted to the hero's ghost they die against this monster. Power-ups are simple, they just grant free power tokens for the hero.

Finally since my dungeons would be randomly generated, there was a real chance of getting stuck. To combat this issue I introduced switches. These allow the hero to rotate tiles in the dungeon to create new paths or optimize existing ones. Most switches are trapped though, killing the hero in the process of triggering - such is the life of heroes. Heroes do receive power tokens when killed by traps. Finally to prevent cheap play, I had some rules against backtracking and running into dead ends.

As you can see, I went with abstract power tokens instead of anything specific. Remember, this is a game where new players enter every round and the expectation is that none of these players have played this game before. Can't take forever to explain the rules. Overall, the game is really really simple. The players simply gather resources as a team by 1) killing monsters and 2) guiding the hero to profitable death. A round ends when the hero dies, at which point all players regain their spent power tokens and all monsters in the dungeon respawn. Since players can also freely spend their power as a team, the mechanic is really not different from gathering those tokens into a collective pool.

The fun in this game is not in the finer mechanics of how enemies are fought and defeated but in the higher level mechanic of adding new players to the game. To ensure that players would not have as much reservations, I added a rule that allows players to simply leave the game. All their power tokens are lost so it's  a big loss for the team, but the game can go on if new players are found.

Playtesting


The cool thing about analog prototypes is that they are often much faster to produce. My prototype was finished in about four hours. I ran three playtests on Saturday. I started with a solo playtest just to see how the game would roll out. It wasn't half bad. Okay, it was pretty lame playing alone, but the mechanics were really fast to play.

The next playtest involved other jammers. A game jam can be a tough environment for testing board games - especially ones that require a lot of players! At this point I had no idea how many players it would take to win the game but I guessed that it would be at least ten. I started the game, took the first player position, went into the dungeon and died. Then I invited the next player, explained very quickly what the game's about and in we went together. After a few more rounds there were a bunch of us standing around the table discussing which paths to clear and how the hero should die this time... It was actually really fun! When we hit nine or so players, we started to have deserters what with people being busy with their own projects. We decided to forfeit since it didn't look like we could find enough new players to cope with the loss of power tokens.

My goal was to playtest the game in an authentic target environment: a gaming con! And we had one next door, what luck! In I went, set my prototype, started the game and started to search for new players. At first I had a hard time finding the second player, but then one card game ended and I promptly abducted all the players. With a bunch of players around the table it was much easier to find more players on the following rounds, and this time we managed to beat the game with eleven players. Go us! The game took about an hour and involved all players pretty well. Looked like everyone was having fun and, most importantly, they got a gaming experience like no other. It's not every day that you are invited to play a game and then told "These guys went into the dungeon before you, and we are expecting you to die next. Just try to do so in a profitable way."

Overall I the test sessions were enjoyable. The mechanics were a bit messy with ten players but that's pretty much the only negative feedback I got. I also explained my idea to, well, anyone willing to listen and people were really curious about it. With feedback this encouraging I'll be sure to polish the game for the next event I participate in. With better components the game should be even easier to understand.

Submit... Failed


You won't find this game on the Global Game Jam site. I made my components using a pencil. I intended to make printable components available for download, but I grossly underestimated the time it would take me to do so. I didn't really have any good tools for it, and by the time I realized this I didn't have the time to write a script that would help me with the task. I also spent some time testing another jammer's board game prototype. However, I don't really mind lacking a submit this year. Testing my game requires a lot of people and I honestly don't believe many players are even willing to print board game prototypes.


The Aftermath


Although I didn't +1 to the number of games made this year, it was a successful and far more relaxing game jam than any of the previous ones. Furthermore, my game was true to the jamming spirit: something experimental with no guarantee of it working at all. To my delight it did work. It was fun to watch new players' expressions when they entered the table and also to see how they actively participated in the ghost team's play after their death.This game has the potential to bring new people together, and you don't even need a group to start it. Moreover, it doesn't even require long-time commitment.

I'm not particularly proud of the finer mechanics of the game or its strategic depth. There really isn't much of the latter. The game's difficulty is mostly dictated by the number of available players.However, the finer mechanics are fairly easy to polish with solo testing. Most importantly the core idea works and that alone makes me more than happy for my weekend's achievement.

The game was finally titled Ghost Brigade after one of the best Finnish metal bands. So, to end this lengthy post with hopeful thoughts: "Ghost Brigade - coming soon to a gaming convention near you!"

ps. Anyone want to do dungeon themed art?

Stage Game Jam Post-Mortem

I'm taking a little detour from design analysis to share some insight on design, programming and project planning of our game jam project from last weekend. It's mostly going to be programming though, and mostly don'ts - we didn't finish the project in time. We got quite close though, so I'll come back to the design once some final bugs have been squashed and some levels have been created for the game.

I'll try to add some pictures soonish...

1. Scoping


I've game jammed successfully twice this year. Both games were in fact quite good. They were also very well scoped down, and thus finished. This time around, I decided to take more risks with the scoping, and also do stuff I've totally not done before. This project definitely ramped the challenge up from the last two as evidenced by the fact that we were unable to finish in time with three full-time programmers and one apprentice. We had three main tasks: gameplay engine (it was a platformer with some twists), graphical effects and sound system. None of these were trivial, and no one in our team had really done anything of the stuff they were going to work on. I was in charge of the gameplay engine since we were developing with a library that I was the most familiar with.

Nevertheless, I think the scoping was realistic. In fact, I think our effective working time per person was less than 20 hours - clearly less than what I've had in previous game jams. Ultimately, we were not very far from first playable level. We had some minor bugs, some of them ignorable with level design. What we really lacked was levels. Kind of hard to show any gameplay with them. However, looking at the list of what we actually did build, it's fair to say we did really well. Here are some highlights: isometric platformer with climbing instead of jumping, sound system complete with radio channels and static between them, knobs for tuning frequencies and level elements affected by these frequencies, and finally, enough high quality art for a few levels.

On with the lessons...

2. Lesson: JavaScript with sleep-deprivation is bad


Okay, I think this for me personally was the biggest factor hindering development. I was already tired on Saturday morning when we started actual work, and around 8pm I was way too tired. Programming anything should not be done tired, but JavaScript is special. It's really easy to make invisible errors with JS and tracking them down is really freaking annoying. Moreover so when tired. When tired, it's increasingly hard to escape one's thought patterns, leading to looking over the same piece of code all over again because "the error has to be here somewhere" when ultimately it is not. JavaScript has this annoying tendency to quietly accept almost anything. Between Sat 8pm and Sun 2am I really didn't get that much done, but I did get really annoyed. Hindsight: I should've left around 10pm and come back earlier on Sunday.

3. Lesson: even when used as constants, magic numbers are still really bad


This one was my biggest personal failing, since I can't really blame any of the tools on this one. 2D-programming is often riddled with all sorts of offsets, margins and whatnot, because of the way sprites are handled. This is especially true for isometric 2D as sprites can hide behind each other, and characters are not standing on top of floor sprites but in the middle instead. All sorts of constants. The mistake I made was basically that I did not have any system, I just made estimations for each value using Stetson-Harrison, and at some point the entire system just crashed down on me hard. So hard in fact that I was only able to recover the situation on Sunday morning after a night's sleep. In the end, I did it right in about two hours and now the system makes a lot more sense. I also actually measured all the offsets from the sprites (this would have been impossible earlier though, since the sprites were not finished and we hadn't really agreed on any specific measurements).

4. Lesson: isometric graphics in a platformer = way more trouble than it's worth


When we started out I was thinking about simple side-view 2D. However I didn't communicate this clearly enough, and our artist started with isometric graphics, and me, not realizing what a pain that would end up becoming, okayed it since it did look pretty damn good. What a big big mistake. See, one of the biggest problems is that while in side-view 2D collision detection is easy, with isometric it is not because the sprite size is not equal to the space it takes in the game's internal logic. To further complicate the issue, the library we were using did not support custom hitboxes for collision detection for both parties. Since none of our sprites were equals of their hitboxes, there was trouble. Unfortunately even more so, because I tried to figure my way out of this mess with offsets and margins.

Another problem with isometry is the z-order of sprites. For example, when on the left side of an obstacle, the player sprite has to be behind it, but when on the right side, it needs to be in front. This got even trickier when we chose to use climbing instead of jumping (a sound decision, jumping in a horror game does look a little silly). During climbing from the left side, part of the player sprite needs to be in front of the obstacle (the top half, which is above the obstacle) while the rest is behind. This was solved by splitting the player sprite in two parts during climbing, and was not that hard in the end. Another consequence of climbing is that the sprite can only climb a given fixed height without making the animation look stupid. This is just a level design issue though, and indeed most platformers have their level elements placed on square grids anyway.

Later on I also realized that this is going to come back to haunt us with our ghost enemies, because they can move through everything in the game. It's going to be pretty damn painful to figure out a system where they can at the same time be in front and behind objects...

5. Lesson: plan for earlier integration


Three programmers working separately is okay, especially with version control. However, I would advise planning for integration at milestones, not just the end. It's really crushing to motivation sometimes to only see your part of the game nearing completion, and never getting a glimpse of the end result until, well, the end. We did this mistake in the last game jam where we literally had no idea if the game idea would ever work before it was about one hour away from complete. Fortunately it did work... This time around, since we had no time to make any actual gameplay, I'm still not sure if this idea actually works. So yeah, the old wisdom of prototyping early should be followed in game jams as well.

Conclusion


I guess that covers it for now. As promised, I'll get back to design after I have had the chance to make some gameplay. The game will be released online and be playable without any special plugins, so you can hopefully see the end result for yourselves as well.