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