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.

The Last of Us

Every once in a while even I play hyped titles. It comes down to quite random things, and in this case I largely picked The Last of Us up because of two things: it felt like a game that will be discussed so I had to get it early to dodge spoilers; I just happened to have an empty spot in my gaming schedule since I had drastically decreased my Dota 2 playing. Despite being a horrorish game, it actually felt like a decent summer game due to lots of well-lit environments. I would have probably jumped on this game even harder had it not been for the zombies. Goddamn zombies. I'm not a big fan of post-apo either, but at least The Last of Us is the better kind of post-apo - i.e. not that frigging boring-as-a-brick-wall desert shit. Yeah, there's some things in gaming I *really* don't like.

1. Realism is overrated... again

In a way, The Last of Us is a spot-on example of how Ian Bogost described the persuasive power of games in his book Persuasive Games. In the book he defines the concept of procedural rhetoric: whereas verbal rhetoric appeals to us through logic and compelling writing, games persuade through modeling processes. Through the model, the player can experience the circumstances and interact with them. For instance, Bronkie the Bronchiasaurus teaches asthma management through simulating it - the player controls a dinosaur with asthma. The model can be based on reality, but typically is not realistic as such. So it is with The Last of Us - its gameplay is a compelling model of scarcity. The model is not compelling because of realism - rather, it is compelling despite its lack of realism. Allow me to explain.

The Last of Us uses several different mechanics to simulate scarcity. Since it has a post-apocalyptic setting, guns are expected as is scarce ammunition. Survival games in general use this mechanic to create suspense and force the player to seek alternative ways to defeat enemies. Generally the next best thing would be melee weapons, and they too have been made scarce. A typical melee weapon is only good for a few hits and the most effective melee weapon is the shiv - a single use stabbing weapon. The shiv is especially important because it is the only way to silently kill clickers, a type of enemy that detects the player based on sound. Normal enemies can also be taken down silently by surprise with unarmed attacks, but it takes time. Generally going stealth is the only option when the player has no ammunition left and usually shooting is plan b in any case.

Of course none of this makes sense from the perspective of realism. After a firefight with even a handful of enemies, the protagonist would have weapons and ammunition to last a small lifetime (at least considering how carelessly the enemies fire their weapons - which means they must have no worries about running out). A good melee weapon lasts almost forever with proper maintenance and shivs are just poor replacements for knives, which are clearly ubiquitous in the game world. Thing is, had the developers considered the realism of each game situation, encounters would be rather dull - in order to avoid giving the player too much equipment, they would be facing unarmed opponents for the entire game or only zombies. Simply put, there would be so much less variety. Instead the developers have chosen to model the economy of scarcity through artificial resource limitations - and it works phenomenally well.

The same goes for the game's crafting system. It is very simple with only six or seven items that can be crafted, but it serves an important purpose. First of all, it adds to the survival theme: useful items are very hard to come by, but materials to make them are slightly more available. Second, it does force the player to make some choices about what to do with their resources. The system is simple enough to not get in the way - at the same time it is not too simple to the point it would be redundant. Is it even remotely realistic? Not likely. Instead it's a functional subsystem in the game's repertoire of mechanics. Resources are also scarce enough to make scavenging always worthwhile, which adds value to exploring corners of the world. It also does not feel out of place, because it is consistent with the game's story - unlike excessive looting in certain other genres!

Games often don't follow the WYSIWYG paradigm when it comes to loot. Although it is from time to time called out as unrealistic, it is important to understand that realism would actually make things very though. Anyone who has tried to run a tabletop campaign where scarcity of resources is an important element has likely run into this problem. In tabletop RPGs players are much more likely to play the realism card if they cannot loot stuff enemies were using. Some settings allow for workarounds with varying credibility but others do not. It can become a major challenge for the game master to prevent their players from gaining too much power while still creating challenging combat situations. It helps that mechanics in tabletop RPGs are less rigid - in videogames the designers cannot adapt on the fly.

Finally, let's talk about stealth. Often when sneaking around, at least one other party member is following you. It seems a bit out of character at first, because they are actually entirely invisible to enemies as long as the protagonist has not been detected. Sure, the AI does its best to make it look like they're also sneaking, but very often they end up running around - even bumping into enemies - while the player is trying to sneak as quietly as possible. It sounds pretty awful, but ultimately didn't retract much from the experiene at all. Imagine if, instead, they had made it so that allies can also trigger enemy awareness. The sheer amount of frustration would have caused a massive outcry as yet another stealth attempt fails because the AI-controlled characters accidentally revealed themselves. Considering that stealth in the game is quite demanding, I don't think it would have been possible to implement an AI that could navigate the situations well enough.

