mangobrain

• Quite a bit of fun. A little difficult to steer and lack of sounds hurt a little. Otherwise, very nice.
  • Yeah, the lack of sound is really irritating. I actually found some half decent sounds - explosions, electric hums, and so on - but never had time to put them in. I also found some perfect funky music I wanted to use. In reality I'd have been better off if I had given up on even trying to find any sounds and spent more time coding; the bullets might have sucked less.
• Cool for a 1 week challenge, nice work.
  • Thanks. :)
• How did you make this in one week?!?
  • Erm... quite badly, in my opinion; but everyone's been so nice about it, hehe :) It'll probably surprise you to know (unless you bothered reading my gigantic post-mortem posts) that on the morning of deadline day there wasn't actually a particle in sight.
• Cool concept. Would love to see it evolved further!
  • So would I - I've got big plans for this one. Time will tell. ;)
• sorry, didn't work.. i'm having trouble with a few of these games tho..
  • That's a shame :/ but.. erm.. telling me the error message(s) would be nice!
• Wow, that was pretty cool.
  • Anyone noticed the running theme yet? ;) </modesty>
• Looks pretty cool. Could be a fun game with sound and some slightly prettier graphics :) The charging stuff didn't work for me though (unless I was missing something)
  • Yeah, I didn't have time to texture the particles, let alone touch on what I wanted to do in terms of explosions and dynamic lighting. In the first "final" version, the mouse buttons didn't function after pause/unpause; this might be what caused the charging to fail (this got fixed at the same time as the nVidia bug). Just to clarify, when you hold down the right button, the blue bar (power) should decrease and the red/purple bar (shield) should increase. Dropping either to zero kills you - some of the particle types can regenerate your power, but the drain/charge mechanism is the only way to regenerate shield.
• fast and scary
  • Fast? Yes. Scary? Chicken ;)
• Worth the hassle to install PyODE!
  • Wow - thanks. I never expected to hear this; the way I'm actually making use of PyODE is apalling.
• Looks very good and is fun to play, although the controls and bullets sometimes feel a bit unresponsive.
  • Yeah, the bullets are really, really crap. Sorry about that one. As for the controls - I sort of achieved what I was after, but had no time whatsoever for balancing. (Anyone actually tried playing with sensitivity set to 1.0? That'll show you how untweaked the controls are...)
• Nice tunnel effect, and very nice orbity balls. They look cool!
  • Yeah, I like them. They were much more of a pain in the arse to get working than I thought they would be, too. :P
• Good game. It has potential. Maybe the control could be improved and the world customized. Some racing stuff would be nice.
  • YES. Yes it would. Don't quite know how I'd do it though - trust me when I say the whole moving-along-a-tunnel thing is one big hack, it'd take some major reworking to actually be able to travel a curving path.
• Nice work. I don't think I've survived past a minute!
  • Hehe :)
• Fun game, a bit confusing sometimes but not much.
  • Confusing? Yeah... more visual and audio cues would be nice. Consider it a "known bug."
• Nice game. Simple yet fun. Sometimes those electric fields get real thick, but its cool.
  • Not quite what I wanted, but mostly intentional. I originally wanted either single bolts, or "walls" of lightning with small holes you had to aim for. I didn't have the time though; nor was I really sure how it would have worked even if I did have time. In the end, things get created at distance-based intervals (with some randomness thrown in on the Z axis to disguise the fact), either singly or in "bursts," hence the occasional lightning storm or clump of phlogiston.

