next »

[Evan Balster]

Hey, all.

This isn't a request for technical advice, per se.  More for advice on a problem I imagine many designer/programmers face.

I've got a pet project I'm rather passionate about, and in which I intend to put my abilities as a designer and programmer of games to full use.  In keeping with an idea I've had for a long time I want to put a great deal of detail and subtlety into the character(s) of the game rather than the environment.  I'll be implementing adaptive animation systems, a custom rendering scheme, and a few other systems for the purpose of facilitating a strong sense of physicality in gameplay, body language, and a specific visual aesthetic.

The implication of all this is that I'm going to spend a great deal of time on this technology before I can see my characters come to life.  I've been putting occasional hours in on the rendering system since March (it's still very incomplete) and I'm beginning to plot out the kinematics algorithms.

I've heard warnings from some experienced folk about avoiding technical problems like this where they're born from a programmer's pride rather than a true necessity.  But in my case I like to think it's a tenet of design from which the "need" springs.  The nature of my characters is meant to be a very core part of the gameplay experience.  But I'm still second-guessing myself in small ways.  Wondering if there's a mistake here.

My feeling at present is that I need to push forward; I don't doubt my technical ability.  It's just the work isn't strongly compelling at this juncture and that worries me -- I don't want my passion toward this project to erode.  But as it stands I may have a long way to go before I have something resembling a game.


One option stands apart:  I could begin work on the narrative and logical aspects of the game through an interactive fiction or abstract-graphics prototype while developing the systems I mention above in parallel.

[Fallsburg]

I would say to follow the last option.  One of the things that helps keep me going is to spice up the boring tasks with fun/creative ones. 

[Cheezmeister]

What Fallsburg said. Also, I commend him on his feline analingus ouroboros.

[eigenbom]

You could try to build a series of small games, each containing some new technical feature which ultimately leads to your larger game. Although this is obviously more work.

Another option is to design and build all the subsystems in parallel, so you always have something working and playable. That's kind of what I'm doing with Moonman, trying not to spend months on any one particular feature, but rather build all of it iteratively.

[bateleur]

Assuming the animations are purely cosmetic I'd recommend getting the game working without the techy bits first to check the gameplay is good. I don't see anything wrong with spending a long time on advanced technical systems, but it's easier to have confidence that it's a good use of your time once you know the core game is working.

[VortexCortex]

I agree with both eigenbom and bateleur.

I use these same techniques when doing any project; From back-end website code to game engines.

Our team is working on a series of smaller games as major milestones leading up to the larger actual game.  The bigger game would just take too long with too much waiting with little reward in the interim; So, we came up with a few more simpler games and elaborated part of the story we otherwise wouldn't be able to tell.  Hell, we even cut out a few of the dimensions of gameplay from the lesser games.  If you don't want to butcher the pet project into some smaller subset, then create a different game that utilizes said subset of features.

Furthermore, you probably really do need to test gameplay mechanics if you care about fun.  In order to find out what works from a gameplay perspective we build a prototype of JUST the gameplay, no art at all.  Once we used basic particle effects and bounding boxes (not even any models), this was enough to quickly start testing core gameplay mechanics. 

Eg: We picked one enemy type, and one weapon to implement. Then, hacked together a crappy editor that's a VERY long way from what the finished product will be, but can just barely create content for the basic concepts.

Even though it's just some colored boxes and some particles we were able to decide that flying was much more conducive to the frenetic fun we wanted than platforming + limited "jetpack" boost.  We didn't need the "Jump" mechanic, and that double jump to boost sucked, etc.  The initial designs all sounded pretty good in the design doc and in our heads, but  playtests don't lie -- It doesn't matter how cool you think something will be if it's not fun to play... unless you're doing an art game and being fun isn't important?

Test early, Test often.  Make a bare bones prototype and save yourself oodles of time re-engineering stuff later.  The pride and joy you'll get from actually playing with working concepts will be well worth it in terms of motivation.  Who knows, you might discover something neat you hadn't thought of along the way.

Even little working tech demos can help you power through the next batch of mundane code.

For example: Some rotating text got us through the boring cross platform windowing abstraction layer.  Playing with the tweakable animated sky got us through the input binding system.  Play testing a few gameplay prototypes staved off boredom through implementing the UI event delivery system & networking code.  Adding little features to a cheesy Tetris clone will keep us from being bored while we build out the 3D GUI widget library... etc.

TL;DR: Don't underestimate the motivation power in small bits of working code.  Treat tech demos like the rewards they are, and get something playable as soon as possible.

[Evan Balster]

I'm no stranger to rapid prototyping, though I could stand to do more of it.

Here's the thing.  Far from just aesthetics, these silly algorithms are going to be part of the core gameplay.  It isn't just animation; it's the physical presence of the character.  And it's a major design goal.  Thus prototyping isn't a solve here.  Certainly, I could prototype with simple paper-doll endering and 2D inverse kinematics.  But the gameplay would feel different -- maybe profoundly so -- from what I'm going for.

The "adventure game" elements of this project, on the other hand, work at a more abstract level and would be a bit more feasible to prototype.  That's making more and more sense.  (I wonder if it's crazy to program something as both an interactive novel and a graphical game?)

