The Importance of Pre-Production

I am doing a podcast with my friends about games (check out The Adventure Mechanics here) and I decided that I need to try for accountability on actually releasing a game this year. To that end, I'm going to go through the development process to release a game. Here is the transcript from my first episode on accountability:

Welcome to the Adventure Mechanics Side Quest and it's only going to be me, Chandler, today. This is going to be a mini-series where I look at some of the grittier parts of game design. It's also going to be a form of accountability for me as I take a game from prototype to a more fleshed out game. I have been a hobbyist game developer for a while now, and need a kick in the ass to get a project past the prototype phase and actually publish something. For this mini-series, I'll be taking one of my prototypes I made for a game jam and fleshing it out to a complete game.

So, where do we start? Well, if you haven't done something like this, the first step is planning. It's not the sexiest part of game design, but if you approach it with creativity, you can end up with something great. This first step is going be coming up with a workable idea. How do you come up with a concept? Well you can peruse through old game jam themes for inspiration or looking at an existing game design for your game. The most important part to keep in mind, however, is how much you can realistically make. If you're a solo developer and want to make your Magnum Opus, be prepared for the years of work that will take, despite it, "just being a copy of that sweet MMO/Battle Royale/whatever." The games you're using as a rubric had many developers each with more experience than you. As a side note, if you have made and published a game and are for some reason listening to this, I would love to hear your experiences.

The prototype I'll be using for this is an entry I made for OMGJam6 about mapping the world around you. I called it "The Mapper". It was my first solo entry for any game jam, despite participating in about a dozen game jams before OMGJam. I didn't get nearly far enough to really test out the concept of this game, so I am going back to this and working on getting the prototype more fleshed out. I feel like there's a good game in this idea and I want to spend some more time working on it to see if I can suss it out. For the purposes of this pre-production, I'm giving myself a month to get the prototype out. Here's what I have planned for this game so far:

The pitch:

You are a cartographer that has arrived at a small frontier town in need of your services. Problem is, you haven't mapped the area yet. You need to set out on expeditions to map areas of interest, making sure that you bring enough supplies to survive in the wilderness. With the hard-earned information you gathered, you can then help the town thrive. Be careful to not put yourself out of business, however. A townsperson with a whole map won't need to come back to you for your services again. You have bills to pay, after all.

[The Mapper] is a top down exploration game where the player must manually create a world map and sell portions of it to to make ends meet. The cartographer's office needs to be maintained and the player needs to be fed, creating the tension of the town getting the supplies it needs while not giving too much away where the townspeople no longer need the player.

To further flesh out The Mapper, I'm going to be formalizing the gameplay loops that I am envisioning for it. What's a gameplay loop? A gameplay loop describes what the player will be doing during a typical game session, or series of game sessions. The primary gameplay loop describes the lowest level repetitive task the player will be doing. For Diablo and it's clones, the primary gameplay loop is: kill a monster, pick up loot, sell loot that isn't of value to player. There is more to Diablo, of course, but the primary gameplay loop can be condensed down to that. Any gameplay loop that builds on top of the primary is a secondary (or higher) gameplay loop. In our Diablo example, a secondary gameplay loop is to navigate to a given location, collect an item, and return it to a townsperson. There can be many secondary gameplay loops, but it's important to define all the gameplay loops that you want to implement beforehand.

For my The Mapper prototype, I'm aiming to get the primary and secondary gameplay loops ready. The primary gameplay loop is:

- buying supplies for an expedition

- exploring the world outside town

- noting where things of interest are on a map that the player manually fills out

- returning to town before the expedition supplies run out

A secondary gameplay loop I am planning is going to be something like this:

- player selects townsperson quest from queue

- player selects the tiles (or path) from their map that they are going to sell to the townsperson

- townsperson paths to the goal tile

- if townsperson returns, they go back into the available for gathering resources pool

There will be other gameplay loops that I will want to implement, such as updating the map to reflect improvements, evading predators, and collecting supplies in the wilderness, but this will be enough for the first prototype. I only have a month to finish this, after all.

