Game Dev

Confessions of a Serial Game Jammer (after ~40 jams)

Some of my games

I just came across a great talk by Chris DeLeon regarding game jams and long term improvement: “Long-term improvement doesn’t happen in a few days per year”. In the talk, Chris warns those who do 4 brutal days of game jam a year as their main practice, that it is not enough, and speaks about why regular practice is important.

I agree and have more to add. I have some of my own observations and opinions as a very frequent gamejammer. I’ve done ~40+ game jams so far as a mostly-solo jammer, usually 1 or 2 jams a month depending on the duration of the jams (some are 1+ week long jams), and availability of more interesting jams. Here’s what I learned from doing jams much more frequently (4-10 brutal days a month for the past 3 years):

1. Regular practice and using Jams as tests: Yes, regular practice/exploration outside of jams is important. Jams are a great way to test/measure those skills that you practice. Think of the regular practice as homework, and jams as the exam. In the regular practice/exploration, you can just explore an aspect or technique (e.g. just do some artwork), while in a jam, you’ve got to put together the whole game (if solo). If you do jams frequently enough, then the jams do become part of the regular practice.

Or as a sports analogy, if you’re training for a triathlon, think of the jam as the triathlon event, and the regular gamedev practice as the sessions that you go swimming, biking, or running. Regular practice can also fit as a part of a longer jam…

2. Longer Jams: There are longer jams, such as One Game A Month, which allow you to do your regular practice while having a much more relaxed deadline/goal. These may be helpful for those who can’t do brutal short intense jams.

It’s good to vary it up so that you don’t get into the mindset of only being able to do 48-72 hour projects. The challenge in these longer jams is to keep the scope manageable, and keep motivated and disciplined. I think it’s good to mix up the length of jams that you participate in so that you can grow in these different areas.

For the art or sound side, there are those “30 days of _______” challenges that come up, such as NaNoWriMo, 3December, Inktober They aren’t game jams, but they have a community for you to share your daily creation with, even if you can’t do it every day. Getting encouraging feedback helps with…

3. Motivation: The thought of future jams and upcoming jams can give you motivation for learning new stuff well, so that you can use them during the jams. Also, when motivation is lacking, just commit to practicing your craft 5+ minutes a day. The hardest part is just sitting down and opening up the tools you use for making games/art/sounds/music. Once you get started, it’s harder to make yourself stop after those 5 minutes than it is to keep going.

4. Plateau? Nah. Jams can help to break you out of a plateau or kick you back into the gamedev itch after a lull.

Or if you are actually doing jams as your only gamedev, then I think the key is to create a personal challenge to stretch yourself for each jam you do (besides for doing jams more frequently).

Even after 40 game jams, I still learn something new, try a new technique, or hone a different skill in every jam. Have a goal or personal challenge for that jam; e.g. “I want to try adding a dialogue system this time”, or “I want to practice this new and funky type of 3D texturing that I heard about”, or “I want to focus on my story writing skills this time”.

More importantly: This personal goal/challenge has to have a higher priority than just finishing the jam or necessarily doing “well” in the jam. After finishing a few jams, you’ll get over the overrated importance of finishing the jam, and be concerned more about creating a game that is worthwhile to finish and has something new or interesting to add.

My personal challenge in this coming weekend’s jams (1) (2) is to make a 2D game (I usually make 3D games and am horrid at 2D). So right now, that goal is forcing me to learn 2D gamedev techniques that I can use at the jam. I know the game is probably going to be crummy, but I’ll learn a ton from the experience.

5. Check out the other jam games. You can learn a lot simply by playing through the other jam games in the jam from a reverse engineer’s point of view. A great thing about them is that they’re free and show what can be created in that time period.

Think about what you might do differently to make the games better. Find things that work well in other games. Especially pick up on new and noteworthy experimental things that other games do, though not necessarily well executed, but have potential. One good way to start is to write a feedback comment for a jam game is “What I loved about this game is….”

