| Submitted by , posted on 08 May 2002 |

Image Description, by 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 computer-generated input.
> - 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 effect!
> - 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 CTerrain::LERPdY().
> - 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 quite tricky).

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?!
http://xlr8a.net/x7/flipcode_alpha0.zip
http://xlr8a.net/x7/source.zip
Cheers,
Dom
BTW: the bots are set to 'insanely tough' mode in the EXE -- this was one of the last things I added! =)

[prev] | Image of the Day Gallery www.flipcode.com | [next]

Copyright 1999-2008 (C) FLIPCODE.COM and/or the original content author(s). All rights reserved.
Please read our Terms, Conditions, and Privacy information.