_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Blitz -> some help with a space shooter |
|
| 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
|
|
|
| |||
|
| ||||