So... the future. I want to do a lot of things here. First off, add sound support, and some sort of fading/transitioning when you start the game or lose a life. Also some sort of lighting manager would be nice, allowing for dynamic lighting from bullets and explosions, but to be honest I don't have any experience with lights in OpenGL beyond enabling ambience, and maybe one or two static, unidirectional lights. I don't yet know how to cope gracefully with the fact that the number of lights you can have at once is limited to something ridiculously low like 7 (AFAIK - PLEASE correct me if I'm wrong!).

Support for different resolutions exists, and adding fullscreen support is trivial, but I didn't have time to integrate either with the menu system. Ideally, I want a system capable of querying available resolution/colour depth combinations, and allowing you to alter the two seperately without letting you choose invalid modes. For now, if you want a larger window, open up the game in a text editor and play with the dxres and dyres (NOT ixres and iyres) constants.

I also want to either make the tunnel much larger, or remove it completely in favour of a StarFox-style scrolling landscape. The controls need some work too - either just better balancing of the current system, or perhaps have the mouse influence turn rate instead of directly influencing direction, a la BZFlag.

Bullets need fixing; the particles need a bit more graphical polish; a third-person camera would be nice (although again, it's something I don't quite know how I'd go about implementing). If I go down the route of turning it into a more conventional shooter (I've always wanted a StarFox style game for the PC), then speed control will have to be brought in instead of uncontrollable acceleration - this depends: do people like the manic-uncontrollable-descent feel, or is it just too wild to give the game lasting appeal?

Also note that NONE of the above will happen for quite some time. I'm still settling into my new job, and only have weekends available as free time - during which I usually have other priorities.

The final submission has been replaced with one containing a Windows-friendly readme file, and already patched with the fixes mentioned in my previous diary entry. Thanks Richard :)

PLEASE READ

If ACCELERATOR moans about a missing OpenGL extension, try this:

• Comment out lines 16, 1304 and 1305 (anything related to GL_SGIS_texture_edge_clamp)
• Change GL_CLAMP_TO_EDGE_SGIS to GL_CLAMP_TO_EDGE in lines 75 and 76 (setting of texture parameters). If this still fails, change it directly to the constant 0x812F.

