Some days, it seems less like I'm trying to create a computer game and more like I'm trying to create The Great American Novel in computer game form. So much has ended up on the cutting room floor that I could have stitched together 4 or 5 adequately good games out of the trimmings.
Right now, I'm debating the fate of my Vehicle Wars game. At the very earliest of conception phase, the motivation behind the project would be to create a game that sort of relived my experiences in my late teens playing Battletech MU*s, except without the FASA copyright issue and with better-than-text-based graphics. It's mutated into something different - much different - sort of an systems-building economy based game that, incidentally, has a bit of life simulation in it.
In short: this "Vehicle Wars" project is a mess.
Having a design squared away an understanding in my head exactly how to play a game, from start to end, is important. If you've got that down pat, you can put together a great game in weeks, days, or even hours. That I couldn't do that was probably the first sign that I should have backed up, rethought my concept, and started again from scratch. Visualizing that much, however, is hard, especially when I've got an agenda of trying to reinvent the wheel.
In the end, it seems there's only one thing left to do: Practice. Practice until I've grown enough neurons that I really can visualize my designs from start until end. In the process, I may come into touch with understanding what I really want out of My Own Net Dream, so to speak.
That, and I'm probably going to try my hand at breaking down what I've done into libraries.
Dec 9 2009, 9:25 am
|
|
Lummox JR
   |
One option that might relieve some design stress is to take some time-outs with very short-term projects, making very simple games with little or no thought to gameplay to see what shakes out of them. Like for instance, maybe a simple game to explore a forest and dig up treasure chests while fighting the occasional monster. If you have a stock collection of graphics and sound effects you can whip up a quickie game just to make a game for its own sake, and maybe something you discover from that will help your bigger project. As a bonus, a lot of these little types of games make fun party fodder and will be amusing to play, enough to let your brain take a step back from hardcore thinking and maybe shake some ideas loose. Such games are also great for practice.
|
Sounds like good advice. The tricky part for me is keeping it simple. I just love to meddle with my game concepts in mid-production :P
| |
The best way to keep it simple is to introduce some kind of constraint. For instance, try to make a game according to 4K competition rules, or even Cartridge Classic rules (that let you use libraries and only limit you to 8K).
Writing a game in 4K is difficult but it forces a purity of concept. You're very limited as to how many features you can fit in, so tweaking is more about trying to stuff in useful bits without shedding any of the important ones. Another possible constraint is time. Just give yourself X total hours to make a game from start to finish. I've neer been overly thrilled with GIAD because it's way too confined, but having a time constraint can definitely keep you on task. | |
Sounds like pretty good means to train the mind to have a tendency towards KISS design more, which may indeed be exactly what I need.
Either that, or a tattoo emblazoned backwards on my forehead to remind me every time I look in the mirror ;P | |
Based on my experiences... I'm currently of the opinion (as you well know) that I should go small all the time. With that said, I am no fan of crap games. Stick figures and poor user experiences really have no place in my life. I'm largely about new experiences which tend to be in the interfaces, usability, and/or visuals.
Our perception of project size is really determined based on our skill. What's small for me might not be small for someone else. If I always aim for small projects, they should naturally get larger and more complex while always remaining relatively simple and small. :) My projects over the years with % of completion. 95%: Coloropoly (Medium) 20%: Outpost (XX-Large) 50%: Dungeons of Duerganome (XX-Large) 95%: Clone Wars - (Medium) 90%: Cathedral (Medium) 80%: PopLava Project Manager (X-Large) "Outpost" and "Dungeons of Duerganome" have changed core designs at least 10 times each. Large projects obviously have this problem more so than small ones. ts | |
Sounds like you're a little further down the road in terms of giant projects that broke down than I am :P
I wouldn't be too surprised to discover that my current project is basically just the same project rebooted for the 20th time. I seem to center around the same concept of a dynamic content system building game a lot, I've just hit it from several different perspectives: * The perspective of a member of one of four corporations looking to take over the surface of a planet. * The perspective of a single PC who is marooned in an alien environment but has the ability to build via a matter:energy synthesizer built into their suit. * The perspective of a remote hacker who has the ability to take over devices remotely and change what they do. * The perspective of a colonist looking to terraform a planet, a native species looking to prevent the terraforming of the planet, or a privateer looking to profit from the conflict between the colonist and native species. And, currently, back to the second perspective but with the idea it's primarily a vehicular combat game. | |