Once you have your idea, come up with the absolute basics of your design. What are the controls of your game? Are you going to be using existing conventions, such as the traditional FPS health packs or regenerating health? How do you expect the player to interact in your world? Write down the basics of what you want the player to do or feel. This is the most important part of coming up with a design. Once you have that, any feature you consider adding will have to either be in service of your initial design, or the design itself must change to accomodate the added feature. This step ends up forcing you to consider the game holistically, so you check yourself before adding to the game impulsively and getting yourself stuck in a cursed problem where two features you want are fundamentally incompatible.

In The Mapper, I will be breaking up the game into two different parts: The meat-space, where the player controls an avatar through the world, and the map-space, where the player interacts with the map they generate. With the meat-space, I'm planning on it having controls similar to the Legend of Zelda, with one hand controlling the movement of the player and the other interacting with the world. I plan on having support for both a controller and a mouse and keyboard. I'm not envisioning the player needing more than four buttons for interacting with the world. As the player moves around the wilds, they will see interesting features. Features will be of four different types: Landscape, such as forests and rivers, Resources, such as berry-filled glades or fishing spots, Fauna, such as fowl or bears, and Improvements, such as abandoned towns or roads. It is up to the player to notice and note where they find these features on their map. There will also be hazards in the world that the player will have to deal with, but I do not intend to add any real way to permanently deal with flora or fauna hazards. To that end, the player will not have an attack to use on hostile fauna. I envision that the player will be able to carry equipment to placate or distract the fauna, allowing the player to get away. These may be placed into a context menu or basic inventory.

For the map-space, I plan on having the primary interface to be selecting map tiles and either adding or removing features from the tile. Whatever control scheme used for the meat-space will be mirrored in the map-space. That means if the player chose a controller, the map-space interface will accomodate a controller. That means the map-space navigation will have to be flexible enough to accomodate either input method. The controller setup will focus on moving, highlighting and selecting tiles. The keyboard/mouse setup will work similarly, but will not force to have a highlighted tile. While exploring, the player will be able to open up the map at any time and select a tile to add or remove features. The interface will not highlight the tile that the player is currently on, but rather keep the last tile modified highlighted. I do not want the player to use inappropriate clues from the map to verify it's accuracy. When "selling" information to the townspeople, there will be a goal tile and, if there is a specific path the player wants the townsperson to take, a path from town to goal. What the townsperson needs will be shown on screen somewhere during this pathfinding process.

Notice how I haven't mentioned anything about the technology to use when I described the basics of my interface, beyond the input device support. That step will come after you have come up with your design. Pre-existing game engines are great, but some are better at some things over others and your design should guide you towards an engine/language/whatever that is best suited for your idea. If your concept comes with an existing prototype, great! The choice of what to make it in is that much easier. Otherwise, you'll need to consider what you are most comfortable with or are willing to learn versus the capabilities of the engine that you are looking at.

In my case, The Mapper jam entry I created for OMGJam6 was created in PyGame. PyGame is a simple engine that gives me control of input devices and has basic capabilities of drawing to a screen. I chose to continue in PyGame because it was what I was most comfortable with and had enough capabilities for my purposes. I could have used a more feature-rich engine, such as Unity, Godot or Unreal, but I wanted to push myself to really know what was going on in my engine. I didn't want to have easy access to those extra features so I am forced to work them out. That is why I ended up settling on PyGame once again.

One last thing I wanted to talk about for pre-production is creating a timeline. On larger projects, this falls onto project managers who (hopefully) know what the capabilities and limitations of their team are. On a hobby project, such as this one, that falls onto you. Keep realistic goals in mind, breaking it down to accomplishments you can achieve in short time frames, such as a week or two. This is not the time for optimistic projections. This is what you will be using to hold yourself accountable, so build in some padding as you move forward. You don't want to set yourself up for failure and giving leeway for unexpected roadblocks only ensures that you won't fall behind.

