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