The Binary Zoo Bog

[fog]

Well those proper entity trails are in and although I just used some place-holder graphics they look better than I expected.  The trails themselves are made of entity objects so I can do everything with them that I can with any other game object.  I doubt I'll ever need my trails to fire weapons  but it does make colour cycling and alpha fading them as easy as setting a flag.

My original intention of creating a new trail line every frame turned out to be complete overkill.  In the end I decided to check how far the parent entity has moved and only create a new trail line when it has moved a certain distance.  Currently this is 25 pix which cuts down on the number of sprites needed to draw the trails while still making super smooth looking curves.

And as they are Entities they are already plugged into my LOD system so can automatically be switched off on certain platforms if they hit performance too much.

[T_M_C]

Sounds like a nice system.

Are you still going ahead with your space invaders game ?

TMC

[fog]

Are you still going ahead with your space invaders game ?

Certainly for testing purposes yes.  As it's a very basic game I'll have to see how playable it ends up before I decide what to do with it after that.


A little more progress last night.  I've added "Dummy" to my available Entity types.  As my different entity types all share the same code a Dummy entity has all my logic and behaviour options available, it just doesn't display any sprite image (ie. it's not visible on screen). 

When I started thinking about it, there are a bunch of useful uses for an invisible entity.  The first one I tested last night was to have the players gun fire Dummy entities that had one of my new Trail objects attached.  On screen all you see are the trails coming from the players gun and if I switch the collision detection flag on then I have instant beam weapons.  And because the parent Dummy object can have steering behaviour that the Trails will follow I can have bendy beam weapons.  Not sure there's much call for those, but it's an option 

[T_M_C]

When I started thinking about it, there are a bunch of useful uses for an invisible entity.  The first one I tested last night was to have the players gun fire Dummy entities that had one of my new Trail objects attached.  On screen all you see are the trails coming from the players gun and if I switch the collision detection flag on then I have instant beam weapons.  And because the parent Dummy object can have steering behaviour that the Trails will follow I can have bendy beam weapons.  Not sure there's much call for those, but it's an option

Now thats really cool.   

TMC

[fog]

 

I must admit designing the engine so that every game object uses the same code has thrown up a lot of interesting possibilities that I hadn't thought of.  Of course I'll be claiming it's all by design at a later date. 


Next up Waypoints.  I've never needed them in the past for obvious reasons ( all my enemies are dumb bouncy blobs © ) and I don't need anything complicated here.  A simple list of co-ords and different modes of moving between them should suffice.

[fog]

I've decided to do my Waypoint code in a slightly different way to what I originally envisaged.  I had planned on using fixed world co-ords, but now I'm using co-ords relative to each individual Entity.

So, as a very basic example.... Firstly I create a standard triangular waypoint path.....then I can have an  Entity flying free form not following any set path....then, at any point, assign the triangular waypoint path to it and it will smoothly transition into following that path (the waypoints are repositioned and rotated to match the Entities current position and rotation).

Additionally I can scale the paths so, in theory, I can create a bunch of standard path shapes and just scale those to match my requirements.

I've no idea if that's how it's normally done....it's just a system that suits my needs. 

Hmm.  Knocking up this example diagram makes me thing a mirror option is a good idea too.

[T_M_C]

That looks cool.

The free flight aspects adds a lot of unpredictability and the paths gives the player something to recognize.

Do you have a specific game type you're thinking of where this is most suitable.

Scrolling shooter perhaps ?

TMC

[fog]

Thanks

The free flight aspects adds a lot of unpredictability and the paths gives the player something to recognize.

Yeah it's just another option.  It can transition from free flight to a fixed waypoint path, from one waypoint path straight into a different one, or just keep looping around the same path.  I have a couple of other waypath mode too.  Choices

Do you have a specific game type you're thinking of where this is most suitable.

Scrolling shooter perhaps ?

Yes it's certainly something I'll be needing for a few future projects I have which would be vertical scrollers.
 
More immediately though 1982 is full of enemy styles from the early 80's so this would be perfect for getting proper Galaxian style swooping enemies in there among others. (they currently fly using random looping patterns)

And the next version of mono would have (currently) 10 different themed levels each with different enemy types.  So for example in the "square" level the backgound would be filled in using square blobs, the background distortions would be based on squares & the enemies would move using square waypoint paths.  At least that's my current way of thinking. 

[T_M_C]

So for example in the "square" level the backgound would be filled in using square blobs, the background distortions would be based on squares & the enemies would move using square waypoint paths.  At least that's my current way of thinking.

I'm liking your thinking here.

Sounds a pretty flexible system.

Any plans to release 1982 as it is ?

TMC

[fog]

Any plans to release 1982 as it is ?

Not "as is" because it's in XNA and I haven't got the necessary PC bits in.  I'll port the games scripts to my new AGK engine when it's done.


Anyway they waypoint code is finished.  They can be repositioned, scaled, rotated, mirrored etc and it all seems to work quite nicely.

Each one can also have a tolerance set which governs how close an entity must get to a waypoint before moving on to the next one.  Below is the same waypoint data with different tolerances applied with one path much more rounded than the other.

One of the other unforeseen uses for my new Trails code is that I can switch them on to see the exact path the Entity takes.  Nice for debugging.

[JDog053]

Looking good fog!

[T_M_C]

Thumbs up from me.

TMC

[fog]

Thanks.

Well now all I need is some proper enemy wave creation routines and an editor of some kind to design them.  Using the good old Paint method would be ideal here as I'm just doing basic Space Invader style layouts, but AGK has no way of reading in that data.

I could write a quick prog in DBPro to convert that image data into a format AGK can read, but the right thing to do is to write a very quick editor in AGK which allows me to build attack waves within the game.....and I know I'll need a similar editor for at least one project I already have planned.

And while I'm at it I might as well write some nice routines for triggering enemy attack waves which I can also reuse in future. 

[T_M_C]

Yeh, writing an editor will be worth it in the long run.

Apart from allowing you to be more creative, it's a lot less hassle.

TMC

[fog]

Well I got the basic GUI elements for the editor in place.  For this project it's about as basic as editors can get as all I need to do is layout different arrangements of Space Invaders and be able to save the results.

The editor itself is built into the main game loop so I should be able to pause the game and drop in and out of the editor as required.

This editor is really game specific, but eventually I plan on adding editors for some elements common to all games (emitters, sound fx etc) which can be used on future projects.  There are so few different weapons etc needed for this project that I'm not going to bother with those other editors just yet.