The calm before the storm

This may be an odd and somewhat controversial statement, but I am mostly convinced I am actually a masochist. Now, before you all label me as some sick, twisted pervert and lock me up, allow me to explain.

Being a programmer, my days are mostly spent in an endless cycle of frustration and joy; spend 8 hours trying to fix a bug, banging my head against the wall, followed by 5 mins of yelling out in praise of whatever Gods saw fit to show me mercy. As you can see, this endless cycle has a ratio of about 80 pain, 20 pleasure. It's not something a normal person would choose to do as work, much less willingly in their own free time.

Yet here I am, plodding away for hours on end. Even now, as I write this mess of words resembling a blog post, my mind is planning a complete system overhaul and major redesign of a game I had previously developed. Titled 'Haunted Within', the project was forced reach code lock and release prematurely. This meant a lot of rushed code, hacky workarounds for issues, and overall poor standards that I would not normally tolerate. I've regretted a lot of what I did, and now that I have some free time on my hands I figured I can revisit it.

Exhibit A: a work in progress

My plan to 'fix' the game is fairly straight forward; since most of my desired features are already in I simply need to remove all the hacked-together bits, correct the underlying problem at its source, and overall polish the fundamentals of what already exists. In the cases where I do need to change major aspects, I'll simply scrap what I have and rework the system from the ground up. Obviously this will take a lot of work and time, so I'll try to avoid doing whole changes if I can. But I know for a fact that some systems really need the overhaul.

System A: Graphics

This one I don't think needs too much fiddling. I do want to touch up on the draw order; currently the objects are being drawn in order of  most recently to least recently spawned. By introducing a z-buffer, I will be able to rearrange the draw order so that objects closer to the foreground are drawn before others.

System B: Game Logic

This system is where things get messy. When I say game logic, it refers to things such as object spawning, collision handling, object logic, etc. Overall, this system tries to handle far too much on its own and does so in a really disorganised way. I plan to split the game logic into 2 separate systems, one for object spawning / logic, and one for object interactions.

System C: UI

Ah the UI system. The trouble with UI in this project is that it uses a third-party system, named CGUI. Normally third-party systems aren't a bad thing and can significantly make things easier, but CGUI is... well, it's not exactly pretty. It seems to be designed using c# syntax and this makes it rather tricky to integrate into my own code. To be honest I'm not sure what I can do here... I guess I can try to keep it as clean and organised as possible. Pretty much all I can do, really.

I'm going to be working my way through these systems and more (a LOT more) through the coming weeks, whenever I have time away from my other duties. My long-term goal is to have the game polished enough for sale via Steam Greenlight, so if I want to get there I need to get working.

VR, AI and the graveyard shift

People, praise and rejoice! For my house is FINALLY hooked up to the World Wide Web. I should be grateful, but in all honesty I'm feeling a little depressed.

You see children, it just so happens that our exchange area (South Brisbane) is ruled by the demonic overlord Telstra. They decided that our area, and our area alone, should possess a lovely alternative to NBN called Fibre Access Broadband.

Go and see their site. Just look at it.

"Now you can enjoy all the speeds of NBN fibre, arbitrarily reduced to ADSL2 speeds for some reason! Oh and this stuff isn't cheap so we're also going to triple the connection costs. Don't you love us!"

Screw you Telstra. I hope all your children are eaten alive by spiders and any money you made seized by the government under suspicion of racketeering.

But enough dark muttering. Let's move onto a more positive topic: games and coding! (^_^)

GAMES:

The other week I managed to get my hands on a Joystick Controller, a second hand Logitec extreme 3D. I'm not usually a fan of flight sims and such, but when I received it a stroke of genius struck me. Joystick + Oculous Rift + War Thunder.

War Thunder is a Free-To-Play War-vehicle Combat Sim, with multiple players battling in either tanks, planes or a combination of both. It is a very polished game considering it's FTP and still in development; there are future plans to implement a Naval Combat aspect in warships, and integrate all three (air, land, sea) into a battle royale mode.

 It may be glorifying the horrors of war, but my god is it glorious.

I've been playing it for a while now, and it occurred to me that having an actual joystick to fly WWII war planes would be much better than the mouse + keyboard alternative they offer us.

But that's not the end of it, ladies and gentlemen. I also happen to own an Oculous Rift, of which War Thunder supports. The plan was to plug in my Rift and joystick, boot up the game and experience what it's like to fly a Mitsubishi A6M Zero  in all its virtual glory.

The result was everything I had hoped for. Controlling the plane felt authentic, the view from the cockpit in VR was incredible, and trying to perform immelmann turns was exhilarating. Unfortunately I couldn't experience it for too long once the motion sickness set in; since I own the DK1 version of Oculus Rift motion sickness is more pronounced as it is, let alone without the further mind bending that comes from flying a plane in VR. It's also not very viable for actual combat, since orientation and spatial awareness takes a nosedive when you don't have a tangible sense of the object in motion. I am definitely going to keep using the joystick, but the Oculus experience will have to remain for joy-flights only.

CODING:

My most immediate concerns regarding programming is the AI bot tournament, which is to be held this Wednesday. I was pleasantly surprised to see my bot doing so well in the last tournament, coming in at 4th. This is an admirable result considering I wrote the whole thing in 2 days and didn't really bother with tweaking. This time, however, is the added challenge of navigating a maze and the pathfinding that comes with it. Apparently, many of the others in the tournament placed great emphasis into pathfinding, and that's the only reason they lost in matchups against superior shooters.

Hmm. That's not good. Movement is possibly the weakest part of my bot code. So how to improve it? My original plan was to use a simplified form of Goal Oriented Action Planning to govern my bot's overall behaviour, with standard A* to figure out the actual pathing.

Unfortunately, the more I read about GOAP the more I realised that it wasn't suited to the task at hand. GOAP is designed to simplify large, nebulous goals by breaking it down into a list of possible actions and determining the most appropriate plan. When your goal is as simple as 'find bot, shoot, kill', the rigidly structured system and large overhead is wasted and the result becomes more confusing than before.

GOAP readings. Surprising amount of games use GOAP in their AI

In the end, I have simply stuck to standard A* pathfnding with some plans for maze sector-based hiearchal A*.  It does seem like Finite State-Machines are best suited for smaller projects such as this, and in retrospect it makes sense that it would be.