123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|715|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Blitz -> some help with a space shooter
Page : 1 Prev 2 3 Next
Fri, 22 Oct 2010, 16:34
j\\'ordos
 		I'm using opera and the default blitz IDE. It looks exactly the same but the tabs are converted to spaces
edit: actually it seems it's not socoder's fault, but rather Teasy who uses spaces instead of tabs
Sun, 24 Oct 2010, 09:56
Teasy
 		Thank you for expressing your appreciation

I've noticed 2 typos in my code,
which was also pasted by you up there,
being the assignment in the loop:


(the A in _sinA and _cosA were missing)

I think that's what caused the Sin/Cos table to be empty,
hence no motion on the debris.

The bugged code would also 'precisify'
the 'normal' Sin/Cos table,
causing the ship-related math
to no longer match the visuals.

Another way to allow NPCs
to chase both player(s) and other NPCs,
without using Object/Handle,
is to isolate the Ship/Craft
from the NPC/Player Type-structure.

I've also demonstrated this
in the 2nd program of my previous post above.
Where Craft/Ship becomes a field
in both the Player/Enemy object.
And Craft/Ship field can be a reference
to an object holding the X/Y etc.

When doing it that way,
and you only want to target ships,
not planets or anything
(like in the example program),
you can simply let the target field
be a reference to a Craft/Ship.



Benefits are mostly:
- less code for collisions/chasing/AI
- and better oversight/clarity

But the downside of this
is that you'll probably need to rewrite
a lot of already existing code
relating to the ships,
although it can be done
using simple Search/Replace ^^

Yes, the Int() rounds 0.51 up and 0.5 down
while Floor() rounds 0.99 down ^^
I think that you want Floor
because it saves 1 degree/index
in the rotation array;

  Floor(359.9) ; 359

  Dim Images(359) ; 0..359

And I think it gives a slightly more
accurate visual representation
of the actual ship's angle
(ship angle -> ship image).

Looking at this I can happily conclude
that your intuition serves you very well

Ahh, that's a nice idea you mention;
to (optionally) apply the raster
to all but the HUD/UI

I love using spaces instead of tabs
because it gives me the freedom
to write things inbetween
(if I choose to).

I'm using a (free) program called IDEal
to write my Blitz programs
I highly recommend it
because I'm totally in love with it

Programs like IDEal, and, for example UltraEdit
(which I often use for things like column-mode edits)
allow you to easily toggle
'use spaces for tabs'.

If you prefer to use real tab characters,
I'd be happy to convert spaces to tabs
UltraEdit has a feature to do that with a single keystroke ^^
Mon, 25 Oct 2010, 05:03
j\\'ordos
 		Hehe I hate it when I miss obvious errors like that .

Hmm currently the split between the ship type and the npc/player types are in place to separate 'shop' data (I have some kind of fleet management option between missions planned where the player would be able to acquire more teammates) and the actual action. Also capital ships might need to become a different type. I'll have to think it over

How would I go about preventing the effect on UI features? I figured I could just make a new sub containing all UI stuff and call it after the interlace effect is applied, though that wouldn't be toggle-able unless I made another main loop for it (which I anticipated, hence the _standard B) ) edit: or I could add two if then statements, but that would be excessive...

I actually used IDEal before! I had a large project in one big source file (include? Que?) which took the defaul blitz UI way too long to open. IDEal managed it in seconds. Never could really get used to it though, so I went back to the good old default UI (I have since ported that large project to freebasic, using multiple source files like a good programmer ). Tabs would be nice =)

PS and I request a confirmation dialog when hitting the delete button!!

edit2: oh and in case you're worried about your wireframe ship never being used, that one is planned for a large map overview screen... So you probably should be worried

edit3: would it be possible to do something like this?

I get an error on the second tg though, even when I delete tg each time I'm done with it, so I guess there's no way around this.
Tue, 26 Oct 2010, 15:24
Teasy
 		well, to separate the hud drawing from the game drawing
here is the easier way from my pov:

make 2 separate images that are the size of the screen:
- one for the game 'screen'
- and one for the 'hud' overlay



so, whenever drawing to the hud, set the buffer to that
and when drawing a game element, draw to the game image



when all rendering is finished for the current frame,
simply splash the images on the backbuffer or something
(probably somewhere in your main loop)



oh, and ofcourse clearing the image buffers every frame,
or, well, unless u like a 'smearing' effect ^^



another way is separating logic from visual,
but this presents a new 'adventure' ^^



i guess this is a bit like u described
with your 'new sub'

another question i would ask,
before choosing any of these;
is the effect worth implementing? (1)
and if so, when (at which point of building your game)
is it best to implement it? (2)


btw, if u send ur most recent source to me
(or inline it here)
i will "tabify" it and 'return' it ^^

