TMC's Shoot Em Up Dev Diary

[fog]

Yesterday i added some player bullet patterns to player 1.

See screenshots.

Some extra forward spread streams, 2 forward curve streams, a rear stream and 2 side streams.

Nice   I do like designing bullet streams even if half the ones I come up with are totally inappropriate.  I'll svae those for the next mono. 

I'll copy the code over for the other players too, but i expect i'll reduce the available streams for multiplayer mode.  Partly to increase game performace and also for game balancing.

Yeah if I was designing for multiplayer then reducing some of the bullet streams would be how I would tackle it.  Leaving the forward facing weapon as in the single player game means you need to make minimal changes elsewhere.


And yay Goldwave

[JDog053]

wow, just saw this now! been a busy weekend, looks amazing!

[T_M_C]

Update
----------

I've had quite a productive weekend.

Over the weekend i added player bullets to the three remaining players.

Along with that i decided to add some motion blur code to the bulets too.  Again with, off, low, medium, high, and max settings

And i'm quite pleased with the results.


I also had an idea for quick landscape collision checks which involves just checking for a certain pixel color under each bullet or ship.  I reserved color rgb 1,0,0 as the color to test for ( which is virtualy black ) and filled in my landscape borders with this color.
And knocked up some small code to test for this one pixel.

The system works really well and is an elegant solution.  Unfortunately though, it does have an fps hit for all bullets ( i just tested for one player, let alone the other players ) so it's not really a pratical solution..

It involves grabbing a pixmap image of the frontbuffer under the sprite i want to check for, which is just 1 pixel in size.

I knew grabbing pixmaps was slow, i didn't realise it was this slow though.


I think now i'll make a start on the background collisions editor and i plan to use circles overlayed on the landscape to define distance checks for each player and bullet.
I don't think theres any need to do polygon or line tests in this game as i did for my platformer.

I'll also probably partition the level to enable quick access to the circles.  Testing only those circles within screen range and not all of them on the level.


I've also added some volume controls for the game too, since i now have limited sfx.  Player shoot and power up and power down weapons sfx.

I've also been messing around trying out different background graphics.  I'm not really happy with the way the game looks at the moment.  It's ok, and maybe with enemies on screen and more action it will become less of an issue.  But at the moment i'm looking at a static level scrolling past and all i see is the background graphics which looks a bit empty.

Still experimenting with the background graphics.

TMC

[fog]

Hmm.  I used to read these dev blog updates over lunch at work, however this site is now blocked because it features "games".  Arse. 

I also had an idea for quick landscape collision checks which involves just checking for a certain pixel color under each bullet or ship.  I reserved color rgb 1,0,0 as the color to test for ( which is virtualy black ) and filled in my landscape borders with this color.
And knocked up some small code to test for this one pixel.

The system works really well and is an elegant solution.  Unfortunately though, it does have an fps hit for all bullets ( i just tested for one player, let alone the other players ) so it's not really a pratical solution..

It involves grabbing a pixmap image of the frontbuffer under the sprite i want to check for, which is just 1 pixel in size.

I knew grabbing pixmaps was slow, i didn't realise it was this slow though.

It's kinda ironic that background colour collisions used to almost be the standard collision system for old games and now, with infinitely more processing power, it could be too slow a method.

I've also been messing around trying out different background graphics.  I'm not really happy with the way the game looks at the moment.  It's ok, and maybe with enemies on screen and more action it will become less of an issue.  But at the moment i'm looking at a static level scrolling past and all i see is the background graphics which looks a bit empty.

Still experimenting with the background graphics.

As a big fan of parallax scrolling I wonder if that could be made to work with a multi direction scrolling level?  Also maybe if you restricted drawing the background starfield (or other objects) to just the internal tunnels thus leaving the walls completely black it might look quite cool?

[T_M_C]

Hmm.  I used to read these dev blog updates over lunch at work, however this site is now blocked because it features "games".  Arse.

 

Try Ultrasurf http://www.ultrareach.com/ for proxy surfing.  I use it alot on the library computers to get around the firewalls.

It's a tiny programme.  400k ish.

It's kinda ironic that background colour collisions used to almost be the standard collision system for old games and now, with infinitely more processing power, it could be too slow a method.

Yeh thats a good point.  Funny how thing turn out.  

As a big fan of parallax scrolling I wonder if that could be made to work with a multi direction scrolling level?  Also maybe if you restricted drawing the background starfield (or other objects) to just the internal tunnels thus leaving the walls completely black it might look quite cool?

