Gauntlets of Recursion (+3)

Times, trials, and turbulence.

Monthly Archives: August 2007


if( developmentTime() < gameTime(GAME_BIOSHOCK) ) {

Purchased Bioshock today after confirming that it ran satisfactorily on my machine. I can run it with most of the goodies enabled, but only at 800×600. Certainly more than good enough. The game is gorgeous, and the atmosphere is absolutely stellar. I’m amazed at how much research and thought has gone into the levels, characters, environment, graphics and audio. Bioshock feels surreal. I’ve only managed to knock off two Big Daddies so far, but I’ll take down more as I get a better grip on the physics/controls. }

Next Game?

The whole physics fiasco with Gloom really left a bad taste in my mouth. But more importantly, it made me realize how inexperienced I am with physics programming. To me, one of the most important factors in writing a game is ensuring that the game is at the right difficulty level for me. If it’s too easy, I’ll quickly get bored and can it. If it’s too hard, I’ll get stuck frequently during development and get too frustrated to work on it.

The other factor is choosing a genre/theme that interests me in a long-term manner. By this, I refer to that fleeting sensation that we game developers get after playing a really awesome game for a day or two, and become very motivated to write a game similar to this. This is a mistake! I cannot stress that enough. For those of you with a bit of memory, my last project attempt after I finished Membrane Massacre was called RavenKeep, a roguelike hack/slash. I had just finished playing Diablo for several days with Dean, and so my motivation for it was *flying*. Of course, motivation like that is entirely short-term, which results in the game crashing+burning as interest wanes. Gloom got its motivational-boost from Deus Ex and Neuromancer, which kept me going for a while. However, like RavenKeep, it’s juice ran out too. The end result? No game project once again.

The most important things, one can then conclude, is that: a) the game idea is not too far above or below one’s abilities as a developer; and b) the game’s theme/genre must be one that the developer has had a long-term interest in, to ensure motivation does not dry up after a few weeks.

And that’s where I stand. I feel really crummy at junking another potentially awesome project, but I’d much rather take on something like how I took on Membrane Massacre: by using a basis that I’ve always enjoyed (free-floating Asteroids controls and a destructible environment), and then giving it my own original direction to take it in. I didn’t take any huge development risks either; I stuck to things that I knew (reasonably well) that I could implement. Same idea for my other completed games.

Thus, some serious pondering will take place, and I’ll try and get some groundwork done before I go announcing what I’m working on. Clear skies ahead! ๐Ÿ™‚


Wave 46.

More Pluggage

First and foremost, the main motivation behind this entry was to offer a plug to my good friend DogPriest, who was kind enough to write up a nice little review about Membrane Massacre. The least I could do was give his nice journal a counter-plug. In his entry, he mentions an MMer who managed to reach Wave 46 of Survival, which I applaud. I can say that this is no easy feat — I think I’ve only reached Wave 48 myself! ๐Ÿ™‚

(click for full image)


Internet via Bell Sympatico

Bell and their DSL infrastructure are now in town, which means I now finally have a real internet connection again, which means I can download the Bioshock PC demo. And anime. And play online games (which I don’t play much of lately anyways). Huzzah.


Furthermore, there’s no news on Simba. I’ve been putting out his favourite treats for him on the porch every day — and even some catnip — but it doesn’t look like any of it has been touched. The search continues.

Much woe and downtime.

Macht schnell!

It’s been very slow lately. My work term is just finishing up (finished next week) so I’ve really had to hit my project hard in order to get all finished by the end of next week. It was a more than a little ambitious of me to suggest writing an app from the ground-up to handle all of this annual data they get here, but I’m going to finish it pretty close to the line. Just some finishing touches here, and some documentation there. On the upside, it earned me a shiny “Outstanding” on my work-term evaluation. Huzzah!

Little Lost Kitty

There’s a kitty named Simba. Well, not really a ‘kitty’ — the old guy is about 11 years old now. I’ve had him since he was a wee-little guy, but the thing is, he’s a house cat. This means that he doesn’t know how to handle himself in the outdoors. So, you can imagine how I felt when I got up in the morning (yesterday) to find the ground-floor window screen torn and Simba nowhere to be found. Christ. It’s been over 24 hours since he vanished, and I’ve been searching the neighbourhood to no avail. I’ve been incredibly worried about him, and I simply can’t focus enough to sit down and work on Gloom — it’s hard enough getting stuff done now at work. So while I’m sorry about the lack of development, you’ll all have to bear with me during this particularly hard time. I can only hope that he’ll show up any time now.

