#hiddenpuncher | Explore Tumblr Posts and Blogs

hiddenpuncher · 7 years

Text

My First Game Jam: Winter 2017

Here we go again!

Over the next two weeks (January 7th - January 21st) I'll be making a game for My First Game Jam: Winter 2017. This will actually be my second game jam, so please, nobody call the police. In spite of the title, the jam invites complete beginners and experienced programmers alike, so long as the latter try something new. I'm still a beginner, but I'll honour that agreement and strive to try new things this time around. Aside from learning new things and making a new kind of game, one of those new things I'll be trying is to keep a development blog. This will be it.

The first game I made was "Boyle and Bubble" a very short little SHMUP for GBJAM 5, which spanned the first ten days of October 2016. It's incredibly simple, but I learned a lot in creating and finishing it; I'd fooled around a little with prototypes before, but never "released" anything that could be called a game. Before I get started on this next game I'd like to take note of what I learned in my first game jam, and keep it in mind going forward.

No matter what, just start

Get going! Boyle and Bubble grew really organically, and I'm not sure if this is because I got very lucky, or if I it was because I didn't have any grand designs in mind to begin with, and just played around and let it happen. I built a game around realistic restrictions I observed about my own skill and the conditions of the jam; the art had to be simple, I am terrible at making engines for platformers, and it had to feel like something that could have existed on the Game Boy. It also helped that GBJAM 5 happened to fall in the run up to Hallowe'en, so there were a lot of pumpkins and ghouls and skellies flying around social media. I realised a SHMUP would make movement easier on me, and I idly started to pixel a small cutesy witch.

From that point, everything came together pretty simply -- a witch typically has a cauldron and casts spells, so the enemies became elemental, and the player had to mix up elements in her cauldron to come up with new magic. Granted, this is an incredibly simple premise, and it didn't birth a ground-breaking new type of gameplay, but going in without a colossal set of expectations and goals was really liberating. There was only a week to work with, and a simple concept like that seemed to work.

Releasing feels good

Most of the reason I'm taking part in this jam, aside from to learn something new, is quite frankly to release something, and get that buzz. I still have lots of prototypes lying around, but since the end of GBJAM 5 I've been committed to working on a new game that I think has a manageable scope that I still know will take me a good deal of time to complete. Sometimes I can feel myself burning out working on it, and I'm eager to find reasons to go back and work on other projects -- maybe now I know this, I can do this better, or maybe so-and-so project didn't fail that badly, if I just try something like this... So a game jam is a great compromise. A set period of time when I can focus on something outwith my long term project, and happily draw a line under it when the deadline comes around. I'll get back to my larger project, but I'll have that wonderful Game Finished And Released feeling.

Plan small, and then resmallerise it

Talking about the size of my current project brings me to the next point - size. Planning simple and planning small are key. Certain ideas lend themselves better to jams than others. Boyle and Bubble in some ways suited a jam really well, but less so in others. In the game you can play now, there's a singular level, but I spent so much of the week programming and making consistent the elemental combination system and plugging in all the different spells that I didn't have time to build all the levels and enemies and bosses necessary to showcase those spells. All of that code exists in the game, but playing through the only level on offer, you'll never see it. I had to settle for letting you choose to use two elements separately, or combine them depending on the circumstances. My plan was small going in, but even so, planning smaller still wouldn't have hurt.

Prototype core mechanics first

This is going to seem like a silly thing to even have to say, but I have to say it, if only to myself. I talked about how Boyle and Bubble grew organically from the restrictions and spriting the player character, but even that was probably a mistake. It helped that the Game Boy limitations meant my art was never going to have to be super complex, but a square box would have suited for pretty much every enemy in the game until much later.

More importantly, Boyle and Bubble had no failure condition for the majority of development, so "playtesting" really was just to see if enemies behaved according to plan. The player couldn't take damage from enemies or projectiles, so there was no incentive to move evasively -- a pretty core mechanic in a SHMUP, second only arguably to, you know, "shooting 'em up". Since there was no threat, playing the game only began to feel like actually 'playing a game' much later. I floated through the levels and saw how movement patterns worked and how projectiles behaved, but the feel of the game was missing for a long time. Had I been playtesting with player death for a great deal more of the development, the game might have felt very, very different earlier on, and probably for the better. The simplest form of the final game is what should be built first.

Budget time around the smallest features with the biggest impact

Hit points! Damn it! Closer to the deadline for GBJAM 5, I started doing my best to budget my time accordingly. With two days to go, I was taking a look at my "development log" (notepad file filled with annotations like "FIX!!" and "this is bad, probably do this like this") and being pretty brutal about what to cut and what to prioritise. It's the reason why the game only features one level, limited enemies, attacks, etc. But even though this was good practice, I still managed to goof colossally.

With about 20 minutes until the deadline and the itch.io page all filled out and ready for the upload, I was almost finished, but had to choose between two things to finish. I'd wanted for a while to program in a three-hit HP system to make the game a little more lenient, but I also had no way to round the game out. There was a boss, and he had an attack cycle, and you could defeat him and he blew up, but then nothing happened. I knew what should happen -- Boyle should glide slowly over to the right of the screen, her adventure complete, fade to black, credits roll. That's how a game should end. So that's what I did. I shelved the HP system ("hey, at least the player can die and restart") and plugged in a way to take control from the player after the boss is defeated, float them over to the right side of the screen, and whipped up a quick credits reel. Boyle hovers up top and waves to you as the names scroll up, and then it boots you to the main menu. Fine! Good. But this was a mistake.

