-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|580|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> some help with a space shooter

Page : 1 2 Next 3
Posted : Thursday, 08 July 2010, 10:06
I'm writing a simple 2D overhead 360 degrees space shooter in blitz3d. The problem I'm having is that I don't know how to calculate the ship's 'roll' (I have a bunch of frames for each ship with an image for each direction and varying stages of roll). Can anyone help me out here?

Here's how the sprites are laid down (conveniently ripped from subspace aka continuum )

edit: in case it's useful, here's the player's update loop:

It seems to be working fine (aside from bullets sometimes not quite travelling the same direction as the ship is pointing), just need a way to add that roll effect
Posted : Thursday, 15 July 2010, 05:01
I tried two solutions that someone provided me with but I can't get them to work correctly. I'm weak with math so could anyone check these formulas for any errors?

First method I tried was using the inverse radius of a cricle:

I found it in the blitz code database Results were odd though.

Next I tried getting the sinus of the angle of a triangle

my own making so may be erroneous.

here's the code to log the three coordinates I need for the formula:

Executed each cycle. Maybe that's too fast so the points are too close to each other? Might not be good for floating point inaccuracy?
Also, I think I still need a way to detect a left or right roll with these formulas.

On an unrelated note, is there any need to use a rectsoverlap() check before imagescollide() or does imagescollide do it's own bounding box check first?
Posted : Thursday, 15 July 2010, 13:51
Funny thing, I have all of Jeff Petersen's notes on his engines (the guy who made Continuum) but sadly, i'm not on my main PC Give me a while and i'll update you.

I'm thinking that if it's anything like his other games, it's simply stepped through by a simple algorithm that corresponds with the frames through simple multiplication. I remember having to do the same for my Infantry project (another one of his games) and it being like that.

Like said, give me a bit and i'll dig up those notes...

I am Busy Mongoose - My Website

Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb

Current Project: Pyroxene
Posted : Thursday, 15 July 2010, 17:08
Hey that's be awesome! You had anything to do with infantry? Or did you try programming your own version? Subspace kept the upright frames and the rolling frames in seperate images (the rolling effect could be disabled), I just added them together since I thought it'd be easier that way. Anyway it'd be nice to have information on how the original did things!
Posted : Thursday, 15 July 2010, 22:25
I was an early tester that came from the whole SubSpace crowd, and contributed some media over the years to the Harmless Games team... now a few players and myself are working on a newer client / server suite with things such as bots and heavier scripting capabilities.

Anyways, I haven't played too much with SS/Con, what was the exact original media so i can kind of match it up to what i know -- You said you merged all of them into one file?

I am Busy Mongoose - My Website

Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb

Current Project: Pyroxene
Posted : Friday, 16 July 2010, 05:39
Yes, subspace has one image file with all ships lumped together, but only the 'upright' image frames (no roll), like this:

Then it has one image file for each ship (so 8 files in total) containing the rolling frames, just like the one I attached to the first post, except I added the upright frames to the center of that image, the idea being that I'd have a roll variable which would become negative for a roll in one direction and positive for a roll on the other direction (0 for upright). But the original files do not have the upright position in there.
Posted : Friday, 16 July 2010, 06:16
Here's a quick idea until i work it out.

You have 40 frames per angle/roll, and 5 roll sectors to left and right with one neutral in the middle. Dead center facing up is frame 200, so naturally -1 (Roll to Left) and +1 (roll to right) will fall at 200-40 (160) and 200+40 (240).

Like said, sadly i'm not on my normal workstation and can only kludge together this quick code for blitz3D to display this idea. Mind you that the end frame is Starting frame +39 (since frame 0 is still technically a frame!), and within your game, you may want to round frames by angle to get the true frame you should be rendering - which off the top of my head, 360 / 40 = 9 steps between each frame.

I am Busy Mongoose - My Website

Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb

Current Project: Pyroxene
Posted : Friday, 16 July 2010, 07:33
Thanks but I already got that far: I originally checked if the player was both thrusting and turning at the same time, if true I would add/substract from a roll var which I capped at 5/-5. Then I'd display the ship like this:

