Now that I’m back to blogging here, I decided that it’s time for a little face lift. I removed several pointless pages to reduce clutter, deleted numerous old comments, and changed the theme. Pretty soon I plan on changing my domain name to a .com one, as well, though that’s not decided yet. I think that before doing that, I need to first get into the habit of posting here regularly.

Rolling stones around in my new game!

Lately I’ve been programming a ton for my latest game. However, instead of just “making a game” like I’ve done so many times in the past (or failed at doing), I made a massive checklist and to-do list for this game based on feedback I got from those who played Hindsight. One of the biggest issues with that game was trial and error. While some trial and error can be good (in exploration games, for instance), in a game where you either do-or-die, it’s not the best idea. For many people, the game became to frustrating after some time and they would quit. Sure, many actually carried through and finished, but I’d rather not make the player frustrating over the poorly done platform engine and gameplay. It’s one thing to have a challenging puzzle if you have puzzle mechanics that work logically and are consistent, it’s another thing to have those “puzzle mechanics” change in every level. Likewise, it might be worth it in a platform game to have a challenging area to get by, but not when the challenge is overcoming the flaws in the engine itself.

So, as I was saying, I believe I have improved on many flaws that Hindsight had for my next game. It has many different puzzle elements/mechanics in it, and each one is introduced level by level by a tutorial guy. This, I’ve found, is one of the biggest flaws in independent games—the developers either just have a wall of text for the controls at the start of the game, on the menu, or not even directly as a part of the game. Many just assume that because it’s easy for them to understand, it will be easy for the player to follow, as well. However, as the developer, you need to remember that your game will always seem much easier and more logical than it will in any player’s mind. If it’s a puzzle game, you know which buttons to press and boxes to push and can do so without much thought, but the player actually has to think those things through and may have to restart a few times before he/she does it properly.

Telling the player what he/she has to do

One of the best ways to teach someone how to play a complicated puzzle game, or a game with unorthodox controls, is to have someone in-game tell them and then show them how to do what they need to do. This will prevent a lot of frustration on the player’s part, while giving the game a much more polished feel to it. Despite it adding a little bit more to your checklist before you can release your game, if the player has no knowledge as to how to play your game, then all of the rest of your effort in making the game will have been wasted.

Yes. That was a very roundabout post. I tend to write, and then just keep writing. Sorry if I lost any of you there (ironic, seeing as I was talking about losing a player because they don’t understand how to play a game).

-Nathan Wood


About turboRamble

I am a seventeen-year-old who enjoys programming games and applications, as well as reading and writing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s