yes, there are a few tricks u can do
with both Types, Select and virtual polymorphism

the following 2 programs
illustrate the same principle in a simplified way
by using strings


simple polymorphism using strings.bb


simple polymorphism using strings - compact.bb

a neat Select/Case trick
is to specify True as the 'evaluator'/condition.

the following program transforms
the If/Then 'tree' from the previous program
into a Select/Case list.



This technique takes the first 'match' in the specified list.
So , in this way u can also apply Object/Handle 'typecasts'.

But in the program above
typecasting would become redundant
when used with objects.

Here's an example that shows 2 functions
where one is faster for many object types
(1 redundant typecast, no "pre-typecast")
and the other is faster for few object types
(typecasting all first, no double typecast).


polymorph typecast example 2a.bb

u can compare the exact differences
with my previous programs specified above
to find a match that better suits your ideas
of implementation for your game

For some more elaborate example,
here's (part of) a construction (for illustration)
of a program that would support the following key-highlights:
- multiple static and dynamic data/object types
- pre-defined and custom data/object types
- unified data/object type handling using container data/object types
- polymorphic layer abstraction for algorithmic illustration


polymorph typecast exampe 1a.bb

Having read/seen all 'this',
going back to your program below 'edit3'
simply modifying the 2nd 'tg'
to a pointer of a different type
would do the trick:



For clarification
of exactly what is happening
in your code (above):



In some languages
you can stack typecasts and referencing,
like this:
   Object.Computer( np\target )\PosX
Although this isn't favored by Blitz ^^

For more clarification,
and for more alternatives,
here are 2 other versions/examples
of my first Object/Handle program in this thread.

the first one uses your approach
using a Target handle,
while the second
uses the Ship-Type 'normalization'.

this, just to illustrate
that your ('tg') code is possible
even in multiple easier
(and harder) ways


controller polymorphism 1a.bb

btw, you can use
   np\target = 0
to invalidate a handle.
just like with:
   img = LoadImage( .. )
   If img = False Then RuntimeError ..

Btw I love things like your extra 'TargetType'
which tremendously improves the speed

so, here's the 2nd approach,
which is my fav ^^
using less code, and more clarity
(at least for me ^^):


controller ship abstraction 1a.bb

The reason I prefer the separate Ship Type,
rather than the obfuscated target handle,
is because, for example, the collisions and such
are much easier to write with just 1 Ship type.

And, as shown in the NPC_FireAtTarget function,
the handle needs to be typecast first,
before being able to access its content.

So the amount of code increases in any place
where you're dealing with the target.

But, anyway,
I'm curious which of the above approaches,
or perhaps a completely new approach,
you prefer

And I hope that you have found or will find
something in all this
that expands your perception
in the ever-ongoing exploration
Wed, 27 Oct 2010, 08:18
j\\'ordos
 		Well the reason I tried using the same pointer for both cases was so I wouldn't need to assign x,y,s and t vars to local temporary holders, I could just use tg\x etc everywhere I'd need it. Looking back at it it's quite obvious that wasn't gonna work though
Anyway I decided to take your recommended solution, creating another ship type. It does seem to allow for a lot more flexibility! But for now I've just updated the source to work without making too much changes yet, so you can tabify it and make corrections where needed before it'd be too late
For the interlace effect I think I'll eventually move all the UI stuff out of update_player and put it in a new sub that is called after the effect is applied. Seems a lot easier than the other method you described
edit: I altered a lot of things to use millisecs timing but the shield recharging code needs some more tweaking.
edit2: oh and godmode doesn't work anymore
edit3: I fixed the above two issues and added multiple AI ships (4 vs 4) and proximity bombs. The former kinda ruins debug mode and the latter needs a lot of work: if a ship comes within a bomb's proximity range a timer is activated and the bomb explodes when time runs out. There should however be some kind of mechanism to explode the bomb prematurely if a ship moves out of the proximity 'field'. I can't think of any good way of doing this. Next I should probably get some kind of decent range-based damage reduction formula going, and lastly there should be a screen shaking effect when the bomb explodes near the player (and he lives) .
edit4: I've got a working screen shaking effect
edit5: added framework for afterburner and multifire mode. Regarding the ship moving out of bomb's proximity field problem: it should be ok to just detect if a ship is moving away from the bomb once the timer is activated instead.
Wed, 03 Nov 2010, 11:16
Teasy
 		Wow, that's some explosive action going on there

I love the way you implemented AI vs AI,
and making the player part of a team

Bombs, explosions, more shrapnel, screen shakes, very cool!

Well, to use tg\x,y,s,t everywhere, unification if possible:



Btw, I think that simply passing a pointer or handle for an object to a function is similar to or the same as what happens in your current program with the Gosubs:


Function


Gosub

The solution I would use
for 'premature bomb proximity explosion'
is probably similar to the one you outlined
in your '5th edit'



* MilliSecs abstraction/wrapper

I love using my Timer library
(another one hehe)
for any timing stuff I need,
just to make it easy.

Here's how I use it:



That's it, no other code needed.
Just a Global MilliSecs variable,
which is already defined in the library.

Here's the library:
Linky
(from SoCoder's code database)

* simple collision handling

Btw, a neat way to 'resolve collisions' between objects
is to simply use separate functions/gosubs
for each unique 'event resolution'.

This way you can re-use alot of existing code
(in a non-copy/paste way).

For example:



This way the code can be expanded and modified very easily.
Using Gosubs should be just as easy



* solution: range-based damage

I suppose that at distance 0,
the damage should be equal to wb\dmg
e.g. maximum damage.

And I guess a maximum distance can be introduced
after which there is no longer damage,
unless u want a radial distance dissipation ^^

So, let's suppose the maximum distance
for any damage is 100 pixels.



So, dist 0 = wb\dmg,
and MaxDist = 0 dmg.

I love just filling this in,
in my ScalePoint function ^^



The ScalePoint function is also included in the Math lib.
But perhaps you want to use a curve function instead?

Btw, I love the way you reference the specs
by using a pointer field inside an object
to the spec structure ^^

* Player moves away from Bomb

I can think of 3 ways to do this, in this moment.

1) using the InterceptAngle function,
simply filling in the Player and the Bomb,
and then just checking if the result is 'unreachable'.

2) comparing the distance between Player and Bomb
inbetween 2 game frames,
to see if it becomes bigger.

3) i forgot the 3rd,
the moment already passed
(and a new one has arrived)

* tabified program

i noticed that ur also using tabs
in the comments behind the code,
and i see that even UltraEdit
is not able to convert 'all spaces to tabs'
while retaining the 'normal spaces' (single whitespaces).

so i wrote another program for it lol,
with variable 'tab width' and 'conversion threshold'

here's the tabified program from ur 'edit 5'.


spacewars4x1a-tc1c.bb (edit5 tabified)
(no trailing spaces)
(tab width 4)
(space threshold 2)

if u have a newer version already (after edit 5)
i'll upload the program somewhere,
or perhaps with the source if u want ^^,
so u can convert it urself at any time


Fri, 05 Nov 2010, 12:32
j\\'ordos
 		Actually I do have a new version! I tried to keep the post updated but I guess it wasn't meant to be.
I added a capital ship to the game, it's in the same ship type, just added an extra var that says it's a large ship. Their turrets were a bit more problematic though, they're a new type (can't be targeted by other ships) but the CreateBullet sub relied on a ship type so I had to create a new sub for bullets from turrets. Creating an extra vectorobject type like you proposed would solve that problem though since it just needs the x,y,s&t vars. The other thing is that the turrets aren't always aligned properly to their host ship's angle.
The turret's x&y position is calculated as such:

with tu\pos and tu\anglepos being some carefully chosen random values)
display:

and capital ship draw command (large ships don't roll)

For some reason the turrets shift their position slightly earlier than the ship while turning, and the effect is quite noticeable. EDIT: this was because I needed to set the tu\anglepos var to something that was dividable by 9, solved now!

That use of gosubs would probably be the same as a function yes, but the difference is that I already loaded most types at the start of the sub because I need them during the sub itself anyway. If I were to use functions instead I'd have to load the pointer too and then load it again for each subfunction. At least that's how I think it works internally, I have to admit I never tried to disassemble a blitz program

I have a shiptakedamage sub in the new version

Looks like it's time to just take the entire math library instead of copying what I need and putting it in the main bb file... It's getting big enough already Thx for the info on the Timer lib and Scalepoint function And no I don't think I'll use exponential damage reduction, I want the proximity bombs to have a devastating effect on fighters, while being not too good at tackling capital ships, so their damage mustn't become too high. Or maybe I'll just implement some kind of damage reduction scheme for prox bombs and bullets against capital ships...

Well I used the intercept function for the proximity bombs, though I'm not yet sure they work like they should... Do the parameters I pass to the function look good at least?


Thx for the info as usual!
Wed, 10 Nov 2010, 11:00
Teasy
yes, the Intercept() params look good
i remember having to 'fiddle' with the delta time tho..

while debugging the enemy ships' aim,
i added extra visual lines (red-like)
to see when angles are correct etc

btw, i've uploaded the Spaces to tabs converter for you

Fri, 19 Nov 2010, 06:53
j\\'ordos
 		Thanks for the tool Teasy! Proxy bombs seem to work pretty okay (calling interceptangle each update might take a hit on performance tho - I'm pretty sure there's a simpler solution )
Currently I've been working on the AI, hence the downtime I've got all the ships organized in 'formations' (4 ships -or less- of the same type). At the start of the game each formation is set to a seek state. In this state they should seek out the enemy fleet To accomplish this I think I'll calculate the average position of all formations, and the average position of each side's formations. Then each formation would fly to the average position of each formation relative to their own position in their fleet, if that makes sense.
In the game loop I'd call update_formations periodically, which updates each formation's position (average position of all ships in the formation) and then check for any formations in radar range. Once detected it should be targeted by appropriate formations (fighters vs fighters and bombers, bombers vs capital ships, capital ships vs capital ships).
Lastly the update_formation sub should make sure each ship in the formation keeps a certain distance from one another. A hit from a proxy bomb should increase that distance.

That's the gist of it, still have a bit of work to do, and I hope it won't be too slow!
Fri, 19 Nov 2010, 07:38
Teasy
 		The solution I like to use
for calling InterceptAngle less
is by using a simple timer
with an interval like 500ms.

I think I've used the same technique
in a previous program up there,
or perhaps in the game itself.

With that technique
you only need an angle# field or variable
to store the last calculated angle to intercept.



Wow @ your ship formations
That would be awesome to see

Can ships also 'break' formation?

Also I think that the ship attack priorities
that you have assigned and outlined
sound like the real thing!

Thanks for the update

Fri, 19 Nov 2010, 10:41
j\\'ordos
 		Well with the bombs I don't need to store the angle, it just needs to check if it's unable to 'intercept', if I delay the check it might not be accurate enough since bombs move quite fast and if the player moves away from the bomb (which is what the check is for) there is even less time! Haven't tried to put it in yet though, it might not be a problem.

It remains to be seen if I can actually manage to implement the formation AI in a believable manner maybe I'll just make all formations visible at all times...
Breaking formations isn't something I have planned, though ofcourse once engaged in a firefight they won't try to keep a nice formation and behave more or less like the current AI Once done they should regroup and go to the next target.

edit: hmm I've hit an unrelated problem: for some reason the player ship is now moving way too fast... The top speed is still the same when I print it during gameplay, it looks like it's somehow being updated twice!
edit2: ok I fixed that problem, turns out I didn't add a return to the update_formations sub, and next in line was update_player, so it was updated twice. Damn gosubs
Sat, 20 Nov 2010, 12:56
Teasy
 		Nice

I vote for a simple (easy as eating pancakes) implementation ^^
Fri, 26 Nov 2010, 10:06
j\\'ordos
 		Just as a heads up, formation AI is in, but I have to deal with target assignment. Currently I have a function that selects the closest appropriate formation to intercept any newly spotted enemy formations. But it's strictly one on one, so each side's bomber formation targets the capital ship correctly, but the capital ships don't target each other because they are already targeted by the bomber formation.
So I'm implementing a 'heuristics' array that tracks each side's available formation types and the amount of formations it should assign to each enemy formation. (what a sentence) It should look something like this:
target_capships = ceil ( (available_bombers + available_capships) / enemy_capships )
Then each time a capital ship is spotted it is targeted by the appropriate number of formations. available_bombers & available_capships will be updated (available = in seek state, it doesn't mean the number of formations the side really has) and target_capships will be calculated again for the next enemy capital ship that's spotted, if any. I'll have to make sure no divide-by-zero occurs, but that should be an exception anyway since for example fighters could assist in bringing down a capital ship if there is no other target left, or even return to the carrier)
edit: OK that seems to be working. Shouldn't have used an array though, that stuff is unreadable! Before I change it to a type I'm going to add in non-respawning ships though.
Sat, 27 Nov 2010, 14:56
Teasy
 		Wow, nice

Btw, if you use Floats (I see the Ceil() function in your 'code'), a division by zero will result in "Infinity" ^^
Converted to Int it becomes -2147483648.

Are some of your ships 'peaceful'?
Or do some of your ships support 'peaceful' states?
Tue, 30 Nov 2010, 12:49
j\\'ordos
 		Ah that's good to know! I don't have non-combat ships planned, but they'd be easy to implement. It depends on how complex I'd eventually want the scenario's to be... The standard battle would be a carrier vs carrier fight. Each side has a carrier with a couple of escorts and a bunch of fighters. Then the objective would be to eliminate the other carrier. (ships don't respawn anymore, though I do have the old code still in there, toggled with the SuperArcade var. I think it could also be a fun mode of play if ships constantly kept respawning in the player's carrier until eventually one side loses all it's carriers). I don't plan on having any scenario beyond that, but some kind of 'escort the transports' scenario could definitely work well in the game as well...


New release ^_^ There's a huge amount of work left to be done though!
Capital ship graphics are from tyrian: www.lostgarden.com/2007/04/free-game-graphics-tyrian-ships-and.html
users.telenet.be/V776822/Project/spacewars4_2.zip

I was hoping to move on to implementing new features like the map screen or scenario loading, but it looks like I'll need to pause for a moment and properly finish the AI first. Controlling capital ships is a bit too boring too, I'd like to make them feel more like a naval warship from the age of sails, delivering a single devastating broadside, then slowly reloading for the next strike . That would require some code to guess which side the player is aiming at or some way for the player to control it himself, currently not very easy to implement. I wanted the player to be able to control turrets too (there's gfx for it in subspace and I like games that let you control everything ) but since capital ships are so slow and hard to maneuver I think it'll be safe to give the player control over both a capital ship and one of it's turrets at the same time. (using the mouse?)
Also left to do is implementing a chatlog, where you can read messages from your teammates when they spot an enemy formation/get killed/kill/... to make the game more immersive, which is quite lacking at the moment. The scale of the game has increased but I'd still like to see at least twice the current amount of ships flying around. (and preferably much much more)
Lastly there are details such as projectiles from turrets being drawn before the capital ships, timerlib not yet implemented, haven't looked at the proximity bombs anymore, etc etc... Lots of work anyway
Mon, 06 Dec 2010, 16:42
j\\'ordos
 		A small question while I'm working on the chat messages:
I have a Message Type:

Each time a new message needs to be generated a new chatmessage type is created and if the number of messages exceeds a certain maximum the first chatmessage is deleted.
Anyway I'm offsetting the y position of each chat line based on it's handle id #, like this:

Can i trust blitz's internal numbering to always follow this scheme (first type gets id 0, next one gets id 1 etc...)? Or would it be wise to dedicate another var in the chatmessage type for that purpose? Does a 'Delete Each' command reset the counter? (I know that deleting one object doesn't cause blitz to reuse the old handle #)

edit: also, anyone got a good idea for a special effect for the destruction of a capital ship?
Tue, 07 Dec 2010, 08:12
Afr0
 		This topic gets the 'Longest Topic of the Year' award!

-=-=-
Afr0 Games

Project Dollhouse on Github - Please fork!
Tue, 07 Dec 2010, 13:36
j\\'ordos
 		Is there a cash prize?
Tue, 07 Dec 2010, 22:09
Afr0
 		Ask Jay!
Wed, 08 Dec 2010, 05:01
CodersRule
 		I was about to ask if Most Pointless Topic got a cash prize. But it looks like I'm two days late.
Wed, 08 Dec 2010, 06:13
Jayenkai
 		Back on topic, folks.. This is a nice lengthy coding discussion, something we've not had here in ages. Let's not kill it.

-=-=-
''Load, Next List!''
Wed, 15 Dec 2010, 09:44
Teasy
Well, it's nice to see more people commenting here


* Non-power-2 image problem

When running the newest game you have posted,
I get a Memory access violation
on the ImagesCollide call
dealing with the capital ship images
in combination with bullets.

I'm using a GeForce 8600GT with latest drivers.
And Blitz3D version '1.105'.

I suspect this happens because some setups
( video cards, drivers, etc )
are not compatible with Blitz's way
of handling some non-power-2 images.

I remember having seen a post somewhere
stating that this issue was recently fixed,
but unfortunately I see that it still happens

I'm a little surprised that some other images,
which are also used in ImagesCollide
( like bullets )
do not cause this MAV (?).

The only other differences I can see
are that the mothership/'escort' image:
- is wider than high,
- and exceeds the horizontal resolution boundary.

While for example the normal ship images:
- are higher than wide,
- and exceed the vertical resolution boundary.

When I set a resolution of 3200x2400, it still happens,
so it seems less evident that it relates to boundaries.

The fix I usually apply is simply making the image power-2.
E.g. 242x242 would become 256x256 with some padding.

So I have simply modified
the primary capital ship's image loading parameters
from 242x242 to 128x128,
to quickly see if it helps/works.

Now the same thing happens, but for the 'escort'.
So I change that too, from 168x168 to 128x128.

And again it happens, now with bomb vs ship.
So I alter all the 3 ship types image dimensions
from 36x36 to 32x32.

And that seems to do the trick, Yay! ^^

For some reason this 'thing'
has not 'bothered' me before in this game,
before some software changes.

So I tested the game on an older Blitz3D version (1.99)
and there it doesn't seem to happen as often (!)
( but it still happens ).

In my latest changes/additions to my games
I have made all images power-2
that are used in ImagesCollide.

But perhaps there is a different/easier fix.
I've spent quite some time on this issue
through-out various games and programs ^^

Hopefully this information is useful


* Unreachable target

After dying, I'm sometimes 'spawned' into some yellow ships
flying waaay upwards, to some 'far away' target
( which doesn't exist ).

I have no idea why that happens,
so for that I added a self-destruct key (BackSpace):



And then I discovered the following line,
which I find very funny ^^



On me it had a very unpredictable/surprising effect


* Object order

I think that your intuition serves you well, j'ordos
Blitz's object ordering is, to me, pretty logical in nature.



Any call to New( type ) will append a new object to the list,
so if there are already 10 objects in the list,
a For..Each will iterate through those 10 objects first,
before 'arriving' at the newly (or last) created object.



To change the order by yourself,
you can use the Insert command,
to for example reverse the default order from back to front,
like this:



Note that keywords like Before, After, First and Last
can be used like Int, Float and Str,
which need no braces and can be stacked
to easily navigate in the list.



This technique can also be used
to manually iterate through a list
in any order that you require:




* Damage effects

For capital ship destruction effects
I like adding various things.
Like smoke puffs and debris coming off
even before it has been destroyed.
For example below 33% health,
damage becomes increasingly 'visible'.

In a game called Robotix (also a 2D shooter),
I have used various effects with similar constructs.
All of them 'spawn' at random locations,
either on the body (image) or radially.

Here's a list based on those effects in the game:


Note: The list goes on a bit ^^

The capital ship can 'emit' its largest explosions, debris,
and biggest sound effects, either in a sequence or all-at-once,
once it is finally destroyed.


* Future visions

A while back I remembered that the game you're currently making
is not far off from a fantasy/vision I used to have
about a non-existing game.

It's amazing to see that fantasies can come to life
without there having to being a conscious initiative
Even your descriptions of the game you're intending to make
closely resembles that game from my fantasy.

Like the things you just mentioned match up very well:
- 'spawning inside' a capital ship
- chat log
- capital ships
- control over (capital) ship 'sub-systems'
- potential for space traffic jams
- intuitive/immersive gaming experience

As well as:
- docking with (capital) ships
- boarding or departing from (capital) ships

My mind goes crazy (madly galloping towards the sun)
when thinking about this

On a side-note I'd like to vote for 'keeping it simple' ^^
I've spent most of my coding time on figuring out
how to make something simple,
revolving around What is inspiration?.


* New code bits

I've added a little code here to show a bit of loading progress
during the starting up sequence of the game.



And some code to maximize the game window
straight after having been created.



The above code uses 2 API definitions ('decls')
in the UserLibs folder:


File: api.User32.decls

And here's the game code with 'all the above' in effect
( just for illustration )
as I can imagine that you have a more recent version ^^


File: spacewars4_2 \ spacewars4-tc1.bb

I hope that you've enjoyed reading this,
and I also hope that you'll find something in all of this
that you can use


Wed, 15 Dec 2010, 17:07
j\\'ordos
 		Yay a new reply! And yes, any comments are nive to have, don't listen to jay, he just doesn't want to pay the cash prize!

That imagesize problem is unfortunate, I thought that only applied to 3D programs, and I don't use the graphics3d command. Resizing the capital ship images isn't much of an issue, but resizing the fighter craft ones is! Since the problem occurs with the imagescollide command, maybe this is a good argument for switching to radius based collision detection? It wouldn't matter much for the 36x36 ships I believe, and it's probably faster too . I don't have any clear ideas on what different collision method to use for capital ships though, bounding boxes? But they'd have to be rotated according to the ship angle. Multiple circles perhaps? I haven't faced this problem myself on this computer, and I don't know if other hardware configurations might have problems beyond the collide functions though.

Regarding the strange AI, it's because it wasn't finished yet, the formations only received a new target if a new enemy formation was spotted, after that they won't get another target after destroying their original target, and they just keep flying endlessly in whatever direction they're facing. This has been improved a lot in the current version

Thanks for the examples on the type lists, there's some stuff I didn't know yet in there! I also didn't know of the insert command This will be very useful once I get scenario loading up as well.

I'm too tired to continue right now I'll check back tomorrow, thanks again for the help!

edit: that's better!
Regarding the self-destruct button you implemented, I just remembered I actually programmed a way to jump to the next or previous ship on your team by using the +/- buttons on your numpad. The End statement when there is no ship left on the player side is of course temporary In fact I also need to implement something to make the jump to a next ship a little less abrupt when the player is destroyed. The plan is to go to a radar map screen when that happens, there the player will be able to select another ship he wants to take control over. (action will be paused) In SuperArcade mode there should instead be a respawn timer, just like in subspace/continuum.

Thanks for the list of effects for the capital ships, I think I'll just make the ship turn in a random direction and create random explosions until it finally blows up completely, but that final explosion effect is another question.

I'm glad the game design appeals to you! And that there might be others who will enjoy an old school overhead shooter I've always read that such games are a dime a dozen but I actually know of few. There's my main inspiration subspace ofcourse, but that's multiplayer. Hell Fighter 32 was another source of inspiration but beyond that there's nothing I can really compare it with. Gate88 is more RTS, and the old zone66/fire fight/swarm/... games aren't team based.
Anyway, to continue about my own plans: I haven't really put any thought into docking beyond that a ship moving slow enough and being near enough to the center of a carrier should automatically become docked (allowing it to replenish bombs). A more challenging docking sequence like in your showcase entry could be fun but probably wouldn't fit in the fast paced gameplay. If you'd like to code one for spacewars 4 please do though, any self respecting simulator needs a ridiculously difficult landing sequence after all!
I don't feel like I need to take any special care to prevent the game from growing overly complex/cumbersome, up till now most features came quite naturally (I've known different!). For the combat sim part of the game I don't have any major features left beyond those I mentioned before. There's all the 'specials' from subspace: repels, rockets (=turbo), cloaking, decoys... But I don't intend to add any of those unless I somehow figure out a way to let the AI make intelligent use of those.

Lastly, thanks for the modified loadimage functions, the visual confirmation is nice (though will have to be replaced), especially on a slower PC I'm sure... Actually, how does the game perform for people here? (did anyone other than Teasy try it? ). Another advantage is that it'll be easy to put in error checking in case an image is not found so those functions are keepers.
Tue, 21 Dec 2010, 07:15
Teasy
* Chemistry

I'm so amazed
at our resonance in this 'project'!
It is like chemistry

There's some kind of vibration
'under' or 'behind' the project (and you)
that makes it very easy for me
to 'connect' and 'play'



* Collisions

Ah, yeah,
switching to radius based collisions
is great too
And it provides the ability
to 'dodge bullets' ^^
( Tyrian-style )

Btw, I also love(d) playing Zone-66,
FireFight & Swarm (wow!)

I also noticed
there are 'a lot' of games like this,
but for me most (good ones)
can be quite 'hard' to find ^^

Anyway,
adding that to a cascade of thoughts,
I see 2 'safe' (quick'n dirty) options:

(1) Use a bulk image resizer ^^
E.g. to convert non 2-power frames/images
( like 20, 45 and 87 )
to 2-power frames/images
( like 32, 64 and 128 ).

I noticed that
you have also nicely rotated
some single-frame images,
and neatly stacked them
into a multiline animstrip.

So I'm guessing you already
have some tools (perhaps homemade ^^)
available for this purpose.

If not,
I also have a homemade tool
called 'AnimImage Layout Changer'.

Simply enter input and output parameters
to convert an animstrip
to any desired arrangement,
with various customizable features.



(2) Overload ImagesCollide
to become a custom collision function.

Again, many options ^^
I'll outline a few, just for fun

Option 1

- overload imagescollide
  so that no code has to be changed





- an additional percentage can be implemented
  to determine how much of the image should be used for the radius
    - for example:
        - ImageWidth( image ) / 2 * 0.30
      which uses 30% of each image/frame for the collision radius.


Option 2

- use a new function
  where some/few code requires changing
- radius can be determined per object type
  defined as a field in the statistics




Option 3

- or radius can be defined
  as a function
    - or array





- object types can also be defined
  as constants
    - for convenience


I'm curious which option you prefer
or perhaps a variation thereof

Btw, due to preceding accurate collision detection
with something like a simple bounding box check,
quite heavy algorithms can be used.



* Vector Collision Library (VCL)

If you *really* want something more accurate
and don't want to deal with manually defining
multiple circles to detect a large ship collision,
perhaps a custom library will come in handy

Btw, I remember that SyntaxError's SpriteControl
has exactly that multicircle collision algorithm,
..or was it Gosse's nSprite Lib, hmm..
Well, I love(d) those libraries too

Anyway, I have built a vector collision library
with the help of many BlitzCoder peoples
The system is pretty versatile
and is very easy to implement.

Here's one way
to demonstrate how it works
using images, in 2 (!) steps:

(1) Create a vector model from an image.
The image outline is traced to create the model.



(2) Detect collision between vector models.
Both a custom scale and angle can be used.



Here's the latest version that i have,
hopefully still in mint condition ^^



That "Docking in space" demo that you saw
also uses this VCL



* Live 2-power conversion

There's another option I see
to internally make all images power-2
during the loading of images.

This increases the loading/copying time
but avoids having to modify any images 'by hand' first
and it makes the 'game download' smaller too.

And it so happens to be
that during my 'power-2 adventures'
I have constructed such a custom LoadAnimImage function.

Actually, it's inside yet another wrapper system ^^
A handy 'discovery' I made while creating it
was that you can simply add the anim-image parameters
in the filename itself for super-easy handling.

If you take, for example: "Spaceship.64x64x16.png"
Then only some code is needed to parse the name
and you can grab the width/height.

Here's the full wrapper code
called the "DrawImageRect AnimImage Lib".



It has no full-fledged help
( like the layout changer program )
but a bunch of comments are included
and perhaps an example program would be nice





* Image dimensions compatibility

There's another issue
that may come up in some situations,
which is images being wider or taller
than the screen resolution.

In the past,
I have used 3 work-arounds for that:

(1) Use an image slicer
to cut all anim-images up
into single frame images.

This solution is extremely reliable.
Also my game Terra Colony uses this approach.

(2) Redistribute the frames
to fit within the horizontal screen boundaries.

It seems that most drivers/cards
are less prone to crashing
when exceeding the vertical
instead of the horizontal boundary.

Although in some scenarios
even then a crash is still inevitable.
The "AnimImage Layout Changer" above
was primarilly built for this purpose.

(3) Redistribute the frames
to fit within both horizontal
and vertical screen boundaries.

This means splitting the frames
across multiple images if needed,
which kinda complicates image/frame handling
unless wrapped in code ^^

From my research I have found that
a horizontal boundary of 640 pixels
is fairly reliable
even when using a lower screen resolution.

I have also noticed that BlitzPlus is more stable
at handling all of the above things,
but even there
I have (accidently) managed
to crash my system
with a simple LoadAnimImage
(or CreateImage) call (oO)

Hmm, sorry for the rant ^^
I hope you'll find some useful info in here



* ship select

ahh, i was wondering
which keys '74' and '78' were
that's also a great debugging feature

btw, have you thought about a 'camera'?
e.g. if the view changes,
the screen quickly but smoothly moves
to the new 'target' (ship).

maybe not needed anyway,
but i always loved that in (my) games



* final explosion

if u wanna make the final explosion
really simple and easy:

(1) just put lots of randomly placed
smaller explosion animations
simultaneously on the ship.

(2) have a loud explosion sound ready.

(3) then just add
some massive amount of debris flying outward.

i think this (bare/decent minimum)
should do it quite nicely



* ship docking

i hadn't even noticed
that there was already a docking feature
in the game!

the way it works currently
seems quite (arcade) intuitive
and suits highspeed gameplay.

i personally like a 'long-term' type of game
in which highspeed gameplay is merely sporadic
( like in combat/threatening situations ).

and most often
the game is in a more 'quiet' state.

for example
to navigate around the 'game world'
or to build and customize settings,
ships, capital ships, planets etc ^^

while still being a real-time game
without needing complex strategies

i guess advanced docking sequences
and neutral/friendly ships
also fit in
with that 'slower' type of game



Enjoy!


Tue, 21 Dec 2010, 15:01
j\\'ordos
 		Ow that's a lot of information, I'll have to let that sink in for a while But on first glance my preference would go to keeping the images and creating a new function for radius based collisions ( = option 2). The code alterations seem minor enough and I could keep the old imagescollide for capital ships (I don't mind altering the capital ship image sizes as much since I merge those frames together myself. I have a tool for that as you guessed, called EZ Image Rotator (I found it on subspace forums where people use it to create custom shipsets) I also like the ingenious simplicity of a loadimage wrapper to fix the sizes as an alternative. I believe the speed gain from using radius collisions instead of pixel perfect is quite substantial though, which is certainly interesting when I want as many ships as possible. (I originally intended to use rectsoverlap for ships out of view to keep the game as fast as possible)

Ah about the large images, I remember I wanted to ask about my current setup for the scrolling backgrounds. I'm using blitz built-in tileimage commands to achieve parallax scrolling but that does require images larger than the screen:

Can the createimage&tileimage commands also suffer from these problems?

The camera is an excellent idea. I don't think it'll be too hard either since I already unlinked the visible screen from the player's ship position for the screen shaking effect. I still think I'll keep the goto map screen on dieing idea, but camera scrolling could be used for a lot of things later on, like showing the destruction of the player's/enemies' carrier or other important events!

Unfortunately there is no docking yet, you didn't miss it What I posted was my idea on how I think it should work, not what was already implemented.
Nope, action is the main focus of this game The only resting periods will be the paused map screen, the shop/fleet management between missions and the start of each mission while both fleets are still searching for each other. Some tension build-up during that stage would be nice, by use of the chatlog again (sounding off each formation for example) though it would probably become old pretty fast.

Bah, turned this into a full blown post after all
Page : 1 Prev 2 3 Next