Friday, October 5, 2007

Backstep to save the project

Lots of things have happened to BRAVE. I got the FGE (Flight Game Example) integrated into the game (or vice versa) and I have started working on the gameplay a bit more. I've dropped back to TGE 1.5.2 while the TGEA LOD bug in 1.0.3 is worked out. I really want the game to run with shaders and if TGEA isn't going the way I need in Jan next year I will implement the Modernisation Kit and just use TGE.

My humans are still using the job system, but I have introduced landers (just mock ups) and have created some spawn points to work on the waves. I did a mini crunch to get the game playable, but there is still heaps of work to do before I can nail down a tech demo.

Here's some screenshots of the game so far. I have put in Defender sounds as placeholders until I can create my own sounds. I was playing Bosconian the other day and when the action gets thick, there's lots of sounds going off. The sounds you hear in the old arcades is the sound design I want to create for BRAVE. They are simple sounds which you learn to know what they mean, a human is being picked up or killed, you get a free man, an alien shoots etc. I also want them to be synthetic so they are just like the old arcade games.

I have to hand it to Decane for the excellent FGE kit. It has saved me heaps of time in development, and the flight model in it is almost perfect. I want to add straffing to the flight controls, and I am going to change the aiController of theirs so I can tell it which ships should not fly like planes, but like floating platforms. The landers for example float down the ground looking for humans. They don't pitch and roll like planes would.

Next I am going to get the landers pickup the humans, get them to rise to the stratosphere and convert to mutants, add scoring and level complete. I'll post an update mid October. Of course it all sounds like a big rip off of Defender - that's because it is. I want to make a 3d Defender as the basis and then derive my own game from that game play dynamic.




Wednesday, September 5, 2007

AI Pathing system

My AI path finding works like this. Bear in mind I read about A* and thought it sounded too complicated when it's all precompiled anyway.

Preparation:
Open editor and click out a bunch of separate paths around buildings - you should try and make as many paths that lead to other location as possible.

Algorithm:
1. When running AI search find closest path to destination.

2. Start COST at 0

3. While traversing nodes on current path, can any nodes on this path see a path to player OR Is node to next path obstructed? (add 1 to COST per node traversed) Store x,y as you go - the idea is to make a path using nodes of existing paths, the paths are just helpers.

4. If failed on either in 3, continue to end of path (summing COST)

5. When at end of current path, look for next path along "rough" vector toward player - tick FAILED counter - pick next path - log JUNCTION(x) ( and COST to here )

6. If FAILED counter < n, pick a new path from destination and goto 3.

7. When FAILED reaches n record COST for *this solution is stored.

8. Next solution, go to JUNCTION(x) until all paths exhausted.

9. Pick lowest cost path.Presumably, when laying the paths down you should have given the algorithm enough chances to get to the player.

So in this pick (black lines are placed by user/programmer) at each junction only nodes "roughly" heading toward the player (even though obstructed) where chosen.

What do you think? Too complex? Not efficient perhaps? Full of errors ?


September - Posts from GG and MyDreamRPG

Here's my latest GG blog which covers everything.

http://www.garagegames.com/blogs/31800/13492

So next is the hard work. AI pathing and behaviour. I was wanting to avoid it, but it has to be done sooner than later. I wrote my own AI pathing for another game, so I might adopt that. It will involve drawing paths in the editor and then the code works out the minimal cost to get somewhere, thereby choosing the best paths.

I've also been thinking about scene handling and I don't really want to hand place every building. I might try an organic, grid aligned algorithm to generate cities and job locations. Will see how this goes.

Post for August - belated

Here's August's activity... mainly blogged on GG and MyDreamRPG...

http://www.garagegames.com/blogs/31800/13335

I've spent most of this month working for 'the man' so development has been slow. I thought I should check in as the month flies on, and blog a little about my progress. It's been mainly research this month.

I've animated the male human using a cartoon-like jutty run cycle. When my pay packet comes in I'm going to invest in an animation book and continue creating unique walk and run cycles for a handful of humans.

I've discovered a free program called Make Human that uses a standard mesh with subtle morphs to create a bazillion different types of humans. So I will use this to create most of the humans and work on skinning to create different looking humans using very few different meshes, about a dozen textures for clothes and unique run cycles.

I've also been implementing the hud and an onscreen debugger, which does something strange every now and then. For some reason writing out play.gui destroys the mouse control and I can't figure out why. It's got something to do with the way the editor writes out the datablocks, but I'm still debugging that to discover the reason.

Next I want to animate the man to work on a machine, and pick something up. I will work more on the Harvester to get it to chase the player a bit better and hopefully in a few weeks have the Harvester eat humans.

Signing off for now. I'll do a bigger update next week.

Wednesday, July 18, 2007

Moving the humans

I've just implemented a pathing system for the humans. They will appear to be doing a job. At the moment I have one human moving from the beach up a hill to a jetty. What I will do next, is at every node there may be extra information on how long to wait, what anim to play, and any objects to interact with. This will make them appear to be performing roles. For example a human could get a box from a boat on the shore, walk up to the jetty and drop it off. From there another human may pilot a boat, drive up to the jetty and grab any boxes there. I will then create a scripted approach to assigning roles. Humans must be kept alive to keep your infrastructure going, otherwise you run out of shields, fuel and weapons.

I have also implemented a rudimentary scoring hud.

Sunday, July 8, 2007

Waypoints and AI Video

I've got some video here of the Harvester using the Waypoint and AI system to find a human. Looks kinda ominous when this thing heads across the water to the human.

YouTube Harvester Attacks

The Harvester will suck the human into it's chamber to be stripped of flesh and the bones spat out - gives me a chance to use my Skeleton Pack.

I've also blogged at GG to show the Harvester and work on interiors.

http://www.garagegames.com/blogs/31800/13196

Thursday, June 21, 2007

Waypoints and AI

I've implemented a system borrowed from the GG pages that allows me to spawn alien bots in avatar form, then mount them to a vehicle. Once they have done this, they then scan for humans - the function is more adaptive and will scan for any type - and then they go after it.

What's really cool is they know how to fly the ship I've mounted them to.

Future work this month will include the following...
- Spawn enemies from barracks inside mother ship
- They have to walk to a ship in the hangar
- They then have to fly the ship out of the hangar
- Once disembarked they will then look for humans to eat / shoot / capture
- When they have a human they will perform their role on them.
- Missile / Laser / Weapons inventory system for player
- Recharge systems for player
- Humans to perform work - infrastructure.