Stay tuned. :/

Working hard, or hardly working?

Working hard, I most readily assure you.

As I’m sure many of you whom already juggle a full-time job and a game development hobby already know: it’s tough. It’s especially tough when you write code all day at work and then come home and try and write some more. It’s even tougher when your physics code keeps on breaking on you for 3 weeks straight — but I digress. Sort of. ๐Ÿ™‚

It’s been really rough lately, since it seems like the physics engine in Gloom keeps refusing to work how I’d like it to. I’ve already had to cut down the engine from being a fully dynamic->dynamic simulation to one that works only on dynamic->static collisions/responses, so the least it could do it behave nicely enough for me to implement it. I began Gloom about 18 days ago, and I can’t believe that just getting the physics groundwork down has taken me this long. Gah! Anyways, it’s now operational and seemingly bug-free, so I suppose that’s all I can ask for. Now that this is done, I can finally start on the Actor class, from which Humans and Bots will derive from. My aim is to have an animated player waltzing around the map (possibly kicking objects around :)) by the end of the weekend, at least.

I haven’t been all woe, however. I implemented a simple spatial partitioning system, which is a fancy term for “regular grid”, which covers the game map in arbitrarily-sized cells (I opted for 64×64). The idea is that every time an Entity moves, it calls the grid’s writeEntity() method, which accepts the Entity in question and a Rectangle representing the bounding box of the Entity in the world, which fills in all cells that the bounding box overlaps with a pointer to it. This allows the game, during the collision-detection/physics phase, to do a call to the grid’s getFromRange() method, which accepts a Rectangle and returns a vector containing all Entities that fall within that area. This, in combination with already implemented bounding box checking, prevents 99% of unneeded polygon collision tests, as well as avoiding the dreaded O(n^2) pairwise brute-force checking I was doing previously.

New Computer, and Setup Woes

I’ve upgraded to a new computer just the other day. It’s not a big jump, but I’m now running on a Pentium 4 3.0ghz processor with a juicy 2GB of RAM. A bit of a jump from my previous 512MB. I’m still in the process of getting things restored/reinstalled, but it’s been a little slow. For some reason the Platform SDK (for use with Visual C++ Express) is refusing to download properly, and my copy of Visual Studio .NET 2005 causes anything it builds to crash cryptically. I’m a little frustrated, but I can manage to develop on my laptop until things get ironed out. I’m sure a little kicking-of-the-motherboard will fix everything. ๐Ÿ™‚


Anybody else ready to lose a heck of a lot of potential development hours to this? ๐Ÿ˜€

Trace my rays, baby.

One Pixel at a Time

Side projects sure are sinister, aren’t they? Well, lucky this one isn’t anything large like a full-fledged game, so it serves as just enough to keep my mind feeling fresh at thought when I’m all Gloomed out. What is this project of which I speak?

Why, a Raytracer, of course. If you aren’t familiar with exactly what raytracing is, then I strongly recommend you take a read-through on the aforementioned link. The idea is that the user’s screen represents a ‘meta-screen’ that exists in the 3D environment, from which a metaphorical camera behind it casts out rays of light through each of the tiny pixels that make up the screen you’re looking at. Each ray finds out which object it intersects with, and does a number of calculations to determine its colour — things like reflection, refraction, diffuse and specular lighting, and likely many other things. Through much computation (you can guess why raytracing is slow) the final image can be quite realistic. This is the technique that folks like Pixar use to render their fancy CG movies.

Writing a raytracer has always been a huge ambition of mine — it’s just so cool to think that such a simple algorithm can produce incredibly realistic 3D images with such ease. Not to mention the utter awesomeness of being able to define this world using shapes composed of raw mathematical equations. Here’s an image generated by my (small) raytracer at a juicily-high 1280×960 resolution (clicky):


