Here's a screenshot from a project which I've been working on in my
spare time for a few months now. I'm releasing the source code to this,
so that hopefully it may be of some use to others. This represents quite
a bit of coding time on my part, but I'm at a turning point in this
project; I would appreciate any advice you guys may have - basically, do
I polish this project, and try to package it into a playable game, or do
I start from scratch on another project (I'm thinking of a driving-type
large terrain game for my next project).
It's a D3D8.1a, Win32-only app. I'm afraid -- there's a fair bit of
stuff in this app, so in no particular order;
Simple bot AI, (zombie-tracking) with abstracted 'flight controls';
this is just a struct. in CUserInput.h - I like it, because I can use it
to represent true user-input aswell as playback-type stuff and
Particle system - used in a true dynamic way and also in an
optimized-type way for the projectile 'lasers'.
Patch-based fixed-LOD terrain algo; this is definitely suboptimal --
inefficient use of vertex buffers causes excessive state switching and
poor performance, but it's interesting to note that even a suboptimal
design can be sufficient in certain cases. Quadtree frustrum culling is
applied here, nothing too fancy. It's possibly slightly unusual in that
I supply colour data in addition to dynamic D3D lighting.
Oh yeah, variable # of D3D lights are supported, and are dynamically
turned on/off in response to gameitem proximity. Leads to some pretty
shading under certain circumstances, but also to a strange blinking
A 'screen-overlay' system; an attempt at a better way of drawing
stuff like HUDs -- all these vertices come from the same vertex buffer.
Useful class: CCmdLineParser -- I'll definitely be reusing this one!
Groovy (read: quite fast) terrain-ship collision detection, see
Billboards, scene output to BMP, mouse smoothing, basic
flight-physics modelling (actually a complete hack, to call it a model
would be silly) with a strange 'never-done-before' flight-sim meets
Quake-type strafe function :@
Menu handling code, and re-entrant game code, to support level
movement and game over type scenarios (not to be underestimated, proved
Basically, a lot of the main elements of a game are there, but they all
need a hell of a lot of work before it could be packaged up and sensibly
called a GAME. I guess my question to you guys is, should I do so, or
should I restart afresh taking with me what I've learned?!
BTW: the bots are set to 'insanely tough' mode in the EXE -- this was
one of the last things I added! =)