Stealing Ideas

I was thinking about my old game engine the other day. I've barely touched that thing in over four years. Yet still I kinda feel like someday I want to do something with it. I don't know why, I just can't let it go. Some time late last year I put a few weeks into cleaning up the lowest-level module and converting it over to build with a makefile system (I'm running Ubuntu now, no more MS Visual Studio). I was having fun for a while trying to design a powerful multiplatform makefile, and I got the first module to build with it. I guess I ran out of time and/or steam shortly after starting to look at the second module, and of course then the momentum was gone.

I'm thinking about maybe going back to that second module, trying to get that to build under the new system. If I could get the engine running on Ubuntu that would be nice. I just have so little time these days, and to be honest I have less motivation than I used to; I don't really play very much these days, I have multiple time-consuming hobbies, I'm very busy at work, and with the Indie market huge on Steam these days there's seems to be less reason to try to produce a game for it's own sake, not when I don't exactly have any big ideas that I feel the need to see made.

Speaking of ideas, maybe I'll just put down what ideas I have had in the last year or so. I might have mentioned some of these before so bear with me.

First of all, back when I started this blog I had an idea for a game which I tentatively titled "Ghostwalker". The general idea was that as you got closer to death you would start to see into the spirit world; this could be an advantage since you would be able to see enemy souls through walls etc. A later idea involved multiplayer games where different players saw the world in different ways.

Well, recently I was thinking about that again and came up with a different take. This is heavily inspired by a short comic I read online a while back (I believe it was called Milk Run, although I remember something similar in a Spiderman comic once), where a man was stuck in a powered suit that fed him altered images of reality, making him think he was a knight battling demons. Remembering this, I thought, why not do that in a video game?

It would work something like this: the game would never break from first person. There would be very little narration; as much as possible the "story" -which would probably be quite minimalist - would just be communicated through events in-game, and as much as possible without trying to take control away from the player. There would be no HUD (except I suppose the pause menu). You would play a character who remembers nothing. This might not need to be explained outside of their body language in the first few seconds of the game, as they look at their own hands with unfamiliarity; I think perhaps it's enough that no backstory is given; he is as confused as you are (well, more-so since you know it's a game), which I think helps to put the player on the same page as the character they are playing, even if it can be clichéd. But hey, what isn't a cliché these days?

So however the game starts, the main character is quickly fighting for their life against demons or monsters or something, in old-fashioned or possibly unearthly environments (this would take some thought, but one element would be that all text that you come across would be in unreadable runes, as part of making the world seem unfamiliar). Early on you pass a mirror - and see your reflection: you are fully armoured (which you might have guessed from the sight of your gauntleted hands earlier). I'm thinking that at some point - probably the very first few seconds of the game, before the player is handed control - the character tries to take the armour off, but can't. It might be a good idea to scatter mirrors through the game so seeing yourself is a normal occurrence. You discover that you are capable of firing energy blasts from your hands (this might not even be scripted or explained; when the player naturally starts pressing buttons on the controller he discovers the "attack" buttons?). Perhaps there were glowing runes inscribed in the gauntlets' palms.

So the game goes on for a while. Some kind of narrative might start to take shape - I haven't put much thought into this, other than the idea that (in keeping with the comic) you probably learn about someone who you have reason to kill. Perhaps you are presented with a "vision" of the persons face, and he is made to look evil / shown at the head of the army of monsters/demons who you are fighting. Perhaps you occasionally come across text leading you to him, or perhaps you are just guided by visions.

After you've been playing the game for a while, there starts to be some bugs. Graphical glitches and so-on; animations that look off, etc. Nothing big, but it starts to get noticeable. Occasionally the whole screen glitches a little, but only for an instant, then it's back. This should be fairly subtle, always in-game (never trying to draw your attention to it in a cutscene or anything heavy-handed like that - heavy-handedness is the mortal enemy of plot twists), and it should go on for several hours of gameplay. Then it starts to get a bit more noticeable - occasionally you see models that look like they are from a completely different game - humans in modern clothing and so on. The model will probably be replaced after a moment with something more fitting in-game, like a demon. Then it starts to get even worse. As you pass mirrors, for just a moment (so at first the player will almost certainly miss it, or at best only catch it from the corner of their eye; eventually it might happen for long enough that if they are looking for it they will see it) the mirror doesn't reflect the knight in armour, but a man in a robotic powered suit. Finally - perhaps when taking damage from certain types of enemies - the whole screen starts to flicker and show you a completely different view, one of a slightly futuristic world populated by humans and robots rather than monsters and demons. During these glitches text suddenly becomes readable, the incomprehensible sounds your enemies are making are replaced by people yelling to each other in English, and so on.