In general it is far more important to consider what is the aesthetic experienced by the player than it is to consider its realism. Likewise the actions taken by the player are more important than how they look. Thus Dark Souls can incorporate a lot of the mentality of actual fencing even though it looks completely different. Likewise, The Last of Us incorporates the dynamics of surviving in a world of scarce resources without taking into account the realism of scarcity. The most compelling games do not impart their message through narrative or graphics - they do so through gameplay. This is essentially Bogost's message in his book. Instead of considering realism, designers should consider whether the game's dynamics are able to model the process they want the player to explore. Making sense is voluntary.

2. About segment lengths

I basically have only one complaint about The Last of Us, and it is one that applies to a bunch of other titles too. I guess I just truly pinpointed the problem while playing this game. In a nutshell, a single segment in the game is way too long. Several times it feels like it is ending and the game is about to move forward, only to start yet another thread that prolongs the experience. Although it is only a single segment, it can have far-reaching consequences to the gameplay experience. The player only needs to get bored once. After one segment that drags, I started to be far more critical towards the game and the length of its segments. Fortunately the problem was not repeated but its shadow still retracted from my enjoyment. I recall this happening in other games too; a single long segment severely affects my playing mentality. The entire games feels more boring only because one segment lasted too long.

I would like to say I know a psychological basis for why this happens, but I actually cannot recall having read anything directly similar. However, since I like to do some guesswork, it might have something to do with how expectations affect our actual experience of something. The same phenomenon that makes wine taste better from a finer glass is just as likely to affect a gameplay experiene. For instance, if I consider a game worth preordering, chances are I will like it more just because I had high enough expectations to opt not to wait. Expectations during gameplay are a living thing. Players usually arrive with some expectations, and will build upon them after experiencing the game itself. A single instance of bad experience can then set the (possibly false) expectation that similar instanced might occur in the future. The player will become suspicious of the game in a way - e.g. Is this turn in the plot another ruse to get me into a long gameplay segment?

The sad reality is that players are more likely to base their expectations on a single bad experience than to a positive experience. That's why you can read fans complaining about the smallest things. Although the things themselves feel small, it might have happened that they have changed the player's expectations and in doing so in fact ruined the entire experience for them. Although this is just my (educated) guesswork, it definitely is something to think about. I have no doubt that The Last of Us's lack of realism has been a turn-off for some players.

3. About stealth, again

I keep going on about this topic - and that's a good thing since I keep re-evaluating my feelings about stealth games. This is the essence of this blog: coming to understand why certain solutions work for me while others do not. I am doing so because I believe it will help as a player (to pick games better) and as a developer (obviously). The Last of Us is a game where I both loved and hated stealth mechanics, and thus it is a good ground for me to explore my relationship with this subgenre. The biggest differentiating factor between stealth scenes I liked and the ones I did not was their setting: I consistently liked outdoor encounters and disliked indoor encounters. Being indoors or outdoors is not the actual explanation though. Rather, it is indeed the degree of freedom which simply happens to be larger in outdoor environments - especially in The Last of Us.

This preference also explains why I consider Dishonored my absolute favorite game in this genre - not only does it take place in quite open environments, it also gives the player superpowers that open up even more possibilities. The more closed the environment, the more stealth starts to feel like a puzzle. This happens because the solution space for a given problem shrinks. Turns out I don't like this one bit. While I have nothing against puzzles, if I want to solve puzzles, I'd rather play puzzle games. There's often a sort of uncertainty in stealth puzzles, and I really don't like that largely because there are too many variables that are hidden from the player. The control of the situation slips from the player's hands because instead of being able to make their way through the encounter, they are playing a guessing game to figure out the one solution that actually works.

Free saving is another feature that highly affects my stealth experience. I don't mind redoing boss-fights in arcade games, because the challenge remains interesting even after defeating the boss for the first time. Likewise, I love strict time attacks in racing games - driving the same track, perfecting one corner at a time, great times. However, I really really hate redoing stealth segments. It is fun to stalk an enemy for the first time, especially if it ends in their death - it's not fun to do the same thing all over again. The difference here is that the "mechanic" involved in stalking is often *waiting*. So while I don't mind playing through a challenging segment again because it will improve my skills, waiting is not really a skill - it's just a colossal waste of time. The more the stealth segment is like a puzzle, the worse it gets because I will just be doing the exact same things every time. I always succeed because I already figured out how to do it.

