Making games is hard…but worthwhile. When we first started doing this a couple of years ago, we decided to try and start small with our first game so we wouldn’t kill ourselves or fail to put something out. The problem with that was that we did not yet understand what “small” would actually mean in a game. Our first project, Farmageddon!, was probably overly ambitious for our first game. I had never developed one before, Kelsey had never drawn for one, and Jhett…well, Jhett had designed a bunch but not built/released on this scale. From there, we decided on another simple-ish game, Gemlight Alchemy…except that this game turned out to be muuuch more complicated. Our group had grown and we wanted to make something bigger, so we designed out this wonderful project, even got it to the point of a playable prototype at our booth for Boston FIG, before realizing that we, quite simply, weren’t good enough to make this game yet.

It was around this time that Kels and I went to our first Global Game Jam. For the uninitiated, this is an organized event, hosted at lots of locations around the world simultaneously, where people are given a theme for a game, and form groups with strangers to make a game in 48 hours. The process was very educational. Simply the process of making a complete game (even a tiny, crappy one) was hugely beneficial.  With this in mind, I approached the NPG group about the idea of taking a break from Gemlight to instead work on a few tiny projects. Really simple 1-2 mechanic games that we could build in a weekend or 2.

The Fish Game

Do you remember this toy?  This was the inspiration for our first game jam. We simply made a 3D version of this in Unity. This was only our second time poking at Unity (our first was for the Gemlight prototype for FIG), and we actually learned a a lot.

  • GDD:
    • We did a Game Design Doc for the first time. Not a great one, but we are still working to do better at this. For people thinking of making games who try to bypass this step: Don’t!
  • Terrains:
    • We played around with terrains for the first time. I played with them for a while very confused before someone showed me that the terrain default size is so HUGE. In fact, the first iteration I had put together wound up having giant fish the size of skyscrapers floating in a huge sea surrounded by mountains…not a fishing pond…
  • Cartoony-3D:
    • The first attempts at the models for the fish were…fish. Which was terrifying. Fish mouths do not open the way we wanted them to, and the effect of having those realistic fish opening and closing their mouths was… it was creepy.  The second attempt was much more cartoony and adorable. We used a similarly cartoony style when designing Sammy for our next game.
  • Moving, and specifically rotating GameObjects in Unity:
    • Because we were modeling ourselves off of the fishing toy, we had a ring of fish that would be rotating around a set point at the center of the pond. Accomplishing this in Unity is, it turns out, rather trivial. We set all of the fish as children of a single parent GameObject, and attached a script to the parent telling it to rotate a little every Update (or once every frame in the game).
    • Though this was a simple implementation, it was the first time I had ever programmed anything to move like that. The fact that I was commanding individual motion with commands at the fish level (we had them bobbing up and down) and group motion simply by placing all fish as children of another game object was an interesting sort of paradigm shift for me.

Sammy Quest a.k.a. Puzzle Planets: Sammy’s Space Oddysey

Our next game started out as a sketch of a couple of 4×4 grids with paths drawn through them.

BetterSnippet

The idea is a simple 2D maze/pathing puzzle game. The goal: draw a path from the start point, through all the cells, to the exit point, without repeating a cell. We decided to do this game in 3D, from a diagonal side-view, which let us have a 3D character moving around solving the puzzles with the player. Enter Sammy:

Sammy Sketches

We settled on the idea of Sammy the space tourist on a planet-touching expedition. For some reason there are sets of Space Platforms floating above the planets with mazes built into them. In order to progress from one platform to the next, you must maneuver from the starting tile to the exit tile, while crossing over all other tiles exactly once, and moreover crossing any tiles with floating numbers above them in ascending numerical order. This project wound up taking us much longer because we wound up enjoying working on it, and enjoying playing through the levels.  We decided to make this our second release as a company, still much smaller in scale than the still-looming Gemlight Alchemy.

