Alien Space Beetles Update
Community Forums/Showcase/Alien Space Beetles Update
| ||
| http://www.seamlesstexturegenerator.com/asb/asb2.zip AotASB is now playable! Sort of. :-) The game now keeps a basic score, 100 points per enemy hit, and gives you three lives. The final score also remains displayed on the title screen when you die so you can determine what your high score was. There are three different types of enemies with five different attack patterns. The enemies spawn randomly. In the final version they will probably be controlled by a script so you'll have groups of enemies of a specific type emerging at specific times, but this is just for testing. The enemies now also spawn bullets at random. This is what creates the difficulty since unlike the enemy paths, you can't easily predict where and when the bullets will show up. It should be noted that all bullets are fired downward right now, but that is simply because sideways and diagonal bullets, and all the other types of bullets, are not yet implemented. |
| ||
| Update: I've now added a nice font to the game, and fixed up the score and high score displays so they are nice, as well as displayed the number of ships remaining. Eventually I'll have a bunch of little ships there rather than a number, but for now I've just got the number. |
| ||
| hi swift, got any screenshots? |
| ||
Well, the screenshots aren't awfully impressive, since it is retro. It looks better in action. But here's one: |
| ||
| aliens need different coloured bullets, but you knew that anyway right? I'll try this later. Did you try mine yet? Hey nice, it's coming together now. Is the ship going to start slower and the you get speed POWs. Also I can fire extremely lots of bullets if I'm prepared to click real fast, is it going to be like that always? The stars seem to move more smoothly now, did you implement the 0.5 in your y coords yet for perfect consistent rounding as suggested originally by Beaker e.g. y=floor(y+0.5)? Well the faster ones seem smoother but the slower ones still jerk a bit, this may just be an effect of different game speed from FPS of course, which can't be helped. |
| ||
| Grey: Yeah, I tried Orion. I don't really remember much about it, other than the fact that it still needed a lot of work, but I'm sure you realise that. As for the alien bullets, I'll probably color them green or something. I don't think it's a big issue though. It's pretty obvious that bullets moving towards you are bad, and those moving away from you are good. :-) |
| ||
| Is the ship going to start slower and the you get speed POWs. Why? Do you think the ship moves almost too fast now? Unfortunately, the speed of stuff moved with the mouse is controlled by what the user has set in Windows for mouse speed. I am not sure if it is possible to set a standard speed, or if that would even be wise. My own mouse speed is set to 3/4 of max. Actually, the speed it moves at right now is probably what I would have for the default. I don't know if I will have a powerup to increase the movement speed, as it might feel weird to have it change. It might feel too much like a mouse pointer then. I did plan to have something to speed up the rate at which enemies move and spawn though. That might also speed up the player's movement, but I haven't decided. I'll have to try it and see. Also I can fire extremely lots of bullets if I'm prepared to click real fast, is it going to be like that always? I haven't decided, but it could well stay that way. For the weapons obviously I considered having two shots fire at once, and shots fire in different directions at the same time, but I also considered a powerup which would just fire a fast constant stream of bullets without you having to click for a short time. The problem with limiting the rate of fire is this. If I limit the rate, and require the player to click for each shot, while clicking for each shot can be more fun than just holding the button down, clicking and then not having a shot appear because the gun hasn't recharged would not feel good at all. It would be annoying. So either I have the user click for each shot and let them fire as much as they want as often as they want, or I have them simply hold down the mouse button and the shots fire off at a set rate. I think what I've chosen is probably the more fun, with a game like this where you're not throwing a hundred enemies at the player at once. Though that is an idea... If I used the enemies at the original scale they would be 3x smaller. I could put a lot more of them on the screen and a lot more bullets and the player could still dodge them because their ship would be smaller too. I wonder if this would be better or not. I think it might get people's attention at least, like with Cromsonland where the screenshots show like a hundred guys on screen at once. That's pretty impressive. The stars seem to move more smoothly now, did you implement the 0.5 in your y coords yet for perfect consistent rounding as suggested originally by Beaker e.g. y=floor(y+0.5)? I treid that 0.5 thing but it didn't make sense to me, and it seemed to make the stars move more choppy. So I just went back to the plain old Floor() I was using. I really can't be screwing aorund with the stars any more. They're good enough IMO at this point. There's lots of games out there where they move much less smoothly. There's no point in trying to be perfect with the stars when I have the whole rest of the game to write. |
| ||
| controlled by what the user has set in Windows for mouse speed this sounds like a major flaw, so some users will be able to avoid stuff better than other users, purely based on their windows mouse settings instead of skill? constant stream of bullets In the old DOS version of my shoot'em up, if you hold fire you get a constant slow stream of bullers but cliking faster enables you to squeeze a few more out but not past a certain coded limit (thus rewarding the button mashing player a bit). Then I also had autofire powerups that made a massive stream that wore off after a short while.Don't make it too small! Big is good. Yeah don't screw around with the stars any more. However, the 0.5 shouldn't have made them more choppy, it should have made it more accurate ho hum. See basically if bankers rounding rounds 1.5 to 2 and 2.5 to 2, your method: floor 1.5 = 1, floor 2.5 = 2, mine: floor (1.5 + 0.5) = 2, floor (2.5+0.5) = 2. So it might not seem any different yours and mine except mine rounds .5 up and yours rounds .5 down BUT. Yours: floor 1.8 = 1, mine: floor (1.8+0.5) = 2, now which one seems more correct? I'd hope you say mine :-) |
| ||
| this sounds like a major flaw, so some users will be able to avoid stuff better than other users, purely based on their windows mouse settings instead of skill? It's the same flaw you'll find in every FPS game, and any other game that uses mouse control, as far as I know. I don't know of any way around the problem unless you're to force the user to calibrate their mouse in some way. BUT. Yours: floor 1.8 = 1, mine: floor (1.8+0.5) = 2, now which one seems more correct? I'd hope you say mine :-) Nope! I'd say mine is more correct. If you use your method, and you start a star out at 0 and move it to 600 at a rate of one pixel per second, then halfway through the first second, it will jump to the second pixel, but then from there on it will take one second to jump from pixel to pixel. With your method, in order to get that star to stay on the first pixel for one second so that it stays on all pixels for the same amount of time, I have to start it "off screen" with an offset of -0.5. Of course it is not off screen at that point after the rounding, so the floating point and the integer coordinates now aren't consistent with one another as to what is onscreen and what is not, and I have to start everyhting eith a weird negative offset. So I don't think that is a very good method. It reminds me of what a pain it is working with texture coordinates, and I'd rather stay away from that icky stuff when I'm working in 2D. :-) |
| ||
| same flaw you'll find in every FPS game not strictly true as it only defines mouse look speed not player movement speed. Anyway, yeah there isn't a way around unless keys are used which you are trying to avoid of course.hmm, re: the 0.5 thing. My method gives proper rounded figures where 0.5 always rounds up, that's all. The way you've chosen to apply it with it having to start at -0.5 to ensure 1 second on a pixel is pretty obscure. In the case of stars, who cares if the first one is only on the same pixel for half the time? Having said that, your plain floor method should result in just as smooth stars as mine, I've just calculated (due to its consistency), so it doesn't really matter plus, yours is faster. Be in mind the 0.5 method though as I'm sure it can be useful for games where the objects have x and y coords and move in non-integer jumps. When I was coding Iron Fist I ran into problems just using floor when doing gravity and landing on platform calculations, can't remember why, but the rounding business sorted it out. Anyway, I look forward to seeing you next version! [edit]ooh I forgot to ask, is the collision pixel perfect or not. Mine is but I found that it can get slow with loads of bullets on screen, so I'm going to make the bullet collision areas rectangle and keep the aliens (and your craft) pixel perfect. This will reduce the collision overhead by a lot I'm sure. Furthermore I found a massive optimisation with collision detection in Iron Fist. Previously I was testing all objects against all objects, a cartesian join. I thought that blitz would go, nah this rectangle is nowhere near that one and thu skip the collision code. But on a hunch I made my own wrapper around the collision routine to check if the man was in the same vertical column as other objects, and if so then only test those objects. It sped up my collision routine massively! Hard to believe that an optimisation like that would make any difference (if the blitz internal code was supposedly already efficient) but it did, trust me, try it yourself! |
| ||
| The collision is pixel perfect. If you have a speed problem, then all you should need to do to correct that is check the bounding box first and then check for the pixel perfect collision if the bounding box check is sucessful. However, the problem you describe is a different one than just a slowdown from pixel perfect checks. That problem you had there was a common one where the number of checks increases exponentially with the number of objects. I suspect you simply coded your collision code incorrectly. Let's say you have a hundred bullets. You said you were checking every object against all other objects. If that includes bullets then that means you may well have been doing 100*100 checks. Of course, if you are observant, you will realise that if you check object 1 versus object 100 then you need not check object 100 versus object 1. That brings us down from 10,000 checks down to (n*(n+1)) / 2 or 5050 checks. However, if you are particularly observant, (and your game design allows for it) you will realise that you don't need to check any of the bullets with eachother at all. In my games, I usually have a bullet type, a player type, and an enemy type. The bullet type contains a source parameter which tells me if it was fired by a player or an alien. My loops are as follows: 1. Check each bullet against player. Ignore bullets with source player. 2. Check each bullet against each alien. Ignore bullets with source alien. 3. Check each alien against player. Now I can have a lot more bullets and aliens on the screen. I still have the problem of course that if I have a lot of bullets and aliens then I will have a lot of collision checks to do, but it is a lot less than if I had to check every bullet against every bullet and every alien against every alien. What you did checking the column the player was in is pretty clever, but you still need to compare that column with every object in the game. If I understand what you did correctly, your trick works because checking columms is faster than checking bounding boxes, if only a little. You were almost to a great solution for checking lots and lots of collision objects against eachother, one that I would use in my own games. That solution is this: Divide the world up into boxes of equal size. Then place a pointer to each object in every box it overlaps. Then simply loop through the boxes and compare the objects in each box to see if they overlap. The difficult part here is making sure you don't spawn multiple explosions when the same two objects collide in multiple boxes at the same time. In my game, I don't use this method. But when a player hits an enemy or a bullet and they explode, I don't bother checking the rest of the enemies or bullets. If you are not using this method to perform physiucs between lots of objects then you can get away with doing that to solve the problem. Otherwise you may need to keep a list for each object that says which objects it was checked against and check that each time you go to check it against another object. All this checking would make for some messy code, but it should be a lot faster if you have tons of objects onscreen than checking them against one another, or even checking to see if they are in the same column. Anyway, it isn't Blitz fault that checking collisions in your game slow, because it's not possible for Mark to implement this sort of collision system that can optimize the number of checks, without forcing you to use some kind of Blitz collision system. That's what he does in Blitz 3D, and it works well, though he probably does not use the method I decribed above to optimize it. He uses some other method. Or maybe it is not optimized. I don't know. But he could optimize it if he wanted. :-) |
| ||
| Boy this little demo's gone over like a ton of lead bricks. Only comments from Grey Alien this time. Not very encouraging! |
| ||
| The 100x100 thing is called a cartesian join, I got the term from duff SQLs. I use the same 3 loops as you moreless, they are logical after all; except I do 1) check player against enemies and enemy bullets 2) check bullets against enemies. To do this, I use an array of types for bullets and another for enemies. Why? Because all objects in the game arethe same Type, they have the same available properties so one function can be used to manipulate all the sub-types (no inheritance in B.Plus). I don't want to look through all the objects and check their Sub-Type flag, just the ones in the relevent array. If I implement an ammo type that can destroy alien bullets then I'll need to check bullets against alien bullets too. Your box method sounds interesting, a way to further reduce the bounding rect checks. What I found out is that alway checking a bounding rect BEFORE calling Blitz Plus's pixel perfect collision detection is faster, and only checking a column is even faster. I chose this method in my platform game because the levels were mainly long not tall, so there were less platforms to check vertically than horizontally. My platforms were all objects so they could be positioned and moved anywhere, as opposed to using an old-style grid system. Sorry your thread is brick-like. At least I replied :-) |
| ||
| "Sorry your thread is brick-like. At least I replied :-)" Well I'm just worried people don't like how the game is shaping up, because that's not good if I plan to sell it. If it is just the graphics, I could have an artist do some new aliens. Though with my time schedule it's unrealistic to expect a bunch of weird looking levels, unless I go with something simple that repeats a lot, like walls on the sides. |
| ||
| Well I've sat and played it, and all star field, collision etc technicalities aside, it was fun. BUT as yet I see nothing that makes it stand out as being interesting/different/exciting enough for people to pay for. Seems much like the demos many people do as their "first game", and we know in your case thats just not true. I would have thought the retro shooter was a flooded market. I didn't like mouse control as moving up and down really seemed unecessary to me, when sitting at the bottom of the screen, generaly gives you the best chance of missing the enemies and their bullets. Some sort of auto fire is a must too. My finger is dead lol |
| ||
| Some sort of auto fire is a must too. My finger is dead lol Yeah, I've just implemented an auto fire. There's a lot of shooters out there, but unless you go to emulators to get your fix, there's not a lot of good retro ones. There are a few. And there are a lot with tons of flashy graphics, mostly using 3d acceleration, but that just cuts out a large segment of the market who is without a high end system to play on. At least that's the theory. I don't really have a lot of options at this point other than to develop this, since this is all I have the graphics to do, and I've wanted to develop a shooter for a long time anyway. |
| ||
| I must admit I expected something more sswift, knowing your code skilzz. But I had some fun :) |
| ||
| If the waves become non-random, being able to move to the top of the screen will be useful because you be able to get really close to kill them quickly Ikaruga style. The graphics do make it look like a free game though. You probably just released the demo too early cos you were excited, but there's not really enough for people to chew on. |
| ||
| I've just updated the zip again. Notable changes: 1. Title screen now displays instructions. 2. Lives remaining is now displayed using little ships. Game will not display more than 10 of these, but you can have more than 10 lives. 3. Powerups now appear, but none of them do anything yet but give you varying amounts of points, except the heart which gives you an extra life. Also there is no rewarding particle effect or sound yet when you pick one up. 4. Ship now fires at a fixed rate when you hold down the mouse button. You cannot exceed this rate by clicking fast. Let me know if this feels more fun than when you had to click to fire each shot. |
| ||
| btw sswift, your download server only gives me 70kb a sec on a 2Mb connection, what gives? Also the version I just downloaded the .exe is dated 26/01/06 and is the same as the last version, maybe you boobed. |
| ||
| I think GreyAlien is right sswift, the version i've just grabbed doesn't show the last changes. I thought it was technically fine, but a bit devoid of 'spark' tbh. I'd keep the up/down movement as it really helps avoiding stuff. Not much to add to the previous comments really, must admit it didn't really set me on fire, but nothing terrible either. Sorry to be a bit negative, but i'm sure you'd rather have my honest opinion instead of blowing smoke if you know what i mean. cheers, Mark |
| ||
| Re: Autofire. Have autofire but have a 'gun temp' meter so that when the gun over-heats, the player can only pop out shots slowly until they release the fire button to let the gun cool down. Re: collision detection. http://www.blitzbasic.com/codearcs/codearcs.php?code=1065 If you have a speed problem, then all you should need to do to correct that is check the bounding box first and then check for the pixel perfect collision if the bounding box check is sucessful. Pretty sure blitz does this internally, anyway. |
| ||
| The temp thing was done well in Jet's n'Guns. That's a cool game btw. So is Blue thingy or whatever it's called. Big10p: Thanks for the link, that's a cool method, might change me platformer to use it, maybe. The thing with the pixel perfect Blitz routines is, yes I'm sure they do do bounding rect stuff BUT I found it much faster to do bounding rect stuff externally before calling (or not calling) the pixelperfect collision. I had the logic time shown on-screen in MS and thought it was too high so optimised the collision detection as I've just described and reduced it by a massive factor. Crud I've run out of bandwidth AGAIN! I've got 1.5GB on my server per month but it's just not enough! [edit] oh it works now, weird! |
| ||
| Yeah I don't know what is up with the server, it is even making me upload really slow right now. But it's a free server another Blitz user runs that he gave me an acount on, so I can't really complain when it acts up. It just crapped out completely just now, and now I can't delete the file on the server, so I had to upload it with a new name. I've changed the link above to reflect the new name. |
| ||
| Mark: "Sorry to be a bit negative, but i'm sure you'd rather have my honest opinion instead of blowing smoke if you know what i mean." I appreciate honest assesments. It helps me make the game better. :-) Big10: I've considered that possiblity. It's something I might do. If I do it, I haven't decided if I'll use a meter at the bottom of the screen or simply adjust the hue of the ship to be more red as it overheats. I suppose I could do both as well. "Pretty sure blitz does this internally, anyway." I thought it might too, which is why I said IF you have a speed problem. :-) |
| ||
| I think the server I'm using just has very little bandwidth, and with three or four people trying to download the game at once it kills the little bandwidth it has. I was able to delete that file finally just now so all the downloads must have stopped. |
| ||
| OK played it, it'scoming along. btw in windowed mode you can't move the mouse outside of the game, kinda defeats the point. |
| ||
| If you could move the mouse outside the game, then you would be losing control of the ship all the time. You can press alt to get the mouse back or alt-tab to switch windows. And you get the cursor back when on the title screen. |
| ||
| I haven't decided if I'll use a meter at the bottom of the screen or simply adjust the hue of the ship to be more red as it overheats. I suppose I could do both as well. Yeah, I think doing both would be a good idea so that the player gets a visual warning instead of having to continuously glance at the meter. I think having an overheating gun adds a really good 'strategic' dynamic to shooters. Just letting the player autofire forever gets pretty boring, IMO.I also like chargeable weapons where you hold fire down to charge and let out a big blast when you let go - like in R-Type. You may not want this for your game, though. Just a thought. :) |
   |