Did you like an aesthetic/mechanic that a game had? Then figure out how to make that aesthetic/mechanic, or ask the developer how they did it in the feedback comment that you give them.

6. Clean code: If you want to improve your efficiency by jamming, try to keep clean code and write it quickly, for as long as you can during the jam. Try that as a personal challenge, marking the proportion of the jam that you kept cleanish code. Only resort to crazy-spaghetti-code when you get to that point where you think “oh crap, only x hours left!!”

Try to improve your personal record of how far you can get through the jam without going dirty. Always keep in mind that you may want to continue the game after the jam. Contrary to what you might think, over the course of a few jams, you’ll notice that you’ll code more efficiently, or do things a bit differently in ways that save time.

On the flip side, if you don’t care about improving your clean coding efficiency and just want to focus on finishing the jam, then mess things up intentionally so you don’t slow yourself down with clean/well-engineered code. Use crazy/obscure/obscene variable/method/class names. Create a Globals class and put tons of stuff in there. For small projects, it sure is quicker. It will help you get over your inclination to want to write clean well engineered code, and get things done the quick and dirty style.

7. The Importance of Aesthetics vs Gameplay mechanics: So you made a jam game, and want people to play it. All else being equal, do you think more people who have only your game’s cover thumbnail image (and no other info about your game) are going to click on the game with the great mechanics and story but programmer art, or the game with the lovely polished stylized aesthetics but poor mechanics? From what I’ve observed, the latter gets far more clicks and plays in game jams, and are rated higher whether they deserve it or not.

That said, some of the most memorable jam games that I’ve played were actually Twine games, but I fear that the average player doesn’t have the patience to read through all that text.

It varies by the structure of each jam, but I find that the biggest factor in getting people to play your jam game is the cover image, and then the screenshots/GIFs/videos. It has to stand out against all the other games in the jam and on the jam’s site and on social media. In a large jam, games without interesting cover images are easily lost. A game’s amazing gameplay mechanics are wasted if no one is even going to click on the game or download it after seeing the screenshots. On the flip side, a good aesthetic has the effect of making up for lack of good game mechanics – I’ve seen time and again where it makes players think it is a better game.

If your game is lacking in good aesthetics, then make an extra effort to at least make an outstanding thumbnail cover image for the jam’s site. That is a whole topic in itself that I cannot cover in this post.

Unfortunately, I don’t usually have time to make a game’s thumbnail cover image for the jam’s site until the final minutes of the jam, or even until after submitting. I’ve learned that having good in-game aesthetics naturally helps make it easier to create a cover image quickly:  take a screenshot of game assets posed dramatically, and put on some typography. It also makes it easier to take good screenshots/GIFs to share and promote the game.

8. The “Right Way” to Jam: Too often, I’ve heard other jammers say that the “right way” to do game jams is to get the mechanics down first, with placeholder everything, and then make the art/assets and polish. That makes a lot of sense if your goal is just to finish a playable game, but I don’t think that necessarily result in a “sexy” game that people will click on, since the aesthetics are prioritized last in that order.

Nowadays, I typically start with, and spend most of the time on the aesthetics. I pretty much start by picturing moments, interactions, and feelings based on the theme, and picturing a screenshot of a quintessential moment in the game. After making and seeing the interesting aesthetics, I am then inspired to come up with story/interactions/gameplay/levels. Sharing the aesthetics with others and seeing how they react to it helps to inspire the rest of the game.

