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.

Bioshock

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):

(Shiiiiny.)

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).

---

---

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.

Upcoming!

---

 Next Up to Bat

Brand new project on the rise! I didn’t try all that hard to break away from the overhead shooter genre, so it will be following somewhat along that vein. Since I’m without internet, I decided that now would be a fantastic opportunity to create a small(ish) game that allowed me to flex myself outside of the conventional boundries that all of my games thus far have constrained themselves by. This new project aims to introduce several new systems and areas that none of my games to this point have explored:

Storyline. All five of my released games focus on mindless violence, more or less. Admiral Overalls was about as close as I’ve gotten to a game with a story, and that was just a blurb of text at the start and end of the game. I’d love a game that actually told a story, and being able to offer the players a character who really has a meaning and purpose in the world s/he is in.

Hand-crafted levels. Procedurally-generated content has been the cornerstone of all of my games to date, excluding Admiral Overalls, which Dean actually developed the levels for. Procedural content is neat, but we still aren’t at the point where it can replace the warm feel of a human touch. Being able to custom-tailor levels for more interesting and in-depth situations is something that randomized levels cannot do, and I’m excited to be able to bring to the table.

NPCs and Dialog. Flat-out, I’ve never finished a game that had NPCs in it, or dialog between the player and other characters. I really enjoy both creative writing and writing dialog — which I haven’t invested time in in far too long — so I’m looking really forward to getting into this. Dean and me agree that a Shadowrun/Morrowind-èsque conversation system would probably work the best for this game, whereas the player selects conversation items from a list when engaging in dialog with another character. The inclusion of dialog will also open the door to the clever insertion of intermittant witty humour, which I’ve sadly had to leave out of other projects.

Atmosphere. This one is the prime goal, which is really a byproduct of the above items and other things, such as general game polish. Atmosphere is that nice tingly feeling you get when you really feel like you’re part of that world, where you feel like your presence is actually making an impact in that game world. When I played through the project of another developer, Ravuya, and his game, Glow, I realized after blowing the guts out of the last boss that this feeling really was attainable even within hobbyist games such as ours.

But most of all, the rule I’m following for developing this game is KISS: Keep It Simple, Stupid! Projects tend to fail because the author bites off more than they can programmatically chew, which I’m confident was the case for my last couple of drop-offs over the last few months. Although it means I’m sacrificing some code cleanliness for ease-of-programming, it’s a trade-off I’m willing to make. The code is still far cleaner than the mess known as Membrane Massacre, so I think I’m safe.

Screenshots? I guiltily admit that I’m writing from work right now, so I don’t have screenshots to display at the moment. I haven’t even talked about what the game is about, either! Hopefully I can shed some light on both of these items in my next entry, which hopefully will start becoming more and more frequent. Work is finally winding down in this final month (August), so I can start to get back in the swing of things when uni rolls around this September.

---

Addendum

I’ve realized that with the previous title I gave my right-hand sidebar, “Respected Developers”, that I likely had of insulted a number of people inadvertantly. It now holds the more apt title of, “Exceptional Developers”, which I think is more accurate. I refer to the folks who work their arses off on game development to no end; even more maniacally than the average (but still awesome) developer. If I were to make a list of “respected developers” I would probably run out of webspace trying to list all of you. I deeply respect all of you folks — you know who you are!