What we have here is pretty simple by the standards set by the numerous kick-arse raytracers out there. So far I’ve implemented: Phong lighting (diffuse+specular), reflections, shadows, spheres, planes, and textures (for planes only). A short list, but I’m eager to try and get refraction and more shapes in there for some cooler scenes. I’m also quite interested in the notion of real-time raytracing, which mine is reasonably far away from. If I run at 160×140 I can manage a little over 10 FPS (anyone interested in seeing this?). However, I didn’t write this with speed in mind. Perhaps a project for a rainy day. ๐Ÿ™‚

I’m also really tempted to start writing some articles on the topic — I’ve noticed that the current ‘best’ resources glaze over a lot of important material (like intersection detection, explaining the math for the effects, and the general ‘structure’ of the raytracer, objects, and the scene). If anyone has any non-trivial interest in this, please speak up!

More Gloom

Not much programming done lately. The focus currently is getting a rough draft of the design document completed, so I have a more solid idea of what the game is going to look and feel like. I’m really trying to hard to avoid make-it-up-as-you-go syndrome (aka. MIUAYGS), so following the “measure twice, cut once” methodology feels like the wisest move. I won’t blather about the half-baked rough draft material I have so far, since most of it will either change or get cut out. ๐Ÿ™‚ But, as the document progresses, I get more and more eager to develop forward, as the final image of the game grows clearer and clearer in my mind. Onward! ๐Ÿ™‚

Drowning in physics.

Well, sort of.

Like I’ve been raving about for the past few entries, I’ve been focusing on the physics engine that Gloom will be powered by. The original plan was to have it fully dynamic and fancy-pants-รจsque, which I regret having had to decide to water down. I’m quite confident that, given enough time, I could complete this goal. However, I’m really tired of working on it, so a simplification is in order.

By fully dynamic, all objects would react to eachother in terms of linear and angular effects (velocity, acceleration, forces and torques) within a polygonal environment. What I had was somewhat close, but my limited knowledge and experience in physics programming left it still a little buggy and dysfunctional — mostly in collision response. I’ve decided to aim a little lower by creating a rift between two types of objects: static and dynamic.

Static objects, as the name implies, are immobile. They do not react to forces or torques, and so can be thought of as in ‘suspended animation’. Although static, the player can still fully interact with them in terms of non-physics interactions (opening a door, activating a switch, etc.. The reason for this is to prevent the more complicated case of dynamic objects colliding with other dynamic objects. Calculating this response is much more complicated, so I’m averting it by only allowing dynamic objects to collide with static objects, and vice versa.

Dynamic objects are objects in motion. These bounce off of the ground, ricochet of walls, and land on top of innocent static ammunition crates. Once a dynamic object reaches full rest (no linear/angular velocity) it becomes a static object. Special objects (like the Player) are always dynamic, even when stopped. (This system makes it fiendishly easier to sort out collision detection, too. :))

Limitations? Some. Certainly the world won’t be as flexible and dynamic as I originally hoped, but as I play more Shadowrun and read more Neuromancer, I’m leaning towards less hardcore action (a la Deus Ex) and more strategy/storyline/tactic (a la Shadowrun (and, strangely, Resident Evil — only a bit though ;))). The physics engine will still be able to let the user do plenty of cool things. Up to and including throwing potted plants at people. It’s a must.

There is also the idea of ‘Z Physics’, such as the screenshot below. This will allow (albeit basic) physics of objects stacking upon objects, and an illusion of height for objects that require it (eg. grenades, thrown rocks, shrapnel, etc).

Physics Fun

Feel the cyberpunk — *BE* the cyberpunk.

I was out today with Dean, who is also a mad fanatic of the cyberpunk genre. Since I’m not quite as, erm, enlightened as him, he saw it fit to bestow a few items upon me:

  1. His copy of Neuromancer, one of the books that truly began the genre. It’s a little shy of 300 pages, so it’ll be a quick read over the next few days, and should offer a huge boost to my understanding of the genre. Not to mention ideas for game features/atmosphere.
  2. A recommendation to get myself a copy of Shadowrun, both the SNES and Genesis (ROM) versions, of which he is also a raving follower of. I played the SNES version a bit at his abode, and it’s certainly neat stuff. Shadowrun has elements like magic/dwarves/elves, which I’m adverse to in cyberpunk, but it doesn’t detract too much from the coolness of hacking security systems and hiring guns. Irregardless, it will mean another source of inspiration to draw additional material from.