One of the first things we learned in Sammy, was designers (game/visual design) should “be more specific”, and developers (me) should “always grab a designer and review any added feature (not just if its being ‘finalized’)”. We ran into an issue where I was given an incomplete design for a particular feature, the beacons that go up when you pass a number tile, and proceeded to implement something I figured would be temporary, but would let me know if the feature was being triggered as I wanted. (Important note: I am not an artist, though I am OK at UX.) The original “beacons” that I made were sort of crappy white and blue fountains of particles (large ones…it looked weird). I implemented that so that I could move forward, assuming it would simply be changed later once there was a real design. Unfortunately, it wound up slowly just becoming accepted as the actual feature until someone finally pointed out that we should design a real version (months later). This bad feature, that was never intended to go into a final product, was almost slipped into the final game, and it could have been prevented much sooner if we adhered better to the 2 aforementioned lessons.

Another important lesson (from this as well as Farmageddon!) was Beta Test your tutorial. As a developer and game designer, tutorials have been the bane of my existence these last few years. Making a good, concise, and effective tutorial that isn’t obtrusive or condescending is tricky.  A beta tester thought of a way that we liked, involving little highway signs floating on asteroids along the path. This allowed us to have a tutorial level pack, with one instruction/sign per level spelling out all of the rules and mechanics one at a time. This would also let us use this conceit to place funny signs along the way to the other planets, and kind of give all of the planets a bit of personality.  It also helped make it feel more like he was a space tourist which wasn’t really shown before. After we got this implemented, we sent out our new shinier version to beta testers and got a much better reaction, started getting complaints that people were getting stuck, and needed a “restart” button. Funny story there is that we actually had one, but then we removed it when we implemented the ability to tap on a tile in your path to backtrack there…the problem was that the sign with that instruction was 2 levels past the first place someone could actually get stuck and need to backtrack. Our solution was to create a still with the path from the second level drawn out, and with some instructions overlayed, and present this image when starting the first level. We then moved the backtrack sign to the second level and got no more complaints.

Another, somewhat controversial lesson I learned was complain earlier. There were a couple of features that almost got pushed, even though they were not really liked by anyone and fixing them wound up taking only a couple of hours. It was actually on a day when we were going to just ship the game out (the team was getting tired of this game and wanted to get started on Gemlight), that someone brought up something they didn’t like in the game, and a number of issues that people had been having that they hadn’t said anything about came up. All of these things wound up being easily fixable, and delayed the push by a total of 1 day. Thanks to this, we have meteors that move and look the way we intended, a not-terrible skybox, a much nicer level select screen, and a credits screen (asking people to rate us!).  While good for the game, this was actually really frustrating to a number of members of the team. The solution here is just complain earlier. Not necessarily often, just earlier. Odds are you are not alone, and if that is the case, then things are changeable, especially in a small team, and it is better to do that sooner so it doesn’t come up at a time when you are pushing and everyone is stressed to be finished.

Another, somewhat unrelated thing I learned was rate the games that you like. Apparently this isn’t just for checking the relative good-ness of games, but is innate in how things show up in the app stores. Despite no other games with the name puzzle planets, we don’t even show up in the first page of results unless you search for “puzzle planets sso”.  This is apparently a consequence of our not having enough ratings. Now, we aren’t as invested in making sure this game sells amazingly, as we are giving it away for free (although if we do get alot of downloads, we plan to release more level packs with new mechanics in a paid version. No micro-payments, just buy the new version for a dollar). But this sunk home to me why games make sure to ask that all the time, and inspired me to start making sure to rate the ones that I like.

There were more lessons to be learned from the process, and I’m sure the other team members have their own share of take-aways.  The important thing here is that the best way to learn how to make games is to make games and start simple. Make simple games. Make crappy games. Make checkers or tic tac toe. You will learn more than you expect. And accept that the first few won’t be great. In fact plan for that. Plan to make 3 crappy (but complete) things and then something you care about, because if you start on something you care about, you will be disappointed by your lack of experience, and risk spending months and months longer and learning much less than if you simply “finished” at a lower quality game and moved on.  During this time the important thing to improve is the process, rather than the product.

I kind of feel like this advice works for many other disciplines, such as art or learning an instrument. The best way to get better is to just do it and to be okay with being bad for a while. We of course have much more to learn but at least feel like we have progressed to the point where Gemlight is ready to be our next game.  I look forward to see what we learn from this project. :-)

One thought on “Lessons learned from Jamming: A look back at the last year of NPG development.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>