In my case, I have broken my progress down to milestones on a week by week basis. I am only doing this on a spare-time basis, so breaking it down further wasn't going to help me measure my progress. I also chose a week length, since I find that I will put off tasks that have longer timelines. So, for the next month, I have a series of milestones that I am pushing myself to achieve. By the time the next episode of this podcast releases, I will have a prototype ready, along with another topic to discuss as I push to get this game to release.

Thank you for listening this rather rambly podcast. As always, if you have any thoughts, questions or feedback, reach out to me @jcsirron on Twitter. This has been the The Adventure Mechanics Side Quest. I'll talk to you next time.

Bye!

 

Role playing and the game designer

I have been playing role playing games since I was a kid, albeit video game rpgs.  Diablo and other action-roleplaying hybrids were my introduction into the game type.  I started playing juicier role playing games later with the Fallout series.  Even as the level of immersion increased with each game I played, I felt as if I was only a spectator in them.  I wasn't free to do as I wished in these ginormous worlds.  The limitations of game engines and developer creativity stifled my desire to play out characters I built.

When I started dating my now wife, I was introduced to the world of tabletop roleplaying.  She is an avid role player and her friends kept pushing me to join.  Being the techie in high school, I always used to make jokes about Dungeons and Dragons, using it as a punching bag.  I didn't want my carefully created self-image to be "sullied" by something as trite as pen-and-paper rpgs.  After all, I was playing much prettier games on my self-built PC.  When I finally caved, I realized how wrong I was about the tabletop and what it means to me as a game designer.

Why is it important?  It puts into stark relief how fragile your carefully thought out story and "immersive" speech tree actually are.  I foolhardily started as a DM, not just a player.  "I've built games, surely building an engaging dungeon crawl isn't that hard!"  Man, was I a fool.  I got my first dungeon crawl mocked up, with a prison that changed layouts and everything.  After an agonizingly long character build session, the party sits down, and...  I break a cardinal rule in DMing.  I dump one of the players into a fight already in progress without letting them know first.  I thought it would build tension and incentivize the party to go to the prison first.  I had no idea that the party would want to actually explore the town.  Tough first step, but not session breaking.

After some rather strained improv, I was able to get the party to the prison and introduce them to their final player character.  They go a bit further into the prison, finding a circular room with an oculus shining light into the center of the room.  At the center of the room was a pedestal and a note.  I figured the party would take a look at the note, maybe a quick glance at the pedestal, and then move on.  That's what I would do in a PC rpg, why wouldn't it work here?  No, no.  They spent at least an hour investigating the room and the pedestal.  Players become obsessed with the oddest things.

After all was said and done, the group still had a good time in the limited setting I had created.  The experience taught me a lot about what players experience when playing role playing games and how my expectations differed wildly from the experience that they had.  As I continue to develop games, I look back at my time playing D&D and remind myself that, no matter what I do, the experience I craft will not necessarily be the same experience that the player has with my game.

My thoughts on running a Ludum Dare without the rating period

Over the past month or so, there has been a kerfuffle within the Ludum Dare community.  It seems like Mike Kasprzak has been unable to rectify the need to build a more current website for the community and the responsibility of hosting the next Ludum Dare challenge.  This has caused quite a few feathers to get ruffled in the comments section relating to any post relating to LD36.  Some people have been asking about keeping the voting in some capacity, while others have been threatening to not participate in protest.  Sometimes an internet community explodes about something that they have ignored when they could have had some real input.  I'm rather baffled by this phenomenon.

Don't get me wrong, I personally loved getting the ratings back from my work on any given game I submitted for the challenge.  Feedback in a convenient number form is highly informative (and intoxicating).  This should not, however, be the make or break condition for whether or not you enter the challenge.  If you are the type of developer that absolutely has to have the feedback of the community, you are chasing the popularity contest to the detriment of your game designs.  I've been guilty of this fallacy on occasion.  Those games that I have made in this mold are games that I am not proud of.  I'm not sure that those games I've played "inspired" by community ratings are any better than those truly original games submitted.