This works fine but if the player is still moving due to inertia and then turns his ship and only after turning starts thrusting again the ship will change direction without rolling. It's a minor issue now I look at it again, but in subspace it's done differently (the ship rolls even in the above mentioned case) and I'd like to emulate it as close as possible
Posted : Friday, 16 July 2010, 08:28
I always thought in Subspace, when you turned it simply banked to whatever direction they were turning then slowly faded back to neutral. I'm trying to wrap my head around what you mean about it not banking after thrusting out of an inertial drift (right? is that what you meant?) that it doesn't bank..

So are you trying to only make it bank only when thrusting and turning? Bank only in inertial drift? Again, sorry for lack of further help and stumbling about, been on bare-minimal amount of sleep lately D:

I am Busy Mongoose - My Website

Dev PC: AMD 8150-FX, 16gb Ram, GeForce GTX 680 2gb

Current Project: Pyroxene
Posted : Friday, 16 July 2010, 09:13
No, the ship only banks when the ship's vector changes, turning in place does not bank the ship. The code you provided would bank the ship when turning even when the ship's not moving. The effect I was trying to describe is when a player thrusts his ship forward, releases the thrust key - the ship continues to travel in the same direction and at the same speed due to frictionless physics - then the player would turn the ship without applying thrust. At this point the ship should not bank as it hasn't changed the actual direction it's traveling yet. Only when the player then applies thrust again, after turning the ship, should the ship bank. This is how it happens in the latest continuum client at least. The code I devised at first did not bank the ship unless the player was holding down both a turning key and a thrusting key. The two 'solutions' I attempted in my second post don't work properly.
Sorry if it's a bit confusing, I don't know how to describe it any better.
Posted : Friday, 30 July 2010, 18:49
I could use some help making the AI ships 'lead' their shots. I have the following setup:
first we get the distance between the player and the AI

then we calculate the time needed for the projectile to cover that distance

and then we calculate the target x&y pos based on the player's current x&y speed and angle:

The accuracy is appalling though. Feels like there is something inherently wrong with this code... Another problem is that it does not take into account the velocity of the AI spaceship, which is added to that of the bullet.

Posted : Tuesday, 03 August 2010, 21:16
Hey j\'ordos

Ship roll

Here's a little program I baked for ya, which I hope mimics your desired ship roll behavior, from having read your elaborate explanations

Ship roll 1.BB: Use cursor left/right to rotate and cursor up to thrust (Esc to quit).

From what I understood, you're looking for:
RollPosition = RotationVelocity * ThrustVelocity

I've marked the most relevant bits in the code with {@@} so you can easily locate the juicy parts

Target intercept

