TMC's Space Ranger Dev Diary

[fog]

Fancy having a go at this project then 'TheKhakinator'  ?

I think TheKhakinator is too rock n roll to be coding now

[T_M_C]

lol.

Hey, who says coding doesn't rock.   

TMC

[T_M_C]

Update
----------

Well christmas is over for another year and i must say i had a really enjoyable one this year.  Hope you did too.  Mind you, last christmas was pretty good for me too. 
I bought myself a mountain bike just before christmas and i went cycling through the Devonshire countryside on christmas day and thoroughly enjoyed myself.
We've not had any snow down here, just some black ice in places.

I can now go back to doing some regular cycling which i've missed these past 2 years.

It's not something i've posted alot about before, but i've probably done as much cycling in my life as i have coding.  And thats alot.
I've logged alot of miles over years and gotten through quite a number of bikes.
It's something i do for fitness and for the enjoyment of being in the countryside.

Looking back, 2 years have passed since i was last able to do any regular cycling.  How time flies.



On the programming front.

I did some coding christmas day and completed the file management system for my enemies animations editor.

As with my main editor file management system i can browse and audit folders, create, rename and delete folders and files.

I also wrote the animation load and save routines too but havn't fully tested them yet.

As well as that i wrote a file management system for background template images.
This option allows me to display a background image on the screen, from a series of animations, which i can trace over to create animations.  Placing joints and images ect.

I also realised that the animations system is not strictly restricted to enemy animations but can be used for any type of animations.  Background scenery for instance.

Therefore the title of enemy animations editor seemed a bit unsuitable.

So after a bit of thought of decided to call all categories as "Actors" with animation sub categories.

So for instance i can have.

Human Wizard - Actor

With animations

run
walk
attack
defend
die
jump


or

swaying background tree - Actor

With animations

light sway in breeze
medium sway in breeze
severe sway in breeze

ect

Calling the categories Actors seems a much more sensible approach.


I've also coded an Actor image library section to the animations editor.
This sub section allows me to browse and select images that i want to use in the animations.
An image library allows me to select and load images that will only be needed for the level, instead of loading all of the images at once and thus causing out of memory or slow down issues.
These images are seperate from all other images in the game too.


I've still got alot of work to do to the Actors animation sub editor, alot of tweaking to make it a bit more user friendly.
There are some interface options i'm not too happy with, so i plan to create some test animations to get a better idea of how user friendly the interface is and make changes where necessary.

I also played around with making background trees and bushes images sway and distort as though blowing in the wind.
My background images sub editor has the option to distort any images based on sine waves and it gives pretty neat results for bushes and trees.  Sort of brings a bit of extra life to a level.



I also have a pretty clear idea of what i want to achieve next year coding wise once the Actor animations editor is complete.

Next year i will concentrate on getting enemies into the game.

There will be 4 different categories of enemy.

Ground based enemies.
Air based enemies.
Water based enemies.
Boss enemies.

All with the abilities to use ranged or mele attacks.

This will be a major update to the game and i know that the coding will be a quite large and lengthy process.

If i can get all the enemies code done next year i'll be happy.  Anything more will be a bonus.

I'll start on the ground based enemies first and modify that code for the others.

I don't want to write a single piece of code that will handle all enemies as it will add alot of complexity and increase the chances of bugs.  Would probably also mean that each enemy would have alot of redundant data associated with it too, depending on it's type.
I want to keep the code as simpe and bug free as possible.


I've also called my game engine 'The Genesis Game Engine".  As all pro developers seem to call their engines by some fancy name.  Thought i'd do the same. 

TMC






Screenshots

This screenshot shows how big the project is getting now.
I'm up to 51 source file includes now for the whole game and editor.  Some of the sub edtiors are pretty long listings.


This screenshot shows the Actor animation editor with a default human run background template image.  The template image is a motion captured biped sequence from 3ds max.

[T_M_C]

This screenshot shows joint placement and linkage over the background template image.