Coincidentally, Dishonored has free saving while The Last of Us did not. A lot of games are better off without free saving, but seriously, that feature is absolutely necessary in stealth games. Moving very slowly and waiting simply are not fun game "mechanics" - the real challenge was in scouting the situation and figuring out a way through it - and since that knowledge is not lost when the player dies, all they have left to do is to repeat the same steps. I guess we can coin a term for this: retry value (related to replay value, obviously). If repeating a segment poses no challenge to the player, its retry value is very low whereas if it remains challenging every time, its retry value is high. Games with high retry value can actually benefit from not having free saving whereas games with low retry value absolutely must have free saving or very frequent checkpoints.

Conclusion

The Last of Us is worth the hype, and calling it PlayStation 3's last big game might very well be appropriate. It is impressive in so many ways - it's beautiful to look at, runs smooth and has a solid story to boot. Most importantly though, it has so much elegant design. It is one of those games that really make the player feel like the world has ended. It accomplishes this not through realism, but game mechanics that give rise to compelling model of scarcity. Yet another strength that went unmentioned is that the game achieves a lot in segments where nothing at all happens. As opposed to what might be expected of a videogame, The Last of Us actually has rather lenghty parts where no fighting is going on and the player is simply wandering through scenery - and somehow these feel like the strongest moments in the game. Part of their allure is built by conversation. There's a lot of that, and most of the game's dialogue takes place in-game rather than cutscenes.

Although the game is beautifully designed, its mechanics are not ultimately *that* interesting on their own. The beauty is in the atmosphere - the final aesthetic - of the game. In this sense it is the paragon of modern games where everything from technology to writing to game mechanics come together to support an enchanting player experience. It is also a game that uses the strengths of the medium to create something powerful that simply could not work in any other media. I do think it's required playing before putting your PS3 to rest - whether you like zombies or not.

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...

Darksiders 2

Oh wow. I have been too busy to even keep this blog. Somehow I haven't been too busy to play games though! I guess there's a slight preference hidden there somewhere. Anyway. Now I have some time to catch up on what I've played. I'm going to go in chronological order because it's easy. The first one on the list is therefore Darksiders 2. It's going to be followed by Space Marine, Vanquish and Borderlands 2. I have also been playing Stepmania because I have no time for my normal exercise-related hobbies.

Anyway. Darksiders 2. This is one of the games that I've actually been waiting for this year. Largely because the first game was amazing in many aspects but felt like it could use a sequel. Many games these days do. In the movie industry sequels are often crap, but in the games industry it seems more like the sequel is often the better game because in a sense the game has gone through one hell of an iteration already with one launched title. The third title in a series might be a mistep again, largely because when there are no huge flaws to fix, new things have to be added into the mix. It's either that or be accused of "beating on a dead horse". You just can't win there. It would probably be an interesting study to look at how many series consist of exactly two titles. Might be interesting to also involve the sales figures of second versus third iteration.

1. Originality, schmoriginality

Let's just get this out of the way immediately. Not a single ounce in the gameplay of Darksiders 2 is original. The game steals from a variety of sources: God of War, Prince of Persia, Diablo/Borderlands and of course Zelda. Most likely a bunch of other titles to boot. Does it matter? No, it does not. It is somewhat of a dick move though - taking good concepts from the wealth of past game design while giving next to nothing back. The one thing that has been done exceptionally well is the combination of so many influences. The core is definitely Zelda. The guys at Vigil clearly have decided that Zelda just isn't manly enough for them, so they replaced green elves with grunting wisecracking horsemen of the freaking apocalypse and made combat bloody as hell. It is a nice take on the Zelda gameplay, something for us grim'n'dark types to enjoy with our adventure.

2. Fighting matters

Actually yeah, I think combat is the single biggest differentiator between Zelda-like titles I like and ones that I  don't. One problem in the first Darksiders was that War was more or less a tank, and tanks are not really interesting to play in solo hack'n'slash. Death on the other hand is a master of agile DPS (you know, like agile programming but with more violence!) There is no guard button in Darksiders 2; the only way to avoid damage is to evade or interrupt attacks. The game also acknowledges the importance of hit stun resistance. Some enemies are more resistant to hit stun which makes them a lot harder to interrupt. Death's combos also have varying hit stun. This forces different strategies against different enemies. Hit stun is one of the most important aspect of hack'n'slash games. The lack of proper hit stun mechanics is what often leads to button smashing.