Yeh, i have thought of that and in fact i did block out the outside edges of the tunnels ( making them solid ) only allowing the tunnels themselves to be visible.  And i wasn't that keen on the look.  If i was able to texture the solid walls it would look alot better, but i havn't figured a decent way to do that yet, graphicaly.

I'll keep trying lots of different techniques and hopefully find something that looks cool.


Update
----------

Yesterday i managed to get alot of coding done.

I completed the background collisions sub editor.

This sub editor allows me to scroll around the level and place circles of varying sizes over parts of the level i want to cause a background collision.

I ran a stress test of over 1000 circles on the level and it kept a steady 60 fps through out.  I've allowed up to 10,000 circles per level though.  Should be plenty.  

However, drawing the circles with the blitz line commands ( my own drawcircle routine ) causes an fps drop down to 2.  

So, i have an option to toggle drawing those on or off.

I also drew a hi res plain circle in paintshop pro and draw and scale that over the level circles.  Thus having solid and outline circles to view.

The level drawn with 1000 circle images runs at a nice 60 fps, but the outline circles drop to 2.

But i have the options to show either one.

The solid circles allow me to view a solid filled in area of the level and the outline circles show the distance check circles.

I also added the option to show the camera path spline in the level too, to help gauge circle placement.

Today i'll make a start on the spatial partition system for the circles.

TMC

[fog]

Hmm.  I used to read these dev blog updates over lunch at work, however this site is now blocked because it features "games".  Arse.

 

Try Ultrasurf http://www.ultrareach.com/ for proxy surfing.  I use it alot on the library computers to get around the firewalls.

It's a tiny programme.  400k ish.

Thanks but we can't install anything   TBH I could get around it with a proxy site, it's just not something I'd risk doing at work.  Even though the block on gaming sites wasn't really intended for places like this I'm sure they wouldn't react too well to me bypassing it.

I ran a stress test of over 1000 circles on the level and it kept a steady 60 fps through out.  I've allowed up to 10,000 circles per level though.  Should be plenty.   

What did that test involve then?  Just drawing the circles or testing for collisions against a shit load (technical term) of bullets and enemies?

[JDog053]

I have to say TMC, your drive of progress between each update is proving just the thing i need to make my project more interesting (almost like a mini competition) its been alot of fun coding, and when someone else is going through (near enough) the exact same experience as yourself at the same time is a great confidence booster!

Another great update, keep 'em coming....

Anything happening with 1982 Fog?

[T_M_C]

Thanks but we can't install anything   TBH I could get around it with a proxy site, it's just not something I'd risk doing at work.  Even though the block on gaming sites wasn't really intended for places like this I'm sure they wouldn't react too well to me bypassing it.

Thats fair enough.  Although i would point out that Ultrasurf doesn't need installing.  It's just a small exe to run.

Incidentally there is a new search engine available at http://www.startpage.com/ which is soon to have proxy surfing enabled by default.  So, any page that you load through the search engine is via a proxy.

What did that test involve then?  Just drawing the circles or testing for collisions against a shit load (technical term) of bullets and enemies?

Just a drawing stress test.  

I have to say TMC, your drive of progress between each update is proving just the thing i need to make my project more interesting (almost like a mini competition) its been alot of fun coding, and when someone else is going through (near enough) the exact same experience as yourself at the same time is a great confidence booster!

Thats great news Jdog.

Whatever motivates you to code can't be a bad thing.  


Update
----------

Made a start on the spatial partitioning system for the background collision circles yesterday.

Coding is going well.

Heres a brief description of the system i'm implementing.

Since my level can hold a theoretical maximum of 10,000 collision circles, it's going to be prey impratical and downright uber slow to check every bullet, enemy and player with every collision circle each frame.

So, the solution is to only test those circles that are onscreen or partially intersect with it.

To do this, i first create the level with all the background circles in place, aligned to the background scenery and scaled to suit.

Then i mathematically divide up my game world into a square grid of equal sized segments.  I'm using 1000 x 1000 pixel / units per segment.

Each segment has an array with it, to hold the indexes of every collision circle that intersects it.  This is not at runtime but all precalculated.

Then at runtime, all i need to do, is caluclate the segment the player is on ( in fact camera position ), select the surrounding 8 segments, making a total of 9, and testing each circle within that segments array to see if it intersects the screen.

Any circle from a tested segment array that does intersect the screen gets stored into a final master array of circles ( taking care not to store copies of the same circle into the master array ), which will get tested against every player, player bullet and probably enemies too.

This should drastically speed up the process of collsiion testing, by first pre calculating which circles reside on what part of the level, via which segment it intersects and then finding out which circles intersect the screen.

I'm about halfway through the process at the moment.

TMC

[T_M_C]

Update
----------