Often I don’t know exactly what the gameplay mechanics or story will be until the final quarter of the game jam. In some cases, this isn’t until the final “make it work” hours of the jam, where I go into quick and dirty mode, and the real magic happens at miraculous speeds due to time pressure, lack of hesitation, lack of perfectionism, lack of concern for cleaning up code after the jam, and lack of sleep. Some of my best work and/or most critically acclaimed work has come from these final magic hours, doing gamedev the “wrong” way:

  1. Lord of the Aisle – the gameplay mechanics, waves, dialogue, all came in the final magic hours. This game jam game, which had some idiotic gameplay mechanics and an interesting main character aesthetic had 200+ Youtube videos made about it, and even pirated by a dozen other game sites. I spent most of the time making the main character, a random shopper generator, and random supermarket shelves generators.
  2. Infinite Monkey Autocorrect – the game is almost entirely aesthetics with no real game mechanics, but was voted #1 for Innovation and #2 for Humor, out of 1637 games in Ludum Dare 34 (72-hr Jam). WTF is wrong with the voters, right? It’s pretty, but is it even a game?
  3. Lullaby For An Electric Toaster and Shadow of the Red Hand – the levels are all made in the final hours, which is an obscene thing to do for platformers, where the levels are the game. Most of the time was spent in the aesthetics/artwork. Lullaby was voted #1 out of 21 for LetsCookJam, and Shadow of the Red Hand was voted #10/1574 for Innovation and #11/1574 for Theme, out of 1574 games in Ludum Dare 35 (72-hr Jam). Both of these games had wonky controls, yet they did “well” in the jams and were popular with YouTubers.

I’ve found it a good idea to keep the game mechanics relatively simple and unoriginal for jams. From my observations, very few players, especially YouTubers, have the patience to learn novel or experimental mechanics. Written instructions are almost useless except for the 1 in 10 players who will bother read them.

I’ve tried making jam games with more novel or experimental mechanics, and it is usually not received as well as my games with simple mechanics.

I think each jammer needs to discover their own “right way”, based on their styles, skills, and experiences. Don’t just blindly accept other jammers’ “right way” as your own. Even your own right way will change with time.

8. The Idea Fairy: I have to admit, once I got the game jam addiction, I haven’t really been able to stick with a single non-gamejam game project of my own. It’s not that I can’t work through longer projects (I routinely do longer projects for my clients), it’s just that shinier new game ideas keep coming along. I have several game jam games that I want to turn into full games, but keep getting distracted by the next shiny game jam, which produces another shiny new idea that I want to turn into a full game.

Because there are so many game jams to choose from nowadays, it’s hard for me to resist not jamming.  And when I return to my old in-progress full game projects after being interrupted by a game jam or two, I feel like they are already obsolete, or my heart is in a new idea.

It sounds a lot like the Idea Fairy comic by theMeatly. It’s not a problem unique to game jammers, but frequent game jamming sure does exacerbate the problem. Beware!

Comments Off on Confessions of a Serial Game Jammer (after ~40 jams)

Lessons Learned From 191k Views on Youtube: Lord of the Aisle

lord_of_the_aisle_1.2.0 title

I wasted a great opportunity when my game received 191k views on Youtube in its first 10 days. Here are my lessons learned and what I would do differently.

Backstory:

Only 10 days ago, I uploaded my game, Lord of the Aisle, for The Arbitrary Gamejam 17. Already, there have been 39 Youtuber videos made of the game, ~191k views of the videos, mostly playing the old glitchy version of the game that was initially released for the jam’s deadline. There have been at least ~10k downloads/plays of the game, across multiple sites, some of which I did not even know were hosting downloads of my game.

Usually, my game jam entries only get 2-4 Youtubers, with a handful of views, and less than 1k plays/downloads within the first 10 days, despite them being around the same quality as this game. You can imagine my surprise by the number of videos, views, and downloads this time around.

I must admit that I have blown a great opportunity and capitalized very poorly on the publicity of the game, but learned quite a few valuable lessons.

Lessons learned:

1. Once you upload a free game, it’s out of your control.

Even if you only upload your game to a single site, it may grow legs and find its way to other sites. It doesn’t matter that it is a free game in a tiny game jam.

Even though Gamejolt.com was the only place I uploaded Lord of the Aisle, somehow a dozen other sites are now hosting the game (old versions of it) too! They never contacted me, nor credited me, nor got my permission, and I would not have known if I had not done a Google search or watched the Youtube videos.  It’s a free game for a game jam. I did not expect to make any money on it. But it irks me that these other sites are making ad revenue off of my game, and I’m not getting a penny of it. Some of the other sites must have ripped the Unity Webplayer version of the game from Gamejolt. I didn’t realize that they could or would do that. Now I know.