Games where defence relies on evasion can become evade fests instead but Darksiders 2 also avoids this by limiting the number of subsequent evades that can be performed to three. The last evade has a lengthty recovery which often leads to taking hits and hit stun (also known as quick death). I am not sure whether I liked this mechanic or not, because sometimes the enemies just attack in patterns that are really difficult to get out of with just two evades. On the other hand, this forces the player to seek strategies that avoid getting into such situations in the first place. So the jury is still out on this one. Most important thing is though that combat in Darksiders 2 actually demands some skill, especially against multiple opponents. Single opponents, no matter how strong, were mostly quite easy because of Death's superior mobility.

Here's a theory. It involves the guard button. Thing is, Darksiders 2 has the most enjoyable fast-paced hack'n'slash since Devil May Cry 3. The difference between these titles and titles like God of War and Dante's Inferno? Guard button. The guard button is a kind of fail-safe; it removes the need to telegraph attacks and in general make all attack situations perceivable. It's a get-out-of-jail-free card that allows creating fights where the player has no way of seeing what the f is going on because whenever things get like that, they can just hit the guard button and wait for a clearer situation. But that's bull. Holding a button is not a whole lot of fun. Getting a cue when attacks are coming and avoiding them with carefully timed evades is fun. More so, because often you might even need to learn which way to evade in order to get a good counter-strike opening.

So um yeah, the problem is not exactly the guard button itself. Still, guarding as a mechanic is horribly static unless some dynamics are added into it. See Dark/Demon's Souls to see a guard that works for the game.

Conclusion

I guess there is not really that much more to say about Darksiders 2 what with it being a sum of mostly other games. The hardest difficulty setting was quite enjoyable to play and many fight scenes in the game took several attempts so can't complain about lack of challenge either. What the game really lacked was interesting boss fights - most of them were too easy because of Death's ability to easily evade anything thrown at his way by a single opponent. The ultimate challenge in the game was also a bit lame: fight 100 rounds of arena battles without dying. Having to start the entire process over after reaching 98 or so was really really annoying. These things are hardly ever acceptable but even less so if the first half of the challenge is more or less trivial but still takes a great deal of time.

All in all, I guess, combat aside, the core message of Darksiders 2 is that theme matters. If it had been a cute game with pixies or silent elves in green tunics I probably would not have enjoyed as much. Furthermore there is always something to do in the game and every dungeon is different. My favorite ability was soul splitter which allowed Death to become a statue and spawn two clones of himself. The best puzzles in the game revolved around this ability. I dunno if this is stolen from another game or not; if not, good job Vigil. Adding looting and simple character development in Borderlands fashion was also a smart move. Hunting better equipment is always much more fun than trying to locate some small upgrades like extra health. As long as you don't mind lack of originality, you could do a lot worse than to pick up Darksiders 2.

Trine 2

This is going to be a bit shorter. Trine was a charming game, especially audiovisually. It might have not been the most balanced game though and the utility of its three characters was pretty far from equal.

The biggest problem was the knight who had almost zero utility in the first game. He was designed to do the fighting, but quite often the thief's arrows were able to deal more damage and were safer to use. Since the thief was also able to swing around with her grappling hook, for me she stole most of the spotlight. However, this being a physics-based puzzle-platformer, the supreme character was the wizard, able to not only move objects with telekinesis but also to create new ones out of thin air. Limitations were involved, but even with them the wizard was a puzzle-solving powerhouse.

The level design in Trine however enabled so much utility for the thief's grappling hook that I didn't need the wizard that much either. I guess it was more fun to just swing around although at times it probably took me more time in form of attempts than it would have taken to just create some boxes and let physics do the rest. This is all good though, allowing the player to make choices in solving puzzles. This is generally an advantage of physics-based games that players can always come up with solutions that developers did not think of. The possibility space in Trine certainly is not very large but the illusion is usually good enough.

Like any sequel worth its salt, Trine 2 changes things around a bit. It adds new kinds of puzzle devices into the game mechanics. This creates more variation but also I felt that most of these new solutions made puzzles more "hard-coded" to one solution. The thief's utility has been decreased by reducing the amount of surfaces that can be grappled with the hook. The wizard has also lost his triangle block which was the only object he was able to levitate around while standing on it. The knight still hasn't gained any really new utility tools and the thief is still pretty damn solid in combat.