And this screenshot shows the final skeleton.
Images are yet to placed on the joints.
But you get the general idea.


TMC

[fog]

Well I've got no idea how I missed this as I check all new posts every visit 

That skeleton editor looks superb.  I so want something like that in my code library one day.

What's your plan for storing the actual animations then?  Are you planning on positioning every limb and joint for every frame manually or are you just storing key frames and interpolating between them in code?

I can't wait to see it in action now.

[T_M_C]

Well I've got no idea how I missed this as I check all new posts every visit

lol.   

What's your plan for storing the actual animations then?  Are you planning on positioning every limb and joint for every frame manually or are you just storing key frames and interpolating between them in code?

Yeh, it's a very simple process.

I position all joints for each frame manualy.

Although when a joint is created, it's initial position gets copied into all frames.

I then go through each frame and reposition / align the joint to where i want it.  I can also rotate the joint and it's linked children around others and move multiple joints that are linked.

Joints can be linked or de linked at will.
But de linking rarely seems necessary.

Each joint has an image associated with it. 
This image also has position, rotation, scale, color and alpha attributes too.
This is also on a per frame basis.
So i can also animate the joint image over several frames for added flexibility.

As well as that, i have options for color cycling each image and sine wave distortions too.

It's a remarkably easy process to place joints by tracing over a background image.

I've got a really smooth 60 frames running skeleton animation so far.  Traced over a motion captured 3ds max sequence.

I'll upload a small video some time of the completed animation.   


Tracing over  a background image is the easy option so far. 
I suspect animation creation to get more tricky when i come to do freehand stuff.

But i'm really pleased with the results so far.  Very promising.

The beauty of this system is that, once the animation / skeleton is created, i can use that animation data for an unlimited number of different creatures, just by changing the displayed image.

TMC

[JDog053]

Thats a really nice system you've got there! Thats also something i'd love to do myself 1 of these days!

[fog]

Any idea how you will be handling background/level collisions Masked?  It's not too bad checking for collisions with floors and walls when each object is a single sprite, but make them out of several and it's a whole different challenge.  I'm assuming you'll need some kind of system whereby you can assign different collision checks to different limbs so you only check feet against floors, torso against walls etc?

I'm getting the shakes just thinking about it lol  

[T_M_C]

Thats a really nice system you've got there! Thats also something i'd love to do myself 1 of these days!

   

Any idea how you will be handling background/level collisions Masked?  It's not too bad checking for collisions with floors and walls when each object is a single sprite, but make them out of several and it's a whole different challenge.  I'm assuming you'll need some kind of system whereby you can assign different collision checks to different limbs so you only check feet against floors, torso against walls etc?

I'm getting the shakes just thinking about it lol 

Well, for movement, i plan on using paths to follow for ground based enemies and movement via ai, whereby i don't need to do any ground collision checks or physics related stuff.
Flying enemies will be constrained to an area of flight and movement via ai and the same system for water based enemies.

For Player to Enemy collision i'll probably use a series of distance checks for each frame of the enemies animation.  Checking only the current frame of course.
With my animation editor, i'll add an option to define collision areas for each frame, circles of varying sizes to cover the animation frame and it's these distance checks i plan to use for all collisions with that enemy frame.

The only other area i can think of at the moment where enemies will need collision, is against doors and blockages.

But there wll probably be others as time goes by.

Thats the plan for the moment, but it may well change to something completely different as time goes by.   

TMC

[T_M_C]

Update
----------

Work on my animations sub editor has ground to a halt.
All is going well, but i'm getting really bored with it and not motivated to continue work at present.
Next thing to add to the sub editor are verlet constraints to keep all the joints attached to each other.
But this is just for the editor and i doubt it will get used in game.



I have been quite busy coding other things though.


I used to play a really cool overhead tank game in the arcades.  Can't remember the name of it, but i've always thought i'd like to write a version of it myself.
The game used two joysticks, one for each track, a bit like battlezone and was sprite based and viewed from overhead.
The real novel thing about this game though, was that the entire play area / screen rotated around the player.  So, the player always pointed up towards the top of the screen.
I remember being really impressed by it at the time.

