Tuesday, November 11, 2014
Featured Post: Middlegame
By Erik Meyer
Time tested blueprints and templates for indie game developer success are in short supply, likely due to the wide range of variables involved in any particular effort (changing goals, number of people, assets required, company/organizational needs, timeframe, etc). I'm choosing to keep the focus of this writing on production, i.e. the middle steps (I'm avoiding the exciting first moments and the thrilling culmination); as the scope of project work balloons and technical challenges present themselves, development becomes a stamina sport requiring careful attention to detail.
In chess, middlegame refers to the point in a match where the opening (the first moves that establish position and engagement early on) has transitioned to a struggle for control of the board; many pieces are in play, yet the end is far from decided.
I've been working on Sum, a math game targeting K-5 common core standards, for three months, and I'm learning as I go. I was fortunate, because I had a clear goal from the beginning: I'm striving to create a game aligned with early education needs that creates reports for teachers and is, more importantly, fun to play. I also possess a clear view of my skills: I have dabbled in coding, but my main strengths are in writing, art creation, and level building.
Like chess, we get better by doing; I am teaching myself C#. Unfortunately, most games stall because of differences of creative opinion, lack of accountability, unclear goals, or the headaches that come with coordinating a team with no budget. So far, I've had help from a few kind members of the local Unity community, but game decisions have all been mine to make, and simpler has been better.
Here's what the player currently experiences:
A math wizard floats around a tree-covered map at the edge of a city, and after clicking on the glowing orbs that spawn around a tree, first grade math questions pop up. When questions are answered correctly, the score increases.
The goals are becoming clearer as the project progresses; I still need to: Input the rest of the math questions by grade, add art assets, create a power-up and experience system, create a dialog and quest system, create a database to log results, and design a visual help interface for students who need assistance with the questions. Presentation of content will be essential to the success of this game, and these may seem like formidable goals, but consider: Three months ago, I knew no C# and had never used Unity3D. I had no levels made, no 3D assets, no idea of how to work with sprite animation.
Now, I have a demo. It's not a complete game, but it's a demo.
From this point, it's about managing the steps and refining the scope. I don't need 15 levels to have a finished game. I don't need 200 power-ups. Five levels and 10 power-ups is fine. Maybe other people will work with me from this point (which adds complexity and non-disclosure agreements, for example); maybe it'll be a largely solo project with community help. The biggest thing is to stay in the moment, to keep it moving forward, and to keep it from crumbling under its own weight.
Like chess, everything has a cost. If I ask someone to help me, I have to make sure we have the same expectations. If I change the scope of the project, I need to balance content with time to create said content. If I create a company, or seek grants, or start a GitHub to back up and version the game, I have to recognize that each of those things requires focused attention.
In chess, I've always found the middlegame to be the most exciting part, because so much can happen. A few clever moves can lead to victory; a careless blunder can remove firepower from the board and lead to a long decline. The clock is ticking.
Erik is a multi-talented game maker from right here in Fargo. Check back for future updates on his upcoming game, Sum.
at 8:56 AM