I've got the spatial partition grid calculated now.  And so far with half a test level of 400 circles it's pretty quick to calculate.
This is the pre calculated arrays for each segment.
And i'll probably calculate it each time the user enters play game mode or after a level has loaded.  I don't see any need to save and load the data when it doesn't take that long to calculate.

I also managed to speed up the line drawing circles by testing to see if they intersect the screen first.  Thus ignoring any too far away to be drawn.
It gives back about 30 fps for the editor.  So was well worth doing.
I've made drawing them a toggable option too.
The line drawn circles are only for the editor and not relevent to playing the game.

Incidentally, the circle to screen intersection test is done simply by creating a circle around the screen and performing a circle to circle distance check on both.  I use the screens x size as the diameter for the screens bounding circle.  The x horizontal axis being the largest.

Ive also written some small code to test the entire level of circles with the first bullet stream for player 1 which allows me to test the collision circle placements.
And it all seems to work really well, at a constant 60 fps.  And thats without any spatial partitioning code running.

See attached screenshots of the collision editor.

I also finaly modified some code i'd been putting off for ages that allows for different screen resolutions.
Now the game supports any supported screen res from 1024 x 768 up to widescreen 1680 x 1050.
Although I'll be designing levels that fit correctly at 1024 x 768, any higher screen resolutions will simply show more of the level.

Next to code are the runtime calculations that test each segment surrounding the camera for circles that intersect the screen.


I also had the idea of creating my own Game Name Generator.
Again i'm stuck for a name for my shoot em up.
So, i think i'll create a name generator to help with choosing one.
I'll probably use a database of names and words that sound cool and randomize varying sequences and see what it spits out.
It will simply be a case of jotting down any names i come across and think are cool, and adding them to the database.
I imagine building up the database over several years will provide plenty of suitable names.



Away from coding, i took myself off to the cinema yesterday to watch the much hyped film Avatar.

And what an Excelent film it was too.  If you havn't seen it yet, i highly reccomend it.

Although i didn't get to watch it in 3d, the visuals and effects for it are simply stunning.  Jaw dropping in places.

The planet Pandora often reminded me of when i used to play World Of Warcraft and that set me thinking, I wonder if the films look was inspired by the game in any way.  I wouldn't be suprised if it was.  Very similar in places.

The only negative things i have to say about the film are that it does contain alot of Cliche's, pretty predictable stuff.  But these are minor gripes in what i thought was an excellent movie.


TMC

[fog]

Those editor screenies are cool.  When they are thumbnails they look totally black and white and it's a real nice effect (logs image in memory for future reference)

Incidentally, the circle to screen intersection test is done simply by creating a circle around the screen and performing a circle to circle distance check on both.  I use the screens x size as the diameter for the screens bounding circle.  The x horizontal axis being the largest.

I may be misunderstandingh what you're doing here but is a circle to circle distance check really necessary and the best method?  Why can you not just see whether the circle intersects the screen rectangle?  I'm sure I'm missing something.

I also had the idea of creating my own Game Name Generator.
Again i'm stuck for a name for my shoot em up.
So, i think i'll create a name generator to help with choosing one.
I'll probably use a database of names and words that sound cool and randomize varying sequences and see what it spits out.
It will simply be a case of jotting down any names i come across and think are cool, and adding them to the database.
I imagine building up the database over several years will provide plenty of suitable names.

There are a few of those around if you Google.  I just have a notepad file into which I write any interesting words I come across....then I stick a pin in the list

Away from coding, i took myself off to the cinema yesterday to watch the much hyped film Avatar.

I must admit I don't really fancy it from the clips I've seen, but I'm curious to see what all the hype is about.

[JDog053]

I've seen Avatar twice and it really is super predictable, the effects from Weta digital are spot on though. Film is sub par.

Yeah that does seem like alot of checks you're doing, but if it works, don't break it

[T_M_C]

Update
----------

Yesterday i finished off the spatial partition code.  And have all the bullet streams for all the players using it for background collision testing.

This gives the level a much more solid feeling now, being able to shoot at solid scenery.

All seems to run fine at 60 fps, even at 1680 x 1050 res.   And theres quite alot of bullets on screen with 4 players all maxed out.

The code was trickier than i thought and had me scratching my head several times.  But it was well worth the effort.
It gives a definate speed boost.

Next, i'd like to code some bullet explosion / richochets for when the bullets hit the scenery.
I would expect that to start hitting the fps rate though.  Especially for all players and bullets with motion blur.  But i'll have to wait and see.
The options will be toggable on / off of course.

I also spent some time creating a little Game Name Creator.
And routed through my game archives finding game names and including them in my name creator.