Well, I've made another program for ya, which demonstrates 'artificial intelligence' firing at the player ship with prediction/interception.
It uses a math algorithm (which I don't understand ) from the BlitzCoder-era.

As a side-note, I've altered the ship roll behavior in the second program to be a bit more natural in my opinion

Also here I've marked the most relevant bits with {@@}.

Ship roll 2 & intercept.BB: Use cursor left/right to rotate and cursor up to thrust (Esc to quit).

The InterceptAngle function (see below) has support for both source and target velocities, which is what I think you were after.

Include files

Both programs use a separate math 'library' file and an input definition file, for my own convenience

Most stuff is fairly well commented/documented, but if you're ever in the dark, lemme know

Math.Lib.BB: Collection of math functions and definitions.

Input.Def.BB: Collection of input (keyboard, mouse) definitions.

I've added another bunch of these in the Code Snippets section of this website.


I remember that some time ago I've read on the BlitzBasic forums that ImagesOverlap gets called inside BlitzBasic's own ImagesCollide function.
But I don't know if this has changed in any new releases, since there were some fixes related to the ImagesCollide function.

Personally I've always experienced the wrapping of the higher precision functions (including ImagesCollide) as extremely beneficial/reliable

Posted : Friday, 06 August 2010, 06:12
Wow that's awesome! I've been busy implementing the intercept thingy, I'm sure the rest of that math library will be very useful during this ordeal too (the input library too now that I think of it, but later, when I get to menu functions such as customize key bindings)
Sadly it looks like the ship roll is still not what I meant it to be - I myself managed to get it as far as rolling only when the player was both thrusting and turning at the same time, which your first example seems to be doing. (I like the runtime generated ship, might have to steal that for the radar map or something ). What I'd like to do is to make it roll only when the ship actually changes it's course.
here's an image of the event I've been trying to explain earlier where this code fails:

A ship is cruising along at some speed. The ship is not thrusting but keeps it's momentum due to frictionless physics used. Then the player turns without thrusting. The ship does not and should not roll. Fine so far. The player stops turning and now the ship is pointing in another direction but still moving in it's original heading. The player applies thrust and the ship changes it's direction gradually: now it should roll but it doesn't in either of the two proposed setups (ship rolls when turning & ship rolls when turning and thrusting) since the player is only thrusting and not turning!
Hopefully I managed to explain the problem clearly this time
edit: The problem is minor ofcourse - I'm just wondering how this kind of effect can be done since it is implemented that way in subspace/continuum. Also it's current implementation may be harder to do for AI ships.
Posted : Friday, 06 August 2010, 15:50
Ahh, that's an interesting type of roll.
It seems you're after the rotation deviation, so to speak, rather than the rotation velocity.

E.g. the difference between the heading and the angle ('facing'), rather than the current rotational 'strength':
RollPosition = RotationDeviation * ThrustVelocity

I'll outline the steps I've taken to mimic this behavior.

1. Converting your diagram to a function using an AngleDifference function, most conveniently already located in the Math library

2. Deciding the type of interpolation/smoothing to use for the roll, adding a custom Tri (wave) function.

3. Final-testing the algorithm, wrapping the AngleDifference in either Sin() or Tri().

4. And finally tweaking the existing game using the new code/formula.

After tweaking some more, I ended up with reversing the roll (left=right), and choosing Sin() over Tri() for a more natural smoothness.
I'm curious if this is the behavior you're looking for

Well, I'm glad you like my ship
And I hope you enjoy using it
As well as any other code
Posted : Saturday, 07 August 2010, 09:22
I've added a beautiful flame effect, and a thicker ship

Posted : Sunday, 08 August 2010, 06:00
Yes, that finally looks like the effect I'm trying to achieve! No success in implementing it in my game yet, it'll take some time to let all that math sink in. :s
Well for a radar screen I won't be using a flame effect and thicker ship but glad to see you're enjoying yourself!

edit: and after all this I'll have to start tackling AI math... Argh I'll never make it!
Posted : Friday, 13 August 2010, 08:39
Hey, is there any chance/place to see your game in action?
I'm curious what it feels like
Posted : Sunday, 10 October 2010, 13:22
Hey Teasy, terribly sorry I didn't see this sooner! Truth be told, I lost interest pretty soon after this without ever getting to the implementation of the mathematics part Recently I've gotten back into programming slowly and I suddenly wondered if there'd be anything new here
The game is indeed 'playable' and I'd be happy to upload it. As I said - the rolling part hasn't been implemented yet and looks completely wrong.
edit: You can download it here: users.telenet.be/V776822/Project/spacewars4.zip (~6.4Mb) There's a scrolling background and a single AI ship that hunts you (most of the time, it sometimes can get lost ), firing bombs at you occasionally. You can shoot back with bullets(unlimited) and bombs (of which you have three).
edit2: I forgot the controls: arrow keys to move, ctrl to shoot bullets and tab to fire bombs. By the way; there's a small bug where you can go over the top speed because of the recoil caused by firing a bomb. Currently the speed doesn't drop back to normal when that happens and thrusting won't work anymore so you're stuck. Easy to fix but yeah...
Posted : Tuesday, 12 October 2010, 12:44
the game looks and feels alot like
(or identical to?) continuum
i also love seeing ur AI stuff in action ^^

i really like the organization of your code.
it was easy to find most things
i can give some recommendations or optimizations
(only related to code simplification)
but first i'll "take a nice cup of stfu"
because maybe ur not looking for this anyway

so, here's what i've done to make it work ^^
i've made it a "quick and dirty" edit session,
just for illustration.

the "thrust" variable u were using was a simple boolean (0,1)
to indicate whether the player is thrusting.
i've expanded this to become a value ranging from 0 to 15
which is identical in my example program

thanks to this there is a smooth transition
from starting a thrust and stopping the thrust
becoming visible in the eventual roll.

there was a problem between the angle orientation
between our programs.
e.g. i was using a 0 degrees means 'up'
while u were probably using another setup,
like swapping sin/cos or inverting them (under the hood).
(i use non-"traditional" orientation ^^)

so i've messed a bit with the speedX and speedY vars
(in your program called 'pl\s' and 'pl\t')
as well as stuff like the ATan2 call

and i've 'disabled' the 'reverse thrust' key/function for simplicity.

i've modified some more things in your code
like making the program work with any resolution,
changing the radar blip blinkrate,
making the enemy ship 'peaceful' (good for testing)
and some other things ^^

i hope u will still understand or recognize ur old program lol

oh, i've also added a grid
so u can clearly see the ship motion ^^

and i also hope that the roll is now satisfactory

feel free to ask if some (new) code is unclear


I've noticed a 'small' problem with accurate heading
related to the rectangular speed limiter,
so I've added a new circular limiter
that should fix it
Posted : Tuesday, 12 October 2010, 15:28
Sweet! Thanks a lot Teasy, the code is quite clear, looks like it required less changes than I first imagined!
Glad to see you managed to decipher my code without much problems, luckily the program isn't too big yet Any suggestions you may have are of course welcome!
I'm trying to make the game look as much like subspace/continuum as possible for now, but it isn't my eventual goal to make a clone. I Just wanted to make a 360 shooter set in space and subspace seemed like a good starting point (not in the least because I could rip it's graphics )
There's still heaps of work left to do, and AI seems like the next step... I can use any advice anyone can give me on that
Thanks for the other small edits by the way (except for disabling reverse thrust perhaps ), I love my game now <3
Posted : Tuesday, 19 October 2010, 09:10
Well, I am curious why you are converting from object to handle and back again,
when you can simply use a direct reference to the object instead,
as I see you're not using Object/Handle for abstraction (yet?).

I mean, it looks really cool and daunting
but my guess is that wasn't your intention ^^

In your code:

And when 'simplified':

Btw, I was wondering
why you use the fieldnames 's' and 't'
for horizontal/vertical velocities?

Sometimes I use functions to wrap commonly used code.
Or for example to make a process easier (like maths).
Or to create an object in a unified way,
or creating multiple types of objects using 1 function.

Just for illustration, in your code:

And with a function:

Hopefully you'll find something new here hehe ^^

Another example is for saving typing,
and making the code easier to read
and faster to modify

For example using this function:

Turning this:

Into this:

Also, I highly recommend using some constants
for massively reoccuring values ^^
It also clarifies questions like "what does this '36' mean?"
I love modifying my own old source code which use these constants
where I otherwise would have no idea what some numbers meant

For the AI, I've added a small addition
that prevents it from turning a full 360 sometimes.
Simply by calculating whether clockwise or counter-clockwise
is the fastest turning direction to be facing the player.

Apparently there was a bug in the InterceptAngle function.
Maybe I used an older version in a previous test program ^^
Anyway, I've replaced it with the most recent version,
and it seems to be working excellently again

Also, I've add a little radius check
to see if the NPC is near the player,
and if so, to stop thrusting,
which gives it a bit more 'real' feel

To prevent local (or even global) variables
from 'bleeding through' multiple parts of code,
you could convert a Gosub section (or part of it)
to a compartimentalized function ^^
Although, looking at your code,
it is very inspiring to see how well it works
and how easy it is to read/edit it
without having used any functions

First thing I see for example,
for which also a Gosub section can be used,
is making a centralized code-spot
for respawning the NPC and player,
because there are currently 2 places,
for both the NPC and the player,
to (re)spawn them, in the code.

Btw, what were you planning on using the GetCurvature functions for?

Personally I prefer code where there are less numbers
and more concrete or abstract words/variables.

For example, I would alter the following code:

Into perhaps looking like this:

This also allows using Sin/Cos tables ofcourse ^^

You could also use MidHandle on some images,
so the orientation is centered, like for rotated ships,
and, as such, requires no additional offsetting in the code

I felt that the thrust display was a little 'unnatural'
so I altered the entire exhaust velocity orientation
from screen-based to 'game zone'-based.
So now the NPC's exhaust trail
looks identical to the player's

I've also expanded the NPC's thrust code
to have the same threshold as the player
which is now also visible in the exhaust

I've noticed you're sometimes using "#"
as explicit variable type identifier.
For example:

But in Blitz, after declaration,
you're free to omit the "#"
Same goes for integers,
and all other types of variables.

I'm curious if you can implement reverse thrust
the way you want it to function and look
using the new thrust 'system'

I've also hid all debugging values by default.
Press (and hold) backquote (tilde key)
to make all debugging values show up
including some new marker/heading lines
to clearly demonstrate the ship's motion.

And some more small changes

I hope you enjoy

Posted : Thursday, 21 October 2010, 12:44
Excellent as always

I didn't know there was an alternative to using object and handle to gain direct access to a custom type Thanks for your example! I'm curious though, what would be the use of object and handle then? (abstraction??)

I think I just got the s and t names from whatever tutorial I was following at the time... It's possible I misinterpreted them though

As for functions, in the case which you mention I haven't used any since the spawning and respawning code is temporary. It's true I will eventually use a function or sub to create all necessary npc's but that's something to think about later, when I have multiple AI ships flying around there are a few places which could use functions though, such as the bullet&bomb creation and npc/player damage&destruction. in general I tend to create as few functions as possible for some reason... I always think of the extra CPU cycles it would cost even though I realize the speed hit would be non-existent (this is also why I used subs instead of functions - I remember some old discussions which concluded gosub was slightly faster . I Also noticed in my previous games that I never needed to pass/return any arguments to those update_xx functions and I don't like creating globals )

Can't think of any argument against using a few more constants though Midhandle is also excellent, I remember thinking about it when I started the project but I wasn't sure what way would end up best... I edited the code which makes it a bit simpler now!

Thanks for the AI additions I noticed there was a problem with the intercept function though I didn't find out what it was! And the AI exhaust flames were indeed bugged, I thought I'd be able to shave off a few calculations by offsetting the player's position when the flame was created but that didn't take into account the possibility the player might move :o (damn players always rebelling against my code!) The new thrust effect is looking good!

Ah yes, the getcurvature functions were all previous (failed) experiments at achieving a nicely rolling ship

I know you don't need to repeat the variable type symbols but I think it's useful to be able to see at a glance whether or not I'm dealing with a float or an integer

I implemented the reverse thrust, but it may sometimes generate an occasional flame even when the player is not thrusting the way it is now:

Anyway I merged your new code with my own progress (hope I didn't miss anything!), here's the new program. It's actually a game now You can dogfight the AI ship and there's a little score counter.

edit: you'll need an additional image for this newest version. Title
Download it and extract it to GFX\Game\Fx\ folder

Posted : Thursday, 21 October 2010, 21:46

Posted : Friday, 22 October 2010, 10:15
Wow this is an enormous improvement for the AI! Excellent work Teasy, I love teamwork ^^

Ah I understand the handle/object use a bit better now. Thx for the quick overview. Looks like I'll need to use the target var as intended then, so I can use it to track both player as AI ships. Also I eventually want to have some capital ships flying around which may (or may not) become an entirely different class.
I will need to find some images for large ships though, there are none in subspace/continuum.

I'm still going over all the changes (an extra if then condition for the reverse thrust! The horror! ), thanks for the optimizations, those will be useful as I want to have lots of little ships duking it out . The doubled sin/cos table is a great idea! There does seem to be something wrong with the accurate tables though; you only used them for the debris scattering which didn't scatter anymore. Replacing the accurate table with the standard 9 degree interleaved one fixed it though. Can't see anything wrong with them at first glance...

(by the way, there wouldn't be any way to preserve tabs when copying code from here would there? )

I'm aware of the automatic integer conversion but that uses int and not floor isn't it? I remember having a reason for wanting floor instead of int, though I can't remember it

The interlace effect is fun by the way, works wonders on the background! (at least when in turbo mode) though it does make me dizzy when the grid is on :s Would be better if the UI wasn't affected I think...

anyway, I'm off doing some more work!
Page : 1 2 Next 3