Most comments I've read protesting this (hopefully temporary) change boil down to this:  "I'm not happy because Mike's decision effects my plans!"  This does not contribute to the conversation at all.  More productive comments have been consistently bashed until those commenters simply stop contributing to the conversation about the future of Ludum Dare.  Not only is this non-productive, it's actively harmful to the community as a whole.  I've seen it happen before.  The hackerspace I founded was initially an open community where people would step up and volunteer for what needed to happen for the good of the space.  Now that same community is having extreme difficulty finding anyone to volunteer for anything, be it for classes or simply keeping the space clean.  Volunteerism died because the vocal minority was tearing down the community constantly.  Unfortunately, elements of that minority were in control of the 'space.  I'm seeing the same thing happen within the Ludum Dare community now.  If we let these elements control the conversation, we'll have lost the little nugget of gold that so many of us enjoy now.

Moreover, many of these "protesters" have been the late arrivals to the discussion and are now getting pissed about not being listened to a month after the decision was made.  That's like going to dinner late and not being happy about the menu.  You came in late.  You missed the planning and cooking stage, so you've lost the ability to change the cake now.  If this event is so important to you, you should have been more involved in helping out with it.  I haven't been involved in the community's maintenance, but I know that there is a way to join in helping out.  At least occasionally checking in with the community between numbered Dares would have clued you into the issues hosting the challenges.  If you don't like the direction now, get more involved in the future.

I'm assuming that most of this anger comes from a place of passion:  Passion for the Dares goes deep.  I got the bug my first Dare.  I know those that participate in a single challenge almost always have a good experience and want to participate further.  If you have passion for this Dare being great, stop sitting on the sidelines and join in making this game challenge community great!

Metris, Tetris and mutating known formulas

After sitting and waiting for the memories of the last Ludum Dare to fade a bit, especially the emotions, it's time to sit down and do some good, old-fashioned analysis on our game, Metris.  Metris is a mutation variant of Tetris, the classic block game.  Instead of the known formula of rotating shapes, we used morphing in place of it.  That was the core of our idea: morph the shapes in Tetris and use someone's existing codebase to kick off the jam a little faster than the last iterations.

We started the evening by brainstorming ideas until the two teams were decided: Our game, with two people working on it in Python, and the gobs of people working on the other game in Unity. It seems like my preferred language, Python, turns off quite a few developers.  Those not scared off by Python were not too enthusiastic about working on a Tetris clone.  Oh well, the game they came up with was good as well.

Once we had our game concept in mind, we found a code base to work from and started working on it.  At first, it seemed like the code we were using was good, but after a while, I found myself working on handling the edge cases that the original developer never bothered to handle.  I spent the entire first evening and most of the morning working on getting the edge cases under control.  Although it was a good lesson, I would have much rather have just spent some more time looking at code bases and not have dealt with the headache in the first place.  Lesson learned, I suppose.

I started feeling rather weathered as we entered the second evening.  Apparently I didn't avoid the cold that my significant other had brought home from work.  Despite that, I was still able to handle the rest of the edge cases in the code and get the game to run the way we wanted it to run.  I retired from working on the game early that night, knowing full well that the next day would be a mad rush yet again to get the game finished and polished.

We started doing the polishing phase once we started working on the final day of the jam.  We created a win condition, set up several levels for the game, and even got some music in as well!  Funnily enough, we started the day assuming that we would not be able to get music in for the game.  There just wasn't enough time to get both the polish in, along with working on the music.  In the final hours, Josh came in and wanted to do some audio for one of the groups.  Fortunately for us, the other group, which had seemingly absorbed any walk-ins, was at capacity when it came to audio people.  We sat him down for a quick playtest and some vague desires on what the game should sound like and we let him loose.  A mere hour later, he had music done and in the game for us.  Sweet!

Ok, now time for good, the bad and the ugly!

The Good:

• I got practice on working with a poorly documented, buggy code base other than my own.
• Metris has music!
• We got time to spend on polishing the game more than a few hours.  Consequently, the game was much more complete and looked better than the playable demo we had at the beginning.

The Bad:

• Not a lot of people joined us for creating this game.  This was not ideal, since there were over a dozen people working on the other one.  I think Unity has saturated the game development community.
• Getting sick.  Not much else to say about that.  Colds suck.