I previously never caught this because ATI cards do support the extension (NVIDIA don't), and I'd only ever run the game on the development machine, with an ATI card. Anyone care to shed light on why PyOpenGL doesn't define GL_CLAMP_TO_EDGE directly for me?

(Warning: The overly verbose, self-indulgent post-mortem continues...)

I've just been playing my game, something I never really did during the competition itself (mainly due to there not being anything significantly interactive until the early hours of Saturday), and surprisingly, I actually think it's kinda fun. Although I'm now 99.9% certain that my hackish way of using ODE has indeed disabled swept collision tests; I should have realised that it would from the start, since I'm only implicitly providing past position information, and not providing any timing or velocity information. That's all dealt with by my own code, which then just tells ODE where the object is this frame. This is potentially fixable, would lead to cleaner code (no mixing of conventions), and is generally desirable and could lead to previously infeasible, physics-based extensions to the gameplay.

Currently, lack of swept collision tests has a severe detrimental effect on your ability to shoot things, something I never noticed during implementation because I simply never played for long enough to get the tunnel runner up to a decent speed. This is a rather fundamental flaw for something that is meant to be, at least in part, a shooter. Blame it on the fact that bullets were the absolute thing added to the game before submission (bar the README), which also explains the incredibly pitiful shot graphic.

One thing I don't really know how I'd fix is the lack of transitions. By this I mean the way in which the main menu launches you straight into the game, which launches you directly into your three lives (without telling you how or why you died), then drops you straight back at the menu again. Nifty looking fades, timed GAME OVER screens, so on and so forth... these things just don't fit nicely with my handy-dandy pluggable main loop system*: as far as I can see you'd end up with either main loops full of state checking and superfluous timers, or a hideous and/or over-designed system for passing state between smaller main loops. My pause menu doesn't fade in, because that would mean an extra level of state checking and timekeeping that I really, really don't want to add to the code, because it'll make things hideous.

* What I did for ths game, that I've tried in a few other prototypes but never made a proper library of, was implement one, single main loop, which triggers methods on a "loop object". For example, when the game is first launched, the main menu loop object is instantiated and given to the system. It is the menu loop's responsibility to instantiate the next loop object, e.g. start a new game. The game loop object encapsulates all state and resources necessary for play, along with a callback that the generic loop usess to perform rendering, collision checking, etc. (there's only one such callback, the system doesn't care what you actually do during it, it just flips the buffer, ticks the timer and calls again). The great thing about this is that, in Python at least, switching to the next main loop simply involves swapping the current loop object for a different one, right under the system's nose without even telling it. Plus when this happens, the reference count on the loop which made the switch drops, which can be used to trigger automatic unloading of all no-longer-needed resources via the destructor. The downside is that since you're relying on the destructor to de-allocate your resources, and have to instantiate the next loop before the current loop can die off (unless you want to quit the game, in which case you simply set the loop object to None, which the generic system then picks up on), you might end up with an overloaded system in the interrim - this would be a job for a slightly cleverer generic loop, capable of being told which class to instantiate next rather than relying on the variable it uses always being instantiated. Sadly, without adding further levels of callbacks and abstraction, none of this makes the nifty little timed fades, and other UI flourishes that make a game seem professional, inherently easier to implement in a reusable fashion. Also, I've yet to figure out how it would be possible to shoehorn multiple threads (e.g. have a physics thread in the background for some of the loop objects) into a system like this.

Oh well. ACCELERATOR has been submitted. It's playable, but by no means finished. It lacks:

• A high score table (your score is lost after each game, sorry)
• A tutorial
• Nice intro
• Menu transitions, game start transitions, death transitions...
• Sound
• Serious testing

I've never done one of these competitions before, so please be nice. I really like the visual style of the game, and the speed and feel of the gameplay is close to what I wanted to achieve, but overall this can't really qualify as much more than a prototype.

I haven't got the time to implement any of what I know is missing before the deadline; it's less than half an hour away as I type. When I sat down to work on Friday evening, I had a semi-functional menu, and a scrolling tunnel. Since then, I have not slept (it's now 1 AM Sunday morning here), and have implemented the HUD, the first-person control method, tunnel wall collision detection, ALL the particles (and the lightning), scoring, shooting, power and shield mechanisms, and so on and so forth. I'm done.

If I ever continue this project post failing to win PyWeek, I'll be adding sound, GREATLY tidying up the particle instantiation/collision system (there is currently a *lot* of code duplication in the main game loop), adding graphical transitions between menu pages and upon loss of a life, and making better use of PyODE.

In my previous diary entry, I mentioned how much I hate collision detection. Today, I spent literally 5 or 6 hours trying to figure out how to align a cylinder in PyODE to match the "electric arcs" I have in my game. Mainly because of (poorly/un-documented) differences between ODE and OpenGL coordinate systems; partly because PyODE doesn't provide any interface to some of ODE's more useful rotation functions, such as quaternions. It also doesn't seem to provide any access to the spaceCollide or spaceCollide2 functions, and so I ended up doing all collision detection manually; hence, you'll see a lot of loops calling ode.collide() within the gameLoop class (if you dare look that far down in my code).

Also, because I started writing the first-person camera and tunnel collision code without any intention of using ODE, I've ended up using ODE *only* for collisions, not for tracking the movement of objects - hence you'll also see lots of calls to ode.GeomObject.setPosition. I have a sneaking suspicion that this might have effectively disabled ODE's ability to do swept collision tests, and hence negated one of the biggest advantages to my using it - but I'm not sure how I'd go about finding out whether or not this is the case, and certainly don't have time to go back and do things properly. Anyway, it *did* (eventually) get me my oriented cylinder/sphere collision test, and as that was the only one where orientation mattered (all other collisions are sphere-sphere), in the long run it probably didn't slow me down much more than trying to write a decent implementation myself would have. Meh, I dunno.

Please attempt to enjoy my half-finished entry. It's only the third game I've finished in my entire life, and the first 3D one that has ever even got off the ground.

Oh well.. spent the evening after work on the phone with/chatting online to my gf, rather than working on my entry. Still, thought I ought to do something, so I did a bit of code tidying (more object encapsulation, fewer globals) and finished the menu system I started yesterday. Note that this just means menus render, and you can switch between/select items; the only item that is currently functional is "quit".

Never done a graphical menu before, so this is all a learning experience; my previous games (well, the finished ones) have always used GUI libraries of some sort, e.g. wxWidgets or Delphi forms, and used buttons, text boxes etc. directly.

I've had plenty of ideas in the past regarding what main loops should look like, how a graphical menu system could work, text rendering in OpenGL and so on and so forth, but most of them have either stayed ideas, or been implemented entirely separately in little "proof of concept" apps that never get turned into finished games. Basically, this week is serving as motivation for me to finally finish something, rather than spend ages perfecting one small part of a system, only to get bored before integrating it back into any kind of whole.

The only thing I'm really unsure I'll be able to get working well in the remaining time is collision detection, which will unfortunately be fairly essential. I hate collision detection with 2D rectangles, never mind fast moving 3D objects. It's just something I've never put in the necessary time to get the hang of, because it really doesn't interest me from a technical standpoint. If you died because your bullets passed straight through the thing you were trying to shoot out of the way, or you didn't die after flying straight into something, it'd be a bit of a disaster.

Any good references on how you do collision detection when objects are potentially fast enough to pass through each other between frames?

Oh, and a screenshot of the menu is here, if you're interested.

Edit: Fixed screenshot link

..that last screenshot seems to have provoked what can only be called "expectations". Oh well - I guess I'd better get on with hammering it into the form of something vaguely playable.

Unfortunately for the purposes of this contest, I have a full-time job; fortunately for me, it involves playing with Perl (yeah, I know, Python would be preferable...) and Linux all day long for the nice people at SmoothWall. :)

Anyway - less procrastination, more coding...

This is the tunnel through which you will be flying. It's an incredibly fanciful rendition of the interior of a particle accelerator (ring type, but immense, so I don't have to bother with dead ends or rendering curvature).

