The Marker Game Backstory
When I think about the reasons I became a game developer, I inevitably start thinking back to my childhood when I would create games for my little brother. I didn't know how to program in those days, so I would make up stories for games and write them down on sheets of paper. We had a large collection of action figures, and I would use them as characters in my games. I'd write out rulebooks for my brother to study and I would sit and enforce the rules of the game as he played along.
One of my fondest memories of those creative days was a game that we simply referred to as "The Marker Game". I would take a few brightly-colored markers and I would draw several pages' worth of maps -- green for the land, blue for the water, and I'd decorate each of them with mountains and trees and cities. My brother would collect a team of heroes and battle his way across the lands, using a turn-based tactical battle system I invented where each player could move in any direction, based on a certain number of "steps" -- basically dashed lines on the page, made with the marker to show where the footsteps had been. It was sort of my version of a Fire Emblem game -- I'd never played Fire Emblem when I was younger, but I do recall reading about it in Nintendo Power and imagining what it must be like. There were some other elements to The Marker Game -- some storyline elements, mixed with exploration of the overworld.
When I picture in my mind the kinds of "dream games" I'd like to make someday, some version of the Marker Game always comes into my mind. So I decided that for week 3 of One Game a Week, with the theme of CHILDHOOD MEMORY, I was going to make a prototype for some variation of the marker game. Playing the marker game was one of my fondest and most beloved memories, so it is a perfect fit for this week.
Constraints
In trying to design a game that would play similarly to the Marker Game, I always struggled with how to translate the functionality and aesthetic to a video game. My dream was to actually make an exact 1:1 mapping, using visuals that resembled marker-on-paper and actually drawing the footsteps the way we'd done back in our childhood. That might be a really fun aesthetic to try and work with, someday -- but for the purposes of One Game a Week, I quickly dismissed this as far out of scope. Trying to make all the characters and effects look like they were drawn by a marker would probably take me at least several days just to get the visuals looking correct, and that's not even taking into account implementing the rest of the game. I decided that instead, I'd implement the game with a more conventional art style -- after all, I could always come back and update the art and just re-use the codebase someday, if I wanted to. I thought instead I'd leverage some of the awesome Synty Studios assets that I acquired during my work on my week 1 game, Curious Castle. These awesome 3D models could basically be the stand-ins for my actions figures that I used as a child.
I also tried to think of some ways I could simplify the game content and mechanics -- The Marker Game has a lot of components, so I had to really focus my scope if I was going to accomplish a finished product for this week. The game had overworld exploration, story components, and a battle system -- I realized I would not be able to work on all of these elements in a week. I decided that the core of the game was the battle system -- most of the time we spent with the marker game was playing out the various battles between my brother's army and the enemy armies. Besides the fact that the battle system was probably the most important part of the game, I also thought it would probably be the most interesting part of the project to work on. So I decided for this week to focus on specifically trying to build the battle system for The Marker Game.
Focusing in even more on the battle system, another constraint I imagined was trying to convert the free-form movement we used on paper and instead put the players on a hexagonal grid. This restriction on the movement seemed like a reasonable middle ground -- not quite as constrained as a square-based grid, but still constrained enough that I could work with it programatically.
So, with those constraints in mind, I was ready to start designing the game.
Building the Level Editor
One of the biggest lessons I've learned in game development is understanding the worth of good tools to help you develop. In this game, I planned to create several "terrains" on which the players could do battle. Assembling these by hand in Unity would be a huge pain point -- I went through similar struggles while creating all of the levels for Omnicube. I put off dedicating some time to truly building a level editor for Omnicube until I'd created 85% of the content. Once I finally bit the bullet and made the level editor, I had a huge amount of regret about not investing time up front to just do it right in the first place. I decided that my first priority was to construct the level editor for The Marker Game.
I found a great set of minimal hexagonal tiles on the Unity Asset Store a few months ago when I had first started thinking about dong the One Game a Week project. The name of the pack was "Low Poly Hex Tiles". This was a perfect match for this project, given my deliberate priority to try and avoid spending too much time on creating art assets -- these tiles had a great look and pretty solid variety, and so I decided to work with these.
They look really great -- unfortunately, it looks like the asset's creator has discontinued the product, which means you can no longer download these from the asset store. However, if you're looking for some cool art assets for a hexagonal grid, it looks like Synty Studios has an offering that would do the trick. You can find it here.
For my level editor, I basically created a 2D array of GameObjects, and then used a raycast to detect which array element I was clicking on. I created a side panel which contained a palette of different hexagon types which I could use as a "brush", and then when I click on a cell in the grid, it would instantiate the corresponding terrain element.
So with this functionality implemented, I could create the areas that the players would fight on. Up next, of course, is actually implementing the player movement. I've spent some time working on that, but right now I'm still in the middle of putting together that code, so I will update my progress on that in my next article.
So that's where I'm at so far in this shortened week! I feel like I'm making pretty good progress, but the Sunday deadline is looming large.
Thanks for following along -- this game is near and dear to my heart, and I'm excited to share it with you all!
--Kyle