Regarding the game itself, I finally have physics collisions just about done. I had made a lot of silly mistakes in the vertex->edge collision detection regarding the intersection of line-segments and the resulting normals, but it’s working now.

One particular item of note was forgetting to clear the map data whenever a map was loaded into the editor, Polyspawn, which resulted in me loading in a half-finished copy of the map overtop of itself. The result was that a collision with a wall was processed twice, which made some walls (those which I had built earliest) to repel the test object with twice as much force. Naturally until I hunted it down there was the thought, “Why on earth do some walls make me fly back when I run into them!?”. The other error, with the line-segment intersection testing, was mistyping slope as “m = (O.y – P.y) / (O.x – P.y)” — whoops. No wonder all of the intersections I was getting seemed completely randomly off. Both simple mistakes, but hunting them down was painful over the course of three days or so. Arr.

Now that the major ‘oopsies’ are cleared up, the object physics will soon be finished, which will allow the work on the player to start. Which will be far cooler than that bland sentence was. ๐Ÿ™‚

Yes yes, better textures on the way!

Working Title: “Gloom”

Despite it’s downcast name, “Gloom” is actually pretty motivational stuff. ๐Ÿ˜‰

I had promised to talk about me and Dean’s latest project, “Gloom”. The title is totally temporary, but it’ll do the job for the time being. “Project X” just doesn’t have the same ring to it anymore.

Project “Gloom”

“Gloom” follows the cyberpunk genre, fitting in as an overhead action/RPG game inspired by titles such as the famous Deus Ex, Ravuya’s sinister Glow, and the sort of grim world that Skirmish Online might have taken place in. Occurring in a dark futuristic world, corporations, gangs and other consolidated organizations rule atop the governments. The storyline is very much still in development, but the image I hope to impart is one of the world overgrowing its former democratic shrub into a full-blown jungle of danger, cybernetic implants, and high-tech gadgetry.The key aims of “Gloom” are along the lines of the items outlined in my previous entry. Strong RPG and storyline elements are to be present, but alongside violence and finger-twitching mayhem. Much like Deus Ex, to those familiar, there will be multiple ways to tackle the problems that the game presents to the player; most with unique outcomes and consequences based on their choice. Although there will often be overlap, the three means to solve a given problem are generally:

  1. Manipulation
    • Harnessing ‘manipulation’ is the means of trickery, deception, and outright bribery. This includes pretending to be who you are not, tricking people into helping you achieve your own goals (or hinder your enemies’), and using credits as a persuasive tool. Even smooth talking the secretary to get past the security clearance zones.
  2. Brute Force
    • Sometimes violence is the easiest answer. Smashing down doors to get where you need to, bashing in heads, detonating explosives, and generally being a big mean fellow.
  3. Stealth
    • Why face an obstacle when you can avoid it? Sneaking past guards, hacking into security systems, slitting throats, and setting silent traps. Your foes only know you as a shadow.

I’m unsure whether these would be best implemented as player stats, or simply recording one’s methods for data display purposes. It’s too early in the design to say for sure, but these three styles of play will be at the forefront.

Screenshots & Progress

You’re really here for screenshots, so I won’t dally any longer. Clicking on images will blow them up (not literally), and the captions should do most of the talking:

“Polyspawn”, the map editor. “Gloom” will be using polygonal maps, which I’ll speak of at a later time. The editor aims to be BUILD-like, for those of you familiar with Duke3D map editing.

A simple map being constructed with “Polyspawn”. A repeating ground ‘material’ can be chosen to cover the empty parts of the map; even a wall-type.

Information pop-ups appear when the player (or in this case, the mouse) is near an object. Later, health and condition will also be shown on the pop-up.

The polygonal map format lends itself to irregular shapes that helps give a more natural feel that a tile-based approach would be unable to escape.

Sorry about the hideous placeholder textures. They’ll change, I promise. ๐Ÿ™‚

On the ToDo List next, I’m working on the physics model for the game’s objects, which will function similarly to the Object Model that I described for Skirmish Online several entries ago. I’ve opted for a simplified version that will be much quicker to implement, so that I can move on to the bread and butter of the game and get things rolling as fast as possible.

Hopefully this gives you all a decent idea of where “Gloom” is headed. Comments, questions, and ideas for improvement are all welcome, as usual. ๐Ÿ™‚