Amateurs look for inspiration; the rest of us just get up and go to work.
For whatever reason, I decided that it would be a good idea to write up a quick game design doc for my current project. Usually they are helpful for a team of developers so that everyone is on the same page, but for me I just did it so that I would have something to look back at to keep me on track.
I only wrote it a day or two ago, but so far I think it was a good idea. After I’m done writing this blog post I’ll be going back to reference it which is exactly why I wrote it. That’s a plus in my book.
Another thing that I didn’t expect from writing it was that it made me really think about what I wanted the game to be like. I had to stop a few times while I wrote it just to decide which direction I wanted to go in. Once again, a plus in my book. Solidifying your ideas before you start can be a big help.
Haha, I titled this section “The Process” as if there is some specific set of steps I took to get it done. In reality, I just did a quick search for “game design document template” and picked one of the top results. From there I just plugged in what I thought was relevant to my game.
Check out what I wrote and see if it is something that you can do to help out your future projects: Four Sided Survival GDD
I’m still working on my first Mechanical Game Design article here and there but it’s not ready yet. Today I wanted to write a brief update on what I’ve been tinkering with and some random thoughts about what I want to do.
For a few reasons (time, frustration, enlightenment) I have decided to ditch the programming language aspect of XMechanics. I still want to experiment with different mechanics but I’d like to just toss some code into the Haxe compiler instead of spending the time to learn C++ at the present.
I’m also going to merge the Mechanical Game Design series with XMechanics so I can do some analysis of the mechanic in question as well as implement that mechanic to see how delicious I can make it feel.
This means that the first article of the series will be a little longer to write up and they’ll be more spread out. Oh well; such is the price of life.
Lately I’ve been trying to become an idea machine. I try to come up with small Flash game ideas every day just to practice ideation (it’s a word, I swear!) and to keep my brain exercised. This is thanks to good ole James Altucher. He’s a good dude.
Among the dozens of ideas I’ve wrote down lately, I came up with one I want to try out. The ultimate goal is to make something super simple but fun to play and to see if I can’t get a license/sponsor deal to make some cash. We’ll see how that goes.
I’ve only just started writing code to get the game on screen and I’ve just decided to write my first game design document (look out for that later). Time to surf the interwebs for some tutorials and examples and to come up with something that will (ideally) help keep me on track during the whole process.
Well, that’s the update. Not super juicy or exciting, but either way, you stay classy interwebs. Catchya later.
P.S. What are your experiences using a game design document? Do they help out much?
Amateurs look for inspiration; the rest of us just get up and go to work.
Here’s another quick (and unremarkable) update on the XMechanics experiment. Haha, EX-Mechanics and EXperiment… Never mind.
You probably already knew that, but it’s making things move along pretty slowly. I always have at least a couple tabs open in Chrome with C++ and SFML references. The going is slow but there is still progress dammit! Don’t sweat it, the whole point of this shindig is to LEARN.
What have I done so far? Well, for the first few days I was lazy and mostly just read a bunch of the SFML API trying to absorb what I could. (You can check out the Github logs to see exactly what I’ve got done by the way)
Last night was pretty productive. I implemented some basic movement code so that the player sprite accelerates and decelerates. It feels much better when you see the character slightly slow to a stop when you stop moving and when you don’t just start off full speed.
I wrote about the method I used not too long ago, check it out if you aren’t sure what I’m talking about: click me! I haven’t read that since I wrote it so I hope it’s not too out of date or you know… incorrect.
On a side note, I just realized I’ve put all my code straight into the Entity class instead of creating a separate Player class for controlling the player… sigh.
Here’s my short todo list for all the minor things I want implemented before I start experimenting with the echolocation mechanic:
After all that is in, I should have a single screen full of platforms that will at least kinda feel like a game. From there I can start toying with echolocation by shooting stuff from the player and then figuring out how to interact with the platforms when the stuff collides with them.
Who knows, maybe this thing will actually turn out to be fun. Then I’ll have to make a whole game and sell it for millions of dollars. Or ten dollars, ten is good too.
That’s it for now. You stay classy interwebs. Catchya later.
You probably remember the first game you ever played. For some reason that isn’t the case for me. I’ve thought about it a lot because of all the stories from successful game developers out there. They always talk about the first time they played a game: they were hooked.
My story is a little different. I remember having the original Nintendo but I don’t remember the first games that I played for it. Maybe they just weren’t very memorable or maybe I didn’t get very good games when I was that young. Either way, that gaming system didn’t have a huge impact on the way I looked at games.
Two of my favorite games of all time are Zelda: A Link to the Past for the Super Nintendo and Final Fantasy Tactics for the original Playstation. Those games are the most memorable for me and their mechanics shaped the way that I look at video games.
There is probably a very good and concrete definition out there of what a game mechanic is, but I haven’t found it and most of the world interprets it their own way anyhow. I’m not a huge fan of putting absolute definitions on most things, but for the sake of this article, it’s worth a shot. Here’s my best interpretation:
A game mechanic is a set of rules that results in a method of interacting with the game world.
The most important part of my “definition” is that the result is basically just how you interact with and experience the game. Your experience is influenced by other factors, such as sound and visual art, but the mechanics are the core of the game (at least for me).
The reason that Zelda and FFT were so influential to my love of video games, is because they are so rich in game mechanics. Games like Mario are great, and I still like to play them, but the experience that I got from my favorite games was unmatched. It wasn’t just picking up a controller to hop around for a bit; it was learning a system of rules in a different world so that I could become the BEST Link and the BEST Ramza.
It would take hours to go through and explain each mechanic in Zelda or FFT. That doesn’t mean having lots of complex mechanics in your game will make it amazing, but there is something to be said for having so many mechanics working together in a game to create such a deep experience. There are also some outstanding games out there that take one solid mechanic and make it into an incredible experience. For example:
As a game designer and developer, I think a lot about mechanics. If I were an artist, I would certainly have a different perspective on games, but as a programmer, the almighty mechanic is where my love of making games stems from. A game with a solid, unique, and clever core mechanic (or mechanics) will get my attention immediately.
Final Fantasy Tactics and The Legend of Zelda: A Link to the Past probably took a large team of developers and a huge amount of time to make. They are both beautiful, filled with story, and heavy on game mechanics meaning that it took lots of time and talent to put it all together. It is rare that you see an indie game accomplish what those games did.
My goal as a game developer is to someday create a game that I can compare to the greats either because of the depth of the experience, or because I executed my core mechanic so well that it was a great experience. For me, that starts with digging deep and understanding how to create interesting mechanics. The only way to really understand them is to study them and create them as much as possible.
I try to spend much of my time improving my programming and gamedev skills, and that covers the creation aspect. What I haven’t done much of so far is the studying. My whole life I have been playing games for the fun; for the experience. It’s about time I start playing them analytically with a different goal in mind.
I want to understand game mechanics better so that I can create games that use them in new and clever ways.
This article is my attempt to lay down some of my thoughts on the importance of designing games mechanically and to prepare myself for diving into lots of games to analyze their mechanics.
I will be choosing a single mechanic, or a small, related group of mechanics to analyze. Then I’ll choose a game that I feel executes those mechanics well and I will write about my findings here.
My best bet is to start with some simple mechanics that can be seen in tons of games. I want to start with platforming elements and the best example of having tight, satisfying platforming is probably Super Meat Boy. Time to get to work playing games.
Photo courtesy of jscreationzs at freedigitalphotos.net