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...
No comments:
Post a Comment