I'm not exactly sure how exactly the full truth should be revealed (although I think it should be mostly obvious by now), but eventually you discover that you were locked in the suit and manipulated into killing a target (whether you realise this in time to not kill the target could be left open to player actions?). Perhaps there needs to be some motivation provided, like the suit is very powerful but people won't wear it willingly because it fries your brain or something, so in order to reach a well-protected target you were kidnapped, brainwashed and strapped in, and it's been feeding you an altered view of the world, but as it sustained damage it started to fail. What I do know is that surprise and journey of discovery is everything; it must be subtle, slow, and it MUST NOT BE REVEALED IN THE BLOODY TRAILER!

Ah-hem. Well, to be honest that's a pretty similar idea to a great game idea Yahtzee wrote about once, though the actual execution is obviously different.


Anyway, some other ideas I've had include:

-A split-screen multiplayer first-person arena deathmatch shooter that takes place on the inside of a miniature Dyson-sphere like structure. The general idea being that a) there aren't enough split-screen multiplayer games around, and b) a small arena where you can pretty much always see everyone else (as all you need to do is look up to find them) should help solve some of the problems associated with a "deathmatch" style game with only a few players playing.

-As above, but with fancy gravity mechanics, so there would be floating structures in the middle of the sphere, and if you get close enough (by jumping or using a jet pack or something) their gravity starts to affect you and pull you down onto the them, so you can go leaping across this space by jumping between the gravitational pulls of these floating asteroids and things.