The problem is that I have no control over the game’s description, the game’s version, or way to communicate with the game’s audience on any of those other sites. If I wanted to make a commercial version of the game (and I intend to), I can’t really reach out to the audience on those other sites. I can’t even post a comment to some of these other sites. Some of the other sites are in other languages.

Lesson learned: For future games, I’m definitely going to put an in-game link to the real site within the game, and perhaps add a simple feature that lets the player know if this is the latest version of the game, where to get it from, and displays a message from a remote online source that I control.

2. Old buggy versions will live around forever.

The initial version I submitted for the game jam had minimal testing due to time. I had no time for performance optimization or even performance profiling. From the early Youtube videos that came after the game was released, I saw that the frame rate becomes very low during later stages in the game on less powerful computers.

Very soon after, I uploaded updated versions onto Gamejolt, fixing the bug, but it was already too late. All of the other sites still have the old glitchy version of the game, and I have no way of updating those. And most of the Youtubers recorded using the old glitchy version. How embarrassing!

Lesson learned: Make sure you have some way to communicate updates with the audience of your game, which may be hosted/downloadable from unknown sites out of your control. Do this right from the start.

3. Most players of free indie computer games probably have slow crappy computers. Target them.

(This is purely anecdotal/conjecture – if you know of an article with stats about the computers of indie gamers, please let me know!)

Indie game developers often have a perception bias when it comes to computers. Most indie game developers are likely to be enthusiast gamers, who are more likely to have higher end computers, which are capable of playing a multitude of games (including intensive AAA games). They may commonly associate with other enthusiast gamers and developers who have high end computers. And so they may become less aware of the multitude of casual indie gamers/youtubers who have low-end budget computers.

On a high end machine (like many game developers probably have), a game issue causing a 50% frame rate drop from 120 frames per second (FPS) to 60 FPS will not even be noticible unless you’re specifically checking for it or doing performance benchmarks. (There’s usually no time to do that in a game jam, of course!) But on a low end machine, this drop could be a disastrous showstopper.

Lesson learned: If you only have high end machines to test with (even if it was a high end machine from a couple of years ago), at least do a run through with a reliable FPS meter or other metric even if the game performs perfectly fine on your machine. Would the game still be playable at 1/4 of the performance? What about 1/8th of the lowest framerate?