The Ugly:

•  My artwork.  Seriously, who let me do the artwork?  Oh, riiight.....

Ok, that's all for this segment.  At some point in the near future, I'll be taking a more formal look at the numbers and what the community had to say about the game.

On Random versus Luck

As I hosted the Game Developers Forum at the TinkerMill last week, we began discussing the concept of luck.  It started with a video by PBS on the topic.  In it, the host Jamin Warren equated luck and player skill in the game Dark Souls.  I initially found this to be rather incompatible when it comes to player interaction; After all, when I'm rocking a game and showing it how I've mastered the mechanics it laid before me, I don't really consider that to be luck. From a developer perspective, Jamin argued that the skill of the player could be considered a form of luck.  One player can struggle with one section while another will simply breeze through it.  I'm not entirely convinced of this argument, however.

First I must try to tease out the difference between random and luck.  I don't feel that these two concepts are interchangeable.  When someone is "lucky," they are assigning either goodness or badness to what just happened. A gambler will say, "It was a lucky streak," when they win several rounds on the roulette table, despite it being an almost completely random game.  Where the ball lands on the wheel is almost completely beyond the control of the player; It is no more likely to land on one number over another (wheel rigging notwithstanding), yet the player will assign a quality to it.  "It was a hot streak," "I had a bad run," or "It was a lucky drop," are all things you could commonly hear around a roulette table.  In this context, luck is an emotional quality the gambler assigns to the random outcome, not the random outcome itself.  I feel that this nuance was somewhat lost in the PBS presentation.

With that framework in mind,  I want to re-examine the assertion that Jamin Warren postulates; That a player's skill can be considered luck in the mind of the designer.  If we agree to this viewpoint, "lucky" streaks that the player has are nothing more than anomalies when compared to the aggregate of player performance.  This doesn't really seem like an emotional response, especially with game design in mind.  These streaks are more likely the players that have mastered the game, rather than the ones that merely gotten a good run. Although interesting, this should not have an emotional component conflating the outliers.

Another view of the player skill he mentions is "luck execution."  This is the idea that no matter how good a player is, they will fail a certain amount of the time.  The reasoning he states for this is the "human factor," or the fact that we, as human beings, are not perfect.  No matter how well we know a game, we will have a lapse of judgement or something that prevents a perfect game.  Although interesting, I'm not sure that this is quite the same as luck.  This lack of a perfect game is what makes pursuits of high scores and speed runs worthwhile.  It's not exactly luck that gets the high score in games like Mario, where any given board is not likely to have a random element.  Rather, it's the focus of the player and the mastery they have over the mechanics.  A lapse in mastery is not necessarily the end for a great run.  This, too, runs into the outliers, where perfection is the goal, unlike the bulk of the player-base.

Although Game/Show has a good description of luck in games, it plays a little too fast and loose with terms to be a great resource on the topic for my tastes.  I understand the ideas this particular episode was trying to convey, but I think it misses by a bit when it tries to equate luck, random, and player mastery into one blanket term.

Analyzing my Ludum Dare games (Part Two)

Continued from part one:

Up next on my list of Ludum Dare games is Break a Leg.  For this game, we started working on the project by creating the game with two sets of cards.  I thought it was great:  So much so that I am actually working on making it a full-fledged game right now.  But what did everyone else think of the game?  Well, the instructions didn't really help.  Most of the comments were focused on confusion.  Most commenters didn't know what to do and were confused by all of the sandbags dropping seemingly at random (they were dropped by the other actors).  In terms of artwork, the commenters stated that they liked the style, but the UI was less than obvious, especially with the sandbags up at the top of the screen.  It seems like the UI could have been worked out be be more intuitive, like re-sizing the forward sandbag and moving them towards the center of the button where they would land.  Or perhaps having a switch button to change the movement to dropping and vice-versa.  At least voters found Break a Leg to be more innovative and followed the theme well.  For a more in-depth post-mortem of the game, look at my previous post here.