The balance has indeed shifted but to what direction. I felt that unlike Trine, the sequel actually forced the player to use the wizard's abilities much more. Many of the puzzles were not solvable with other characters' abilities at all. The knight still has only two purposes outside battle: protecting himself with his shield and breaking things with his hammer throw (which might or might not have been new, can't remember) - both very contextual. Thing is, the wizard is the only character in the game whose abilities do not require much support from the level itself. He can always create boxes and planks. With four objects total, a lot of things can be done.

Balance problems always exist in games with more than one character or class to choose from. Of course, it is not too bad for Trine, because characters can be switched instantly and constantly. On the other hand though, being a puzzle game does by puzzle design dictate which abilities are more useful. It can require all abilities but rarely does so in equal amounts. The wizard clearly gets more screen time in Trine 2. Fortunately, his problem solution model has a lot more variance. Creating a stack of boxes is not a solution to everything. In fact, the last two or so levels in Trine 2 had pretty devilish design. This of course comes with a price - the more difficult you want a physics based puzzle to be, the more "hard-coded" it's solution is likely to become.

All in all though, Trine 2 is a somewhat better game than the first one. Both are quite charming but still have their flaws. I still think the knight could use some ability that makes him more useful. Hammer throw spots aside, there were very little places in the game where his abilities had anything to give to the solution. At least he should be even stronger in combat as he is still outdone by the thief in many situations. The biggest improvement in Trine 2 is the addition of new puzzle mechanics such as watering mystic plants to create new paths, and also the increased difficulty in later levels.

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...

Lumines Supernova

I wanted to write about Lumines... again. Just wanted to point out the things that make Lumines awesome. Lumines is a block dropping puzzle game. The main hook of this game is how it connects its soundtrack to sound effects triggered by game events, making it a highly involved interactive audiovisual experience. The mechanics also happen to hide a really solid game, and here are my observations of some of the causes.

1. Non-solid blocks

In Lumines, when you land a 2x2 block on top of previous ones so that half of it is left hanging in the air, it doesn't remain that way. Instead, the blocks that were left on top of nothing break off and fall down until they hit something solid. It doesn't sound very revolutionary, and indeed it's not particularly new. In Lumines this mechanic ensures that it's more challenging to figure out how a block will end up. Players need some experience to see what's the best way to drop a block into a particular spot on their "construct".

It also means that when a player "undermines" (connects and destroys blocks so that some of the destroyed blocks are underneath other blocks), they again need some experience to see where all those blocks that fall down will end up. In short, the mechanic makes the game less static, and therefore more challenging to entirely figure out. Setting up combos that make use of this mechanic is an art form in itself, and something I have yet to master.

2. The beat line

In Lumines, when the player connects rectangles of four or more blocks, these are not immediately removed. Instead, they are marked for removal. A beat line constantly passes over the playing field, left to right, and as it moves, it erases all blocks marked for removal (and scores them). This mechanic affords big combos, as the player can build lots of rectangles for removal before removal takes place. It also adds a bit to the player's cognitive load as they need to be aware of which blocks are not going to be around much longer while they are placing new blocks. Combine with the previous mechanic, this makes it sometimes quite challenging to figure out what's a an optimal move for a situation.

Another interesting dimension about the beat line is that its speed affects how a level plays. Levels where it moves slowly afford big combos, but are harder because more blocks will accumulate on the screen between removals. This is especially true in levels where the beat line is really slow, and the falling speed of blocks is really fast. The difficulty of levels in Lumines is therefore controlled by two parameters instead of one, which adds a lot of variance to progressing through the game. Which brings us to the next point:

3. Nonlinear difficulty progression

Lumines does not simply change both its difficulty parameters constantly towards more and more challenge, but instead some levels downplay the challenge in one of the parameters and increase in the other. The levels are arranged such that the toughest levels are often followed by somewhat easier ones. I like how this gives the player a second chance after a hectic level which is almost guaranteed to mess up their stacks. Often in these slack levels scoring is not as important as improving the block structure for the next tougher level.

The downside is that this makes the game much longer to play, as it becomes "impossible" way slower than games where only one difficulty parameter constantly ramps up. After the full cycle of 20 levels, the overall falling speed of blocks increases, so eventually the situation is going to get out of hand (for me its at the first half of the third cycle). The definite upside is that one mistake is not going to ruin the entire game. There is always hope. "If I can make through this level, I can fix that problem. Not all is lost."

Conclusion

Lumines (Supernova) does a lot of things right. It puts a huge cognitive load on the player and succeeds in keeping a player in flow for a long time by introducing non-linear difficulty progression. Thanks to the huge cognitive load, the game is really hard to master. It stays interesting a long time.