Well, just for something to do, i decided to modify my current editor code to use the same rotational system.  The code was pretty simple, just a few lines of trig strategically placed and i also knocked up some twin joystick code for the controls.  Each stick per tank track.
I then loaded in a vehicle graphic as my main sprite and promptly went driving about my forrest level as a test.
I'm delighted to say that the system works really well and it was quite fun to play.  So, a similar tank game is very doable.  Whether i'll ever get around to writing one is another thing though.




For along time now i've wanted to write a scrolling shoot em up and i've been meaning to tackle coding splines ( curve paths ) for enemy attack patterns for a long time too.

A demo of the PC port of Armalyte ( the c64 side scrolling shoot em up ) has recently been released http://www.ovine.net/ and this renewed my interest in writing a scrolling shoot em up.
Although i found the demo a little disapointing.  I find it more difficult than it should be.  No mouse support either.
Looks and sounds great though and is a very faithful recreation of one of my all time favourite c64 shooters.


Well the past few days i've been tinkering away trying out different spline methods.

Drawing splines is fairly easy.  The difficult bit is moving along them at a constant speed.

This sounds easy enough, but incrementing along a spline at a constant step value causes speed ups and slow downs depending on the severity of the curve.

I know there are several solutions to this problem and i found some neat code in the blitz archives for moving at a constant speed along a Bezier spline.
I ported the code across to my system, rewrote and modified alot of it and made it alot more flexible for my needs.
Created a mini editor for it.  Clicking and dragging control points around to create different curves.

After some study i came to the conclusion that cubic Bezier splines ( which is what i was using ) don't really give the kind of curves i'm after for smooth enemy patterns in a shoot em up.
The curves themselves seem to have alot of straight edges ( needed to link up the curves ) and what i want are lots of smooth bendy curves so the enemies can swirl about the screen in lovely formations.


So, i decided to do some more research to see what other spline types would be more suitable.

I found a really neat article on this problem at shmup-dev.com, which i downloaded ages ago and decided to try that technique.

This time the splines use the Catmull Rom algorithm.  And coding was easier using these.

The curves are much more like the type of thing i was after and it was relatively easy to get a simple editor up and running to try out various shapes.

The Catmull Rom algorithm still has the inconsistant speed issues but i was able to decifer enough of the Bezier code to realise what the author was doing and i found the equivelant equations within the shmup-dev.com article.

This involved finding the differential of the spline segment ( speed of the curve at a given a point along it ) and using that to scale the current speed that my graphic traverses the spline.

It sounds far more complicated than it actually was.

So i was delighted to find an elegant solution to a problem i'd been thinking about for a long time.

The shmup-dev.com article puts forward another solution to the inconsistant speed issues which involve a quite convoluted system of breaking the spline segments down into small straight lines and storing these in look up tables.
And using a lookup comparison test to find the relevent speed.

Looks like i've managed to sidestep that complicated method via just a few lines of code.  Which i'm very pleased about.

Now, i've overcome a major hurdle for a scrolling shoot em up and in fact i'm sure the techniques and code will be useful for alot of other future projects.  Smooth camera movement along splines being one further example.


So I've upoaded 2 spline demo's for anyone to try out.
Bezier spline and Catmull Rom spline demo's.
The demo's contain on screen instructions.

http://www.themaskedcoder.dreamhosters.com/TMC Splines Demo.zip

And a screeny of one of them.

TMC

[JDog053]

Thats a very comprehensive report, and I thought I was busy! Looks very cool from the screenies and i'll be downloading that in no time.

Funny you should say about a Tank based scrolling shoot-em-up as i've been thinking about doing 1 myself but coming up with a decent control scheme (its alot different to yours) and I'd never thought of doing it with twin sticks per track, is the turret fixed or rotateable? The scheme I came up with was either right trigger for accelaration and the left stick to select orientation/pivot and the other stick to aim and auto fire the gun.