Royal Flesh was a return to audio for me.  In this game, we were able to tag-team the code, which gave me time to work on both putting in some audio and get some artwork in as well.  Most of the comments center around the first build working, so only limited analysis can be gleaned from the rest of the commenters.  What little they said was mostly praise for the game's simplicity.  The ratings for the game show that innovation and theme are becoming fast strengths of the team.  I don't really have much more that I can glean from this, but I did do a longer post-mortem here.

With this last Ludum Dare, I had way too much fun creating Space Mashers.  I felt like I was on point in terms of coding, but I didn't really manage the team too well this time (analyzed here).  Comments centered on praise and a lack of affirmative feedback when the correct buttons are pressed.  I suppose we could have added more effects and background music, but I was just happy getting any sound working in this game.  I have not exactly found out how audio works in pygame, so any sounds were a strict bonus.  It sounds like my UI work left something to be desired and I need to add polish to indicate when the player does something right.  Innovation and theming were on point with this game, however.

That's all of the scoring that I have gotten for Ludum Dare games, but it's certainly not all of my games I've created.  You can see all of the games I've created, including the mini-dare games here and here.  If you have any comments on any of the games, let me know here or on Twitter!

Analyzing my first few attempts at Ludum Dare game challenges (Part One)

I have been looking back at my previous entries into the Ludum Dare lately.  It feels like every time I work on one of these games, I come away feeling great about it.  I rarely look at them a second time, however.  As I have some downtime before the next Ludum Dare, now would be as good a time as any to compare my post-mortems to what the ratings actually said of them.

First up, we have my first ever entry, Lobo.

This being my first ever game created with a team, I felt very good about the outcome.  The strongest portion of our game happened to be the audio.  We found the audio online, using free music (as in the music that can be used for general non-commercial use) and used a few sound clips we made.  I feel that made audio point somewhat of a caveat, since we didn't create all of the assets.  The lowest score we got was in fun.  As the game only had walking brains and no win condition, I'd say that this was a fair critique to have. There wasn't much in terms of gameplay here.  The graphics were a second strong point we had.  I'll do a full post-mortem on this game later.  Onto the next one, The Orion Trial!

Not to be confused with Schell Games The Orion Trail, our Orion Trial ended up being a standout game in terms of rankings, despite having no audio.  We ended up ranking in the top twenty for humor by filling the game with humorous sci-fi references.  It ended up being just a game of random number generation, but no one seemed to care about that weakness, at least judging by the fun rating and the comments.  The weakest portion of the game was the innovation, since it was a clone of the meta-game in Oregon Trail. I personally spent way too much time working on a parallax field, which I felt added polish to the game, but didn't help the fun factor of the game.  I know that I didn't really care about the looks of the original Oregon Trail.  The main part of the game that I liked was the mini-games: Packing up as many bullets, ignoring almost all other supplies, for the hunting mini-game was what I did as a child.  Having no mini-games in the Orion Trial made me feel like the game was somewhat unfinished.  One commenter left one hilarious post, however:

 fisholith says ...
"Cool concept, I love the encounters. :)
On one mission I recruited no fewer than 4 LRRRs. They all died.
On my next mission, my ship had been built on top of an ancient space burial ground. One which also seemed to travel with the ship, because wow, was that ship ever haunted. Actually ... now that I think of it ... there were more ghosts on that ship then crew. Oh my various space gods! *WE* WERE THE GHOSTS!

But also we died later."

Loot Runners was a seeming back-slide in terms of finding that magical mix of game.  I only worked with one other person on this game, but I still am only somewhat happy with the results.  This was our first attempt to create a game involving multiplayer.  The comments on this game were appropriately critical of the execution.  There was not much in terms of gameplay, nor was there much in terms of eye-candy.  What seemed to frustrate the players the most was the lack of feedback.  I think this could have been solved if the player image shook or the monster shook when they attacked you.  What we did do right was sticking on point with the theme.  The entire game was on a single screen.  One bright spot in the game was using a giant killer rabbit for an enemy.  Once again, it was not an especially innovative game.  As a first stab at a local multiplayer game, however, I am pleased with the results.

I will continue the analysis and data visualization of the next three games in the next post.