Game Design Thoughts

Those following the site probably noticed that the other day I posted a… thingy. (I don’t want to quite call it a game). Anyways, if you follow this link you’ll seen one area (in unity) for a very simple kid’s spelling game. And by very simple, I mean VERY SIMPLE. (If you want to read the ‘instructions’, do so here).

I’m sure some of you might be thinking.
“Holy !*@*, is this all Brent has got done since leaving BioWare?”

Yes. Yes it is.

Well, more specifically, this is what I managed to cobble together from some of the prototyping stuff I’ve been doing. It is very primitive and my kids think it is boring. There’s been no attempt at lighting anything properly and some of the props (the platforms I’m using as walls) are stolen from the 2D Tutorial I used to learn Unity. And the firing system sucks.

But is it something I managed to finish (more or less) and deploy, which was one of the risk factors I wanted to investigate. I now have a better idea what I can get away with, in terms of using existing code libraries and the like.

I’ve also tackled:

• Movement – albeit smash-into-the-walls-and-get-stuck-to-them-movement
• Procedurally generating objects (the bullets)
• Basic Lighting
• Visual Effects — not that I’m doing anything pretty with them, but heck at least there are some
• Camera control
• Basic Unity Interface work
• Server side screenshots — useful for automatic bug reporting

Some people have asked why I’m bothering with these kid things, seeing them as taking time away from a real game, but the truth is that building little games like this does the following:

1. I learn. This is important. I’m figuring things out I’ll need to know for a real game. Some of this is rather painful (right now I’m working on a different kid’s game that involves animation… something I’ve never done before. It is unpleasant and if it were not for the fact that my deliverables are so simple, with the kid’s game, I might be deterred from proceeding with it.). So basically these little games are confidence builders and prototypes.

2. I’m trying to get my kids interested in programming and game development (see this old post for some resources I asked for back in the day). Is this working? Not really. They are more interested in telling me what to do rather than actually writing code or building art assets. Hopefully that will change one day.

The Game Design

There’s no actual design to this letter game. Development has been very freeform, with the kid’s throwing suggestions onto the framework I developed. There’s a quasi high level goal in that the player needs to spell words. That’s about it.

The problem with such a vague goal of course is that I puttered on this for some kind, adding features and removing others and not having a real clear idea of what the point would be. Originally it was just to spell words. That was the focus. Then I thought it would be neat’o if the different words spelled could grant different in-game powers. So I added that system — not that there is much differentiation right now.

By doing this though the next step I should be making is to change the core focus. It is a little weird to have collecting letters resulting in powers AND that collecting the letters is required to complete levels. Realistically collecting the letters to get powers should be a step towards fulfilling some other higher level objective… being able to defeat a boss monster or complete some other challenge. That might be a change I introduce down the road, or I might just leave things as they are.

I would also like to play around with procedural creation of the geometry to partly automate the environment building.

SIDENOTE: If the killer pancakes shoot you a lot you still don’t die. This is because my youngest thought dying was stupid. So I tied “death” into a degrading score instead. The more often you “die”, the more points you lose. After each death you’ll be restored back to full health (but with the score penalty).

Workload

I can’t really answer how long this has taken because it was built upon older work for some other purpose that I abandoned. Basically I get 1-2 hrs a week to do game dev. My highest priority right now is still writing (after I’ve taken care of the kids and the housework and all that). Some weeks I get a bit more time to program, but not often. There’s also spells of several weeks or more when I do no game dev work.
That said, next year, things may change for me. Right now most of my ‘writing revenue’ comes from selling the Lazy Designer books (though that’s rather mediocre at this point, hence my playing around with direct selling and adding value). If nothing big happens in fiction-land soon, I might shift focus to game-dev activities (and completing the Lazy Designer books is my primary writing task right now). On the other hand I’ve drafted a plan for my next novel and I’m really excited about it. So, we’ll see…

And unrelated to all the above, while ego-surfing I came across this post about my Lazy Designer books:
“This isn’t DA:I related, but I’ll agree that Brent had (has) an amazing perspective on [how] game development should work and focusing on how the end product appears to the player. His “Lazy Designer” books he is putting out should be taught as religion in the temples of Game Design.”
http://social.bioware.com/en/forum/1/topic/371/index/17533638/1#17533787