I've uploaded it here for anyone to try.  500k zip file.

http://www.themaskedcoder.dreamhosters.com/game name generator.zip

You can add, delete or modify the names within the text file, so you could create your own database if you wanted.

Just run the programme and press Space to start generating some Game Names.

The names are biased towards space and shoot em ups but you could include anything you wanted.

The programme just randomises name sequences.

Some of them come out quite cool and i've already found maybe 10 or more game names for my shoot em up.

Try it out and see what you think.


This morning i finished off placing collisions for the rest of my test level which brings the total to 1100 collision circles.
I ran the game with 4 players all maxed out with maximum bullets. 
The frame rate stays at about 60 fps for most of the level and dips to about 50 at certain points.
I then turned off all the motion blur for all bullets and the frame rate shot back up to  60 for the whole level.

The blur trails are lots of seperate bullet images drawn away from the original bullet and faded the further from the start bullet they were.

It looks like my motion blur trails for my player bullets are a bit of an fps bottle neck.

So, i've decided to remove the bullet blur code and simply design one large alpha faded bullet instead.
Why i didn't do this in the first place is beyond me.  A much simpler solution which gives me back alot of fps.


TMC

[T_M_C]

I may be misunderstandingh what you're doing here but is a circle to circle distance check really necessary and the best method?  Why can you not just see whether the circle intersects the screen rectangle?  I'm sure I'm missing something.

Yeh, thats exactly what i'm doing, using the circle to circle check.
My method uses a bounding circle around the screen so i can perform the distance check to any relevent circle. And is a rough approximation.

Trouble is, an exact  circle to rectangle collision involves alot more code and checks.  It's not simply a case of a point in poly test.  But nearest point on circle circumfrence to line.  4 lines making up the screen borders.

It's one of those problems that on the surface seems really easy.  Until you start looking into the algorithms and code necessary.
I first realised the difficulty with circle to line intersections when i wrote a snooker sim several years ago in 3d.  I do have the code for it, it's just slower than circle to circle checks.

My spatial partition system lets me only see the 9 relevent segemts around the camera, and the circles they contain.  Pre calculated.
Then those are whittled down to only those circles that intersect the screen.

I could have gone for a system similar to my platformer, using point in poly tests and line to line collision tests.  But that would be much slower code too.  Of course, line to line and polygon collision would provide greater accuracy but at the cost of slower code.  But then, my system is less accurate but faster, just so long as i keep the circle to segment count relatively low.

The whole point of using circles is to keep the speed up, by using simple distance checks.

The circle system is not one i've used before, so is new teritory to me.

But i've got the system working well now.

TMC

[fog]

I still think I'm missing something

The screen edges are always horizontal and vertical so you don't need to do a proper circle to line intersection test....it's just a simple distance check:

Code:

FUNCTION Circle_Intersects_Screen()
   IF Circle_Center_X < ( 0 - Circle_Rad ) THEN RETURN FALSE
   IF Circle_Center_X > ( Screen_Width + Circle_Rad ) THEN RETURN FALSE
   IF Circle_Center_Y < ( 0 - Circle_Rad ) THEN RETURN FALSE
   IF Circle_Center_Y > ( Screen_Height + Circle_Rad ) THEN RETURN FALSE
   RETURN TRUE
ENDFUNCTION

[T_M_C]

Oh right, yeh i see where you're comming from.  

You're right, in that the screen does not rotate.

My explanation above was for aabb ( arbitry aligned bounding box ), ie, if the screen edges were sloped.  Or any line for that matter.

However, your code could execute 4 checks at a worst case scenario, whereas my code requires just the one check.

However, my code uses a square root which is slow, so it's really splitting hairs as to which is faster.  Code wise.  Probably not much in it either way.

Granted though, your code does give more accuracy because my method uses extra space surrounding the screen by the bounding circle.

I might implement your method and see if it makes any difference.
If it provides any speed increase it will be worth implementing.

Thanks for the heads up.  

Two heads are always better than one.


Update
----------

I've decided to keep the bullet trail code after all.  And i've implemented a seperate graphics option for each player to choose the complexity of the trails independantly from the ships motion blur, which it was before.

So all users can tailor the graphics settings to suit the speed of their machines.

I've also been making some additional changes to various bits of code, tweaking things here and there.

I also spent a number of hours yesterday compiling a huge list of game names for my game name creator.  I have now over 3300 names in my database and have over 40 names set aside for this project.  And i have a few favourites in that list.  

I'm about to make a start on bullet richochets and explosions for when they hit the scenary.

Then it's on to the player to scenery collision checks.  I'll be using screenshake and particles and sfx when any player collides with the scenery.

TMC