Considering how few people played the game, it really couldn't afford to turn people off quickly. Getting hit by an enemy and being told to restart is a pretty good way to lose patience with a game, I think, and not only that but the threat of taking damage persisted through the level -- the credits sequence was good for a few moments at the end of the game. It wasn't a good trade-off. I don't know that anybody else ever saw them. Four of the five comments people kindly left as feedback for the game reference how unforgiving it was to have a one-hit kill mechanic in the game. One even notes that they were disheartened to die in one hit the moment they encountered the boss.

The ultimate gut-punch here is that on the day after the jam ended I opened the project file back up and carried on tinkering. I'd planned on taking a break, but I couldn't get out of the habit after a week of working on the game religiously. I knew the game should have the three HP system, even before the feedback, so I looked into it. It turned out to be incredibly simple, and took me less than ten minutes to implement.

Don't neglect sound

Another small feature that would have dramatically changed the game was sound. In the run up to the game jam I'd read or watched something (I regret I can't remember whose advice this was) where this point was stressed -- not to neglect sound, because it makes such a big difference. I knew this going in, and told myself that there might be no music, but I would at least have time to whip up a few sounds in BFXR. In the end I cut sound as something to accomplish, and I wish I hadn't -- I went to the trouble of adding particle effects and little explosions and a couple of animations that sound would have really spiced up, even without music.

I wasn't particularly concerned with "winning" GBJAM 5, but I was surprised how well the game did in a few categories (visuals especially), but you can see from a quick breakdown of the categories that having no sound really made a difference. The best score you can possibly honestly give for a game with no sound is a middling one -- that's taking a generous view, with the approach that "well the sound wasn't good or bad", but I think really the score you give to a game with no sound is the lowest possible score.

I deprioritised sound in order to play to my (relative) strengths. I knew I could just about program the game, and I can make very simple pixel art, but with sound, I have no experience. In some ways maybe this wasn't such a bad thing, but again, there's a catch; immediately after the jam ended, I was surprised that people actually approached me over social media offering to give the game a soundtrack. I had thought of working on the jam as such a personal project (and knew well enough people from all discipline's loathing of being asked to work for free, or worse, for "exposure") that I made peace with the idea that if I can't do it, it won't be in my game. The generosity of strangers really caught me off-guard.

Don't neglect your health, either

Budgeting time is important to get your game finished, but you have to budget the time in the day to keep yourself going, too. I made some duff decisions on what to cut from the game, but I think in some ways they were excusable because it meant I finished the game. But I cut time out of my routines outwith programming that simply aren't sustainable -- I stopped running for that week and ate very badly, because it was easier than taking time out to cook smart meals, and an hour out for a run was an hour I could spend bugfixing. I was glued to my screen, and pretty much the only social contact I had was a stalwart friend who was practically responsible for safeguarding my brain and keeping me sane as I stared at code for hours and hours on end. This was okay for a week, I think, but I don't plan on doing it again, even for just the two week span of MyFirstGameJam.

Game development fridge magnet wisdom is actually really, really good

If these nuggets all seem incredibly familiar, I'm sure it's because they have been expressed (much more effectively) in a hundred other lists like this. Derek Yu's "Finishing a Game" probably covers everything here and more, and it's all really great advice. His book on Spelunky was also really insightful and helpful to read. Following Tom Francis's development of both Gunpoint and Heat Signature and learning from his "Make A Game With No Experience" series and dev logs helped me a ton, too. I probably couldn't cite all the sources that I try to keep in mind when fiddling around with a little prototype -- the almost zen koan-status game design wisdom of Miyamoto Shigeru, that one Mega Man X Sequelitis episode, Mark Brown's really insightful Game Maker's Toolkit series, and so many others. All this is really just to say Take Advice From Smart People, You Dummy.

Show people your game, and talk to other people that make games

This was the #1 thing learned -- show off your game on social media, and find other people making games there too. I dislike a lot about social media platforms and what fills them, but I met so many amazing people that were super supportive, and offered advice and feedback. Also, as a complete novice, everyone was like a mentor to me, even if indirectly; watching much more experienced devs create amazing games alongside my own efforts was much less off-putting than I would have thought, and actually just inspiring. It was really gratifying for some reason to see titles I'd seen in development on Twitter (Bob&Dob! Soulstice! Zero Star! Noru! Monster Buds! Zipper League Hockey!) appear as fully-fledged games on-site on the final day. Also, to reiterate an earlier point, Twitter was the medium through which people offered to pitch in with sound and music post-release. People coming out of the wings to support you is amazing.

If nothing else, game jams are the ideal way to get as many hands as possible on your work. Boyle and Bubble has only been downloaded something like 40 or 50 times, but this is way more people than would ever have played my first game otherwise. Feedback is incredibly important to learn lots of important lessons early on in any discipline, and jams really foster that. That was fantastic to experience, and I'm looking forward to it again.

With that said, My First Game Jam: Winter 2017 is well underway, and I have lots to do. Next time I post, a brand new baby prototype will have been born.

x"�1��\

#gamedev #gaming #hiddenpuncher #boyleandbubble #gamejam #game jam #myfirstgamejam

1 note · View note