Also, if you develop in Unity, keep in mind that the FPS meter in the built-in stats display is quite inaccurate! It was displaying the frame rate as ~180-220 FPS when the real frame rate (# of times Update was called) was only ~50-80 FPS. I’d recommend Frame Rate Counter (free on the Unity Asset Store) or writing your own simple FPS meter.

 4. A game is initially judged by its cover. Spend enough time on the cover.

Spending extra time to put an interesting character or interesting artwork in the thumbnail/title is probably worth the effort.

Let’s say you made a great game. But the game has a poor thumbnail/title image. It will likely be at a disadvantage at attracting players versus a crappy game with a great cover. When visitors see the game’s thumbnail in a listing among other games with their thumbnails, the thumbnail may have only milliseconds to capture the visitor’s attention before they move down the list.

I’ve made quite a few other free games for game jams that are on par with the gameplay/artwork of Lord of the Aisle, but in the past, I always left the thumbnail/title image to be created hastily in just the last few minutes before the submission deadline.  So usually, the thumbnails I made in my old games are just text on a background pattern or vague screenshot – they never really told you much about the game itself from a glance.

However, with Lord of the Aisle, I spent a long time creating an extra scene in Unity, specifically for the thumbnail/title. It includes the main character and setting of the game in the backdrop. I know it doesn’t show, but I also spent an embarrassingly large amount of time experimenting with fonts/typography. It still wasn’t quite there yet, but apparently it was enough, and far more effort than the titles I’ve initially made for my other free games for game jams. I guess it paid off:

lord_of_the_aisle_1.2.0 title

 

Comments Off on Lessons Learned From 191k Views on Youtube: Lord of the Aisle

Lessons Learned from Love Bandit and #TAGJam14

Screen Shot 2014-09-09 at 9.55.17 AM thumbnail

Here’s my game, Love Bandit, made in ~72 hours for The Arbitrary Gamejam 14 (Sept 2014)

Play now (Unity Web Player on Gamejolt)

The themes of the game jam were: “Breeder”, “Neutralization”, “Criminal”, and “Surprise!”
The bonus rule was to add a “Did you know…” feature to the game.

I made the game using Unity 4.6 Beta (Pro) to test out some of the new features, Blender for 3D modeling and some simple texture painting.

Lessons Learned:

Most of these are pretty technical except for the last ones. If you know of a better way to do some of these things, or have your own lessons learned about the items, please share. Note that I didn’t necessarily do things the “right” way or even the best way, just the most expedient way during a game jam.

1. Linear Lighting Model:

After watching the videos from Unite 2014 about physically based shading (here and here), and seeing how they use a linear lighting model (rather than gamma), and HDR (high dynamic range), I’ve tried using a linear lighting model with HDR, bloom, tonemapping (AdaptiveReinhardAutoWhite), color correction. With this setup, you get a lot more control via effects on the camera, instead of just the in-scene lights and render settings. It allows smoother transitions between lit and dark areas. I didn’t notice that much else besides for the haziness around the brighter areas due to the bloom.

2. New UI:

Unity 4.6 Beta’s new UI are a lot easier to work with than the old UI which I have often complained about. The new RectTransform component on them makes it a snap to position UI elements or make UI elements stretch according to the screen. For example the Love Meter bar automatically resizes based on the game screen’s width so that it’s right side is at 50% of the width, but the left side of the bar is a fixed position from the left (See first image in this post)

Here was a super quick last-minute title screen made using the new UI. I was planning to add buttons to it that allowed you to jump to a level, but didn’t have enough time:

Screen Shot 2014-09-09 at 9.31.02 AM

Not the best layout, but given only few minutes, and that the background is animated, it will pass. I think I took 5x more time picking out the font.

3. More Shader fun:

The cross-striping on the ground and mushrooms is made using a custom written shader, as opposed to the ground in Boobstorm (my game from the previous gamejam) which was just a texture. Custom writing a shader allowed me to keep the stripes sharp at any resolution and at any zoom level since it is procedural. The stripes are based on the position in the world. This also allowed me to get away with not doing UV maps/skinning for the stripped elements, saving some valuable time. It also allows elements to be resized or stretched without the texture being stretched:

Screen Shot 2014-09-09 at 9.14.24 AM

If anyone is interested in learning shaders for Unity, here is a good tutorial series on cgcookie.com.

4. Map indicator:

This was my first time trying to do a direction indicator UI 2D, pointing to the direction of an objective, and hiding itself when the objective is onscreen. See the little black arrow on the left:

Screen Shot 2014-09-09 at 9.51.03 AM

Here’s the pseudocode:

– Project the 3D position of the objective to screen space.
– Calculate the acceptable portions of screen space that the arrow will be visible in (margins from the sides of the screen, taking the radius of the directional arrow sprite into account, assuming a central origin to the directional arrow sprite)
– Check whether the objective’s screen space location is inside that acceptable portion
– If not in acceptable portion, disable the arrow.
– If in acceptable portion, clamp the arrow’s position to the acceptable portion of the screen, and rotate it to point away from the center of the screen, and enable it.

Here’s the actual c# code.

I had tried using a second camera looking at the objective (your face in the game) and using that as the arrow. It was cool, but didn’t do the job as well as just a plain arrow. I should have made the arrow more visible.

5. Coroutines, Pausing, and Cutscenes:

I had previously avoided using coroutines for many things because I was afraid that they wouldn’t stop if the game was paused. This time around, I learned that Unity coroutines behave according to Time, and if you set Time.timeScale to 0, it will pause the coroutines as well! This allowed me to come up with a quick cutscene framework to easily script and coordinate different actions (camera movement, fade-in fade-out, text display) in the intro and tutorial without having to fuss around with separate animations.

For example, the intro cutscene is scripted with just a few lines using the framework:

Screen Shot 2014-09-16 at 10.43.08 AM

Also, scheduled coroutines can be terminated using the StopAllCoroutines() method, allowing for an easy way to skip a cutscene. Of course, at the beginning of the next cutscene, set the state to what it would be after the first cutscene, just in case it was skipped.

I’m planning on perhaps generalizing the cutscene scripting framework for reuse in future projects and to share on the asset store. Right now it is just messy code I cobbled up during the game jam.

6. Ugh happened with Unity beta:

[Update: I figured out that the Tonemapping (AdaptiveReinhardAutoWhite) image effect does not work well with the Vignetting image effect on wife’s machine. This is not specific to just Unity 4.6 Beta, it also happens with Unity 4.5. When the camera has both of these, it causes the colors to go super dark.]

Somehow the game did not work right on my wife’s computer. It worked right on every other computer. I made this game all cutesy since my wife likes cutesy games! The lighting somehow ended up super dark on her computer (as if there were no lights or ambient lights). I wondered if it was because of the Linear Lighting Model (see point 2).

So after the jam, I went through the trouble of making a branch of the game to be the normal gamma lighting model and retweaked all the lighting, but nope, it still looked the same, lightless, regardless of web build or native build.

She’s got a Mid-2010 iMac, running Mac OS X 10.9.4 with an ATI Radeon HD 5750 1GB. It works fine when booted up in Windows 7 mode though.

I’ll chaulk it up as a Unity 4.6 BETA issue with Mac OS X since my past Unity 4.5 stuff all worked fine on her computer.

7. Tutorial and explicit gamejam mention:

With my last game jam game, the players mostly seemed to miss that the game was part of a game jam with really wierd themes/rules (and I made a game too tailored for those themes/rules). They also missed out on the instructions too. This time, I built in a tutorial, and based on the feedback comments and youtube videos (by patient38 and by DeathandGrim2), it worked.

Unfortunately still, our poor sleep-deprived host (@SnoutUp, thank you for hosting!) missed the statement that is boldly on the first line of the Gamejolt page’s description: that the game was a non-competition entry , and he declared it the winner initially :) Next time, I’ll make sure to put a statement that it is a non-compo entry within the game itself so that no one will miss it. I’m just not fond of having to add so much extra text to the game – the title screen is getting crowded. The real winner was BroodStop, by @ThumbsBlue, whose game I probably spent more time playing (and still haven’t beat, but it is on my bucket list) than I played my own.

8. Last Minute:

Level 2 and 3 were built in the last 2 hours of the gamejam. I had a choice of building them or just polishing the existing intro, tutorial, and Level 1. I’m sure glad I added level 2 and 3, since they demonstrate some different possibilities (obstacles, and moving faces) for future levels. I literally finished submitting the game with less than a minute left. So the lesson learned is to go for the gusto. It’s a game jam after all – the place to have fun and push yourself without much consequence of failure. If not here then where?

9. Recovery:

It takes about a whole entire week after a game jam for me to get back into doing my normal gamedev. This may be due to my lack of sleep from the jam, burnout?, marketing of the gamejam game, playing the other gamejam games, writing a blog post, or just the resting on laurels and procrastinating. It shouldn’t be like this. I should be able to use the momentum from the gamejam and spring right back into my normal gamedev. Dunno.

All in all, I had a ton of fun, and definitely honed my gamedev abilities in the frenzy that was Love Bandit. I’m excited for The Arbitrary Gamejam 15 in October 2014. I hope you to see more of you join in!

Comments Off on Lessons Learned from Love Bandit and #TAGJam14