I'll be following this closely!

[T_M_C]

Funny you should say about a Tank based scrolling shoot-em-up as i've been thinking about doing 1 myself but coming up with a decent control scheme (its alot different to yours) and I'd never thought of doing it with twin sticks per track, is the turret fixed or rotateable? The scheme I came up with was either right trigger for accelaration and the left stick to select orientation/pivot and the other stick to aim and auto fire the gun.

No, the aiming in the original arcade game was in the direction your tank faced.  As far as i can remember.  The turret didn't move.

In fact, in my little tank demo, i had 2 control modes.

Mode 1 was stick per track movement mode.
Mode 2 kicked in when you pressed fire, and this put the tank into strafe mode.  Where no rotation was possible, but instead, you could move forwards / backwards and from side to side.  In whatever direction you happened to face in.

So, mode 1 was for exploration and mode 2 was for attacking stuff.

It all worked really well.  And deserves to be made into a game at some stage.  

I'd love to see you write a tank game too Jdog.  Would make a nice change from spaceships.  

In fact, i think i'll knock up a little runabout demo for you to try.  Should be fun.   

TMC

[fog]

The real novel thing about this game though, was that the entire play area / screen rotated around the player.  So, the player always pointed up towards the top of the screen.
I remember being really impressed by it at the time.

There's code in E+ for a mode where everything revolves around the player.  It looks great, but there's so much stuff on screen that to have it also rotating around the player is really disorientating so it's currently inaccessible to the player. I can certainly see how it would be cool in a tank game with slightly less enemies on screen.

I'll have a play with your spline editor tonight.  I think splines are one of those things that all devs play around with at some point because they look pretty cool.

I'd love to see you write a tank game too Jdog.  Would make a nice change from spaceships.  

That's very true.  It's strange how tanks, planes  and soldiers from the likes of 1942, Silkworm, Commando etc have gone out of fashion and everything now in generic spaceships or abstract neon. Me == guilty.

[JDog053]

Cool ... well say no more! Consider the idea considered. Since I have the control scheme it would make sense to put it to some use!

And yeah, splines are cool, its just XNA wants us to use as little of them as possible!

[T_M_C]

Well i had some fun yesterday creating a level for my tank to wander around.
Spent a couple of hours on it.
And created a demo too for you to try out.

Link and screeny below.  10mb.

http://www.themaskedcoder.dreamhosters.com/TMC Tank Demo.zip

Theres no collision or sound in there, just roam about and try out the controls.  

Also, i seem to remember in the arcade game, you could roll your tank left and right and even sort of fly into the sky when you enter some sort of portal.

I might try and see if i can find a screenshot of it.  Just for old times sake.  

There's code in E+ for a mode where everything revolves around the player.  It looks great, but there's so much stuff on screen that to have it also rotating around the player is really disorientating so it's currently inaccessible to the player. I can certainly see how it would be cool in a tank game with slightly less enemies on screen.

Cool.  Yeh, my autocross racing had the option too as one of the camera modes.  But like you, i also find it very disorientating.  I always play it with a fixed camera, but with auto zoom height. That feels much more natural to me.
But i think the rotational camera system for a tank game suits it pretty well.  Adds an extra challenge for the player.
Add in an onscreen radar and map and you have a pretty neat control system.

I'll have a play with your spline editor tonight.  I think splines are one of those things that all devs play around with at some point because they look pretty cool.

Cool, i've currently started a shoot em up editor.  using my background level editor and a few other library routines.
I'm currently implementing a camera follow spline sub editor.  
Once thats all working well i can use similar code for enemy attack patterns.

And yeah, splines are cool, its just XNA wants us to use as little of them as possible!

lol.  

TMC


Footnote.

I found the arcade game i was talking about.

Called 'Assault' by Namco.

http://www.coinop.org/g.aspx/100437/Assault.html

Brings back fond memories.

Top game.