(And for what it's worth, there's relatively little to be done in the way of engine or porting work for this project.  I'm working atop the crossplatform system I've built over the last three years, which is very well-suited to this project in terms of graphics and sound capabilities, et cetera.)

[VortexCortex]

If you've already got most of the tech done, then what's your aversion to "pushing through"?  You're reading too much into my examples -- It doesn't matter if you have a full game engine or are starting from scratch in assembly:
There is always room for a prototype.

For example:
Your main character is now Vectorman.  There are only point sprites that make him up -- Your IK is replaced with just interpolation -- It doesn't look like the final version will at all but the core concept of moving the hands and feet will work.

If you find the core game mechanics are fun, then proceed.

Next, you give Vectorman an articulated stick figure with fixed length appendages and springs for joints, but the number of joints has been drastically reduced from the target version -- Maybe do vertex weighting and bone animation here.

The next version you finish out your IK solver with the full skeleton & meshes, and rigid joints with flex limits.

------

Divide and conquer (top-down or bottom-up design) is the most fundamental solution to issues of overwhelming complexity.  Only you can decide the best boundaries along which to split up your workload -- There's no one size fits all silver bullet solution.

If you're just determined to work on something for ages until completion before being able to see any results, then why ask for suggestions?
Stop procrastinating and get to work <- Best suggestion in this case.

If you want to know how to "push through" any massive task while mitigating boredom the answer is going to be: Break it into little chunks, or start with something small and add layers.

If what you have is just a lack of motivation -- Try removing distractions.  Decide to work on the project exclusively for a specified length of time then reward yourself by taking a break to do something else you enjoy, repeat as needed...

...Oh, Look, It's another application of divide and conquer. 

[Paul Eres]

you didn't mention what your goals are with this project, and what your resources are

in other words

- how long do want to spend working on this game?
- can you afford to work on it full time, or will it be a part time hobby thing?
- who else is working on this game with you?

the questions you are asking feel like fundamentally questions involving how you should spend your time/resources. and it feels like necessary information (like the above questions) is lacking

but in general, here's my advice:

if this is your "dream game" and you want to be a perfectionist about it and have no time frame and have a day job or whatever, and you don't require it to get done very quickly so that it can sell copies to feed you, then take as long as you want on it; work on the tech bit by bit and make it as good as possible

if you think you may give up on the game if it takes too long, or if you can't afford to work on it forever and need to finish it eventually to survive, you'd want to set deadlines and put limits on its ambition. this would vary depending on the amount of time / resources / team members. it's not always possible to figure out how long something will take to implement (especially when you never coded anything like it before) but you can usually guess in a ballpark range and then double your guess (an old rule)

[Evan Balster]

I'm willing to spend a long time on it, though I don't want to extend development unnecessarily; I started working on the project to keep it from being a "someday" thing -- someday is always at arm's length.
I'm doing contract work, other collaborations and have another personal project in need of attention, so my commitment is part-time.  When I get that number down, I might be able to put more time in?
Regarding teammates, I'm working alone for now and eventually plan to add collaborators to the project.  But only once I've made significant progress myself.

For the foreseeable future I can't work on the project exclusively, but weekends are abundant and I work on it a little during the week too.  I envisioned last night what the project might look like with more rudimentary paper dolls and two-bone IK.  (Think Aquaria)  For the time being it might be enough to get a feel for what I'm doing, so good point there.


Oh hey look, it's the weekend.