It has also had me mesmerised for about the last ten minutes - if the screenshot was animated, it'd show both the texture scrolling to simulate moving down the tunnel, and the camera sweeping a slow random path over the cross section. If I can stop looking at it for long enough, I need to start adding a menu, a control mechanism, and objects for you to shoot at and/or crash into at immense speed. Then, if I have any time left, lots and lots of eyecandy.

I'm reasonably impressed with the tunnel texture work; it's meant to look like wires/circuitry, and has almost turned out exactly how I envisaged. If anyone knows anywhere I could find texture tiles based on *real* circuit boards, I'd love to drop some in and see what it looks like. (The bitmap fonts used for the logo and string rendering weren't done by me, they were taken from the site listed a few entries back.)

Just a quick test of bitmap font rendering, and a first (and, given the available time, probably last) attempt at giving my concept a name and logo.

Yes, this is using OpenGL, so the underlying code is *slightly* more impressive than the screenshot suggests (but not much).

Retro!

I like shoot-'em-ups. I like them a lot. I also like fast, furious games that generate that "in the zone" feeling, like the Wipeout series and underrated PSX shooter n2o. I also somehow needed to fit in with the theme of "power", which stumped me for the entirety of yesterday (which, coupled with the fact that I started a new job last week, puts me at a severe time disadvantage).

I want something with the potential to send you to "the zone", that doesn't require vast amounts of artwork or level design (as I wrote about in my previous diary entry, I hate level design, and don't fancy spending hours creating a game only to have my own enjoyment of it marred by knowing every twist and turn inside out), that won't be a straight rehash of an existing game, and that, most importantly, I'll find fun to play myself. I think I've got it.

I'm also keeping it to myself until I have a screenshot or two ;)

Speed will be a large element of the gameplay; as, once I figure out some satisfying gameplay mechanics, will shooting. But it will definitely not be a horizontal/vertical scrolling game.

No, it's also not that FPS I said I wouldn't be attempting to write in a week.

It's not often you see so many Good Things(TM) brought together in once place. I had to enter, really. I just hope I can come up with a concept that doesn't require me to design levels: I hate designing levels, plus I feel the level designer has had their fun spoiled by knowing what the entire game looks like in advance. Puzzle game it most likely is, then.

Well, I suppose there are certain forms of game where being the level designer is an advantage, and you don't need hundreds of levels to give a game longevity. But I'm not going to try writing a FPS in one week (hint, hint).