-A strategic shooter (X-Com style) which obeys strict line-of-sight, so you can only see on-screen what is in the field-of-view of your characters, everything else is just blackness (except things that they have seen, which is then a muted grey to represent the fact that it's their last view of the place, but it may no longer be accurate).

-As above, but multiplayer with timed turns, so eg 30 seconds to decide on a character's action, then the character does it, now the next player has 30 seconds to decide what to do with their next character etc. Commands would involve things like "move then go into overwatch" or "move then scan for enemies" or whatever; you would have to que up all commands before triggering the execution, after which you have no control until your next turn. Not sure how well this would work, but I think the idea has potential - it would probably need lots of balancing though to give players a reason to advance without them very slowly stepping forwards while just hugging cover. I know that there's a game that works like this (can't remember the name), only everyone decides their moves at the same time then they are all executed at the same time, and I don't think there's any line-of-sight limitations? Dunno if there's anything closer to what I'm thinking than that, but I wouldn't be surprised if there was.

-A cartoony Street Fighter-like game that ONLY has special moves and ultra-over-the-top-super-moves, no regular jabs and kicks. Silly and probably relying much more on luck than skill, but could be funny for a few minutes.


As I've made clear, none of these ideas are very original, mostly they are slightly different takes (at least to the best of my knowledge) on what's already been done. Some of them I think have potential, but I suspect that even with modern game dev tools they are mostly too ambitious for just one man even if he had the time and skill, which I certainly do not. Which is why I'm writing them down; I'll obviously never be able to actually create them.

Animation more sorted

That thing I said yesterday about the exporter only exporting a single pose at a time? Solved. Actually took much less work than I expected, and now I can export an entire animated action in a single file. Might have to tweak it later after I tweak how the engine handles animation of course, but that's the nature of the work. It's an iterative process.

Animation sorted

I recently started to spend time on my engine again, and have finally solved the issues with importing geometry and animations from Blender. There were some problems before that I had not noticed because I had not tested enough, but things seem to be running quite well now. I've also cleaned up the code a bit, and improved the export scripts, making them more user-friendly. The animation export script currently only exports single rig poses though, so the next step will be to export an entire "movement" in one go. After that I think I'll look at graphics again, try to throw in some fancy effects.

Current progress:

Bind pose

Posed bones. It may not be obvious, but this is supposed to happen.

Brave new chicken

I've not really done any programming recently, which does not make me happy. The last thing I completed was some edge-polygon intersection code for the mesh splitting system. While I was testing this I ran into some issues that I had faced before in my previous mesh splitting system. The thing is, the last time I chickened out due to time constraints and went with a simpler version. This time, however, I shall try to keep hacking away at it and see if I can't implement the full system that I failed to complete last time. But I'll be doing it bit at a time while I work on the other parts of the engine, which of course I'm barely working on since I'm hella-busy with work and since I've just taken up painting Warhammer 40K miniatures, which I'm almost stunningly slow at. Seriously, I'm still working on my space-marines starter pack. Hopefully someday I'll get around to those Grey Knight Terminators that I just couldn't resist buying.

Killing time

Right now I'm putting off starting any major jobs on my engine, mainly because I need to spend more time with Blender but don't want to because I'm currently trying to learn 3D studio Max (and other softwares) for my job. Until I can start working on the animation system, I've been spending a little time integrating my old mesh splitting system using the new mesh format I'm using. This has given me a chance to experiment with a pattern of code organisation I thought up. Basically, there are some functions that I may use often in areas that aren't speed-critical, but will also need on rare occasion in very speed-critical areas. This may seem obvious to most people, but I've never seen it in use and so I'm kind of happy with the idea, but basically what I do is write the function as an inlined function, but also have a non-inlined version that just calls the inlined version. For example:

int calculateThing(int i1, int i2);
int calculateThingFast(int i1, int i2);

inline int calculateThingFast(int i1, int i2)
{ ***blahblahblah*** }

int calculateThing(int i1, int i2)
{ return calculateThingFast(i1, i2); }


Now, assuming that the compiler actually inlines the function properly (not sure how to check on that, if anyone knows how to make sure it does actually inline the function please let me know), I will be able to inline the function where needed and call it normally where needed. By the way, if anyone knows a better way to do this, by all means let me know.

Anyway, I've written an infinite plane cut class using inlined line-test functions, which curently tests edges against a plane (it is also capable of figuring out if the ends of the edges are exactly on the plane, which I will need later). Here's some sample images. The plane is represented by a square with a red dot representing the center (or a point on the plane) and a fading line representing the normal. Since the plane is of infinite size, the size of the square is not relevant.
The red dots signify that the plane is intersecting the exact ends of the edge. While it isn't obvious, the bottom edge, which is parallel to the plane and therefore fails normal line tests, is correctly being handled, and the two ends of the edge are being marked as exactly on the line.

Now a normal line test against the two upright edges.
The top of the edges are being detected as exactly on the edge.

So some progress is happening, next I want to work on a finite, circle-shaped cut, then a convex polygon cut. Once that is done, the next step is to start handling the different possible cuts, then triangle sorting, new face generation, handling transforms etc. Of course in the long run it has to be integrated with the model format rather than the current simple mesh, as well as needing to work properly with the animation system (a problem I never solved in the past) which doesn't even exist yet... basically it's going to take a while, and I'm busier than ever now. Still, I shall try to keep at it. Wish me luck.

Finally back to square one.

So the new mesh system is almost fully integrated (as much as the old one at least), including the new LOD system. As I said this new system is easier to use, in fact today I exported a simple model from Blender with two LOD levels:


I only ever tested the old LOD system with simple hand-made meshes, it would have taken a lot more work to get a mesh into it from a modeling program, so I'm happy with this. I'm still considering how (and whether) to implement smooth blending between the LODs (which was already working to a decent degree in the old system), but I think I'll leave that until later. On the plus side, this new system should be more efficient, is more modular, now supports binary files, and is much faster to load.

One step forwards, three steps back

I've not been making much progress on my engine for a while. This was partly because I was cleaning up various bits of code, and partly because I was looking into programming for the PSP, and making early steps to prepare my engine to work on it. I found it would be necessary to change my mesh class, which I had previously put a lot of work into in order to support the cutting system and smooth LODing system.

The new system is simpler and slightly more memory efficient, and allows me to use vertex lists making it more efficient to render than my old system. However I will have to redesign my old cutting system if it is to work, that may add some overhead and may end up being less efficient than the old one. Also, the old smooth LODing system is out the window. The new LODing system I am writing (which simply uses different index lists with the same vertex list, far less innovative than my old one) will require a greater memory overhead (though still less than using seperate models) and in it's current form will not support smooth blending between the LODs - however, this is not because it can't, but because the old LOD system I designed was harder to model for and would require a lot of work writing tools to support, while this version will be much easier to model for and should not require any special tools. In the future I might expand the new system to support working the same way that the old one did, but right now I'll just keep it simple.

So it's going to be a little longer before I'm functionally back to where I was several weeks ago. The time has not been wasted, but the benefits aren't yet visible. That's the way it goes, right?

Ghostwalker: First Screens

After several months and a little work, I have the start of a game engine and the start of an idea. The basic concept of Ghostwalker is a generic first-person-shooter with a bit of "Legacy of Kain: Soulreaver" or "Dark Dominion" thrown in. Allow me to elaborate.

The as yet unnameds main character in Ghostwalker will have a limited ability to see into the spirit realm (if anyone has read Dark Dominion by Defiant Comics, they'll get the basic idea). However, normally he can only do this as he himself approaches death. In the same way that most FPS games these days communicate the player's health using on screen filters, usually a reddening of the screen, in Ghostwalker the player will be able to see into the spirit realm as his health gets lower. This will actually have the opposite effect to typical FPS games in that the player will have an advantage - there are no walls in the spirit world, so the player will be able to see enemies through obstacles etc.

Since health will not regenerate automatically (no Wolverine here, folks), the player will be able to play with low health to take advantage of this ability, at greater risk of dying in a firefight. Enemies may have souls that differ dramatically from their physical appearance, eg. werewolves will look human but have wolfman-like souls. Some enemies may be invisible, thus the player will not see them until he loses enough health to see their souls. Others may not have souls, such as zombies. The player may gain spells to allow him to temporarily see the spirit world even at full health.

I realize that the idea is not so different from the special vision modes, such as thermal vision, present in other games like Syphon Filter, however I'm hoping it will be better integrated, allowing the player to play without needing to stop constantly to activate his thermal vision goggles for a moment, only to switch back to normal vision. I'm also hoping it will be more visually interesting. Like I said, nothing groundbreaking. To be honest, I'm mainly doing this as a hobby to improve my own skills, if I someday have a halfway decent playable demo I'll be ecstatic. If any of my friends (you know who you are) are interested in helping, let me know. Truth is, I'd love some artistic help, I have a few character ideas that I'm too crap to draw myself.


The engine currently has a few features planned or in place:
-Efficient smooth LODing of meshes (more details to come).
-Real-time mesh splitting (haven't started to integrate it yet, but the engine is designed around the neccessary data structures).
-Multiple models per object for the two-stage rendering needed (physical and spirit models).

I have made some progress, with the framework of a game engine in place, some asset management code working nicely, and the basic smooth LODing system working in-engine. It's still nothing but a very basic rendering engine, with no physics or animation and only very basic rendering abilities. Still, it's enough to show a few early screenshots of the basic concept. These are using free models I nicked off the net:

Normal view:

Player at around half health, starts to see spirit world:

Player almost dead, visions is almost completely in spirit world:
Well, that's all for now. Soul Samurai out.

GhostWalker: Announcement

Since Geocities is closing, I decided to start a blog instead of a website, for now at least. I'll start by copy the entire contents of my old site in this post (previously on geocities.com/solesamurai/):



Soul Samurai presents: Ghostwalker

Ghostwalker is the tentative title of a game I am currently working on. At the current rate of progress, it will probably be ready to demo some time next millenium, so don't hold your breath. If you do start holding your breath, and you are still holding it next millenium, please contact the guiness book of world records. Don't try to contact me, I'll be dead.

Sorry, back to Ghostwalker. The game will be a first person shooter of modest proportions, but hopefully will have enough decent bits to be worth a quick look. I am currently working on the engine, which I am calling "Soul engine", because I am not very original. It is being written in C++ with OpenGL.

That's all for now, more details to come.