Community Project - Alien Breed Remake Thread 2
Community Forums/Showcase/Community Project - Alien Breed Remake Thread 2
| ||
Currently Standing like this: Following from first thread History 06-09-2004 : Poed Boy - Added decals instead of tile splatters Rob Farley - Modified decal include to act as a basic particle system CoffeeDotBean - Added Gun flash code Rims - Added HUD and corrected player 2 strafe mode bug Rob Farley - Added the basic console for intex systems 04-09-2004 : Rob Farley - Retreat/strafe mode, when holding down fire the played doesn't change direction - Turnaround added so aliens and players don't switch from left to right they go round all available turning positions, makes it look better. - Alien media tidied up a bit - Bullet media added - Alien blood media added - When aliens dies they leave blood 03-09-2004 : Rims - Different weapons Rob Farley - Different visible bullet types for the weapons, also this type is carried over to the kill_bullet to allow for different blasts depending on the bullet type - Basic collision on the aliens so they don't run over each other, although they sometimes get stuck so this needs to be improved. 02-09-2004 : Perturbatio - Improved and fixed a couple of bugs in the editor Matt - Updated shooting and object collection to deal with clips Rob Farley - Removed offset from positioning of bullets and blasts - Added shooting of aliens, alien health and alien death 01-09-2004 : Matt - Fixed the shooting bug Poed Boy - Seperated out the player code into functions and tidied up the main loop Rob Farley - Refixed the players getting stuck at edges bug! - Added alien gfx and basic alien handling code 31-08-2004 : Rims - Blast and shooting includes (athough shooting appears to be a little buggy) Matt - Fixed players getting stuck at edges bug 29-08-2004 : Rims - 2 Player code Rob Farley - Updated temp hud - Media, added block overlay on map, added object tiles. - More Media, doors and keys now work. Door opening needs animation though Coffeedotbean kindly donated the media from his Alpha Breed project. 25-08-2004 : Rob Farley - First release, basic map editor, game engine and tileset. Both zips just updated... Come on guys... Support the community and add some code. |
| ||
| Updated code.zip Added control.bb for the starter of a better control methodology. Updated intex.bb. Added temp_int global variable for self contained functions that need to pass a variable from on to another without you bothering to pass it... crappy coding but handy. Other changes... Changed player 1's fire key to the right ctrl button. Press I to get into intex systems, there will be a console on the wall to access it, not done that yet! |
| ||
| thats 1 very fancy indx systems.. congrats. |
| ||
| very snazzy looking intex system there, rob. This is looking very nice. I get a "die you green alien crud!!!" feeling when I shoot them. Is that normal? |
| ||
| Thanks, just got to make the menus do something and make it so it gets activated when you wonder up to a terminal. With regards to "Die you green alien crud!!!" Yep! Good ennit! Note: Due to bandwidth costs I can no longer host this project. |
| ||
| email it to me rob and I'll host it as long as I can. matt at 3030deathwar.co.uk |
| ||
| Sent. |
| ||
| Ok, it's here: www.3030deathwar.com/downloads/ab/code.zip www.3030deathwar.com/downloads/ab/media.zip How shall we do this? Shall I handle the code updates, or do you want to do it and then email me the new versions? Here's how it stands (in medium quality to save bandwidth) www.3030deathwar.com/downloads/ab/standing.jpg |
| ||
| Rims, you may as well handle the code updates... I'm going on holiday next week for 2 weeks anyway so I won't be anywhere near a computer! I'm hoping to come back to a finished game!! :) |
| ||
| you cheeky monkey. Ok, I'll handle the code. I hope there's a pay rise. Where you off to? |
| ||
Ok, here's our todo list:[done] Shooting [done] Doors [done] Keys [done] Player 2 [30%] Bad Guys [30%] Bad Guy AI [done] Ammo [ ] Credits [30%] Intex Systems |
| ||
| More todos... Weapon Graphics - For when you see them on the ground and pick em up! Also we need dead people decals! Probably more but that's all I can think of right now... I'll get to work this evening and try and sort the door/editor thing seeing as I've probably got the clearist picture of that lot! Different bad guys - Extend the Alien type to allow for different bad guys, including face huggers scuttling around and stuff. This would mean the radius needs to be included in the type and probably an offset variable so the image is drawn centrally, ie 64x64 would have an offset of 32 a 32x32 would have an offset of 16 etc. Sound - There is some sound media in the original downloads from coffeedotbean but this needs to be implemented. Ammo - Needs to distiguish what weapons it's for Intex system console - Tiles for the intex systems so player can access it, this allows players to buy armour, weapons, ammo, health, etc. Maybe even sell stuff too?! More Alien media - Currently it's not animated, doesn't die etc etc. And if we made more than one alien too, also I think we need static bad guys too like auto cannons etc. More Player media - Personally I think we can cut half the animation frames out and you'd not notice, and use the spares for death and pain animation. Extend Editor - Need to add an extra layer for placing bad guy spawn points, ambient sounds, animated decals etc. Doors - Currently any key will open any door, using the extra map layer mentioned each door could have it's own unique ID and key, or indeed, a common ID |
| ||
| Little update of the decals.bb This seperates the updating of the decals and the rendering. This is needed so the timing all works correctly. It replaces the existing decal_drawall function. This means now you have to add.. Decal_updateAll() Just after: handleblasts() handlebullets() update_aliens() Some more thoughts... The alien type should have a flag to say if the alien is in pain or not so when it gets to the rendering of the alien sprites you might have a pain animation frame to render instead of the regular animation, I think that would look good. Once it's rendered the frame it sets it to false, or indeed instead of a flag it is a number that counts down if it's >0 and whilst the number is >0 the pain frame is shown. |
| ||
| I guess you should kinda slow down its movement at the same time, so you can kinda 'hold back' the aliens with your machine gun fire. Maybe if each weapon had a 'blast power' you could make the aliens recoil against the bigger weapons... |
| ||
| I've not downloaded yet, but really want to support this... My idea I'd like to add in is a "fog of war" type effect, but want gauge opinion first. Essentially, you can see where you've been and the up to walls / doors enclosing your current location. On opening a door, the visible area is extended into the new area. You can see anything on visible stuff, but nothing on non-visible tiles. (Note that I'm not proposing we actually implement line of sight stuff for the player) This will be pretty easy to add (will try to do it tonight when I get home from work), and I think will be pretty cool in the game. It will add an element of suspense / surprise when opening each door - will you find a horde of monsters or a bag of gold in the cupboard? Another thing that'll be easy to add (with the way I'm thinking anyway, without looking at the code!) is to enable the intex systems to show the full level map. I'm thinking a 'security' section in the intex, which needs a password to access. The password will (ultimately) be found as a pickup somewhere in the level. And a 'map' key in game as well to show where you are / have been. I'm thinking (again without touching the code) that a scaled down version of the existing graphics engine ought to do the trick... Thoughts? |
| ||
| JimBob, I had the same thought, the aliens already knock backwards a bit but I think if you had a massive 8 ball gun that twats them down a corridor that would be pretty cool! Mark, Sounds reasonable, I've though about vision systems of sorts, based around where the player(s) are and then basically flood fill until you hit collision blocks. They way to implement this would be add an additional layer on the map of simply "Can I see this block?" if you can it's set true then it draws it if false then not. The hardest thing I think would be when do you recalc your view? Probably every time a door opens? Anyway, you're more than welcome to add it! Intex systems are going to be pretty much everything that isn't in the basic gameplay, shop, map, ping pong game, whatever you care to throw a stick at, there's no reason not to extend it massively. Access codes and stuff in there would be handy for opening doors (to secret areas) you can't get passed. |
| ||
Here's a dead body for you folks. Did it for fun to test out the demo of openCanvas 3.0. It's not the corpse of the player, just someone you can scatter around the place...feel free to modify the poor sod. I may do some more stuff if I find the time. Tested the game the other day, and it looks cool so far. Personally I would prefer to aim with the mouse, so I could strafe using the left and right keys...but of course, then you couldn't do a split screen mode. Cheers, Ragnar |
| ||
| Created a particle system to replace the decal.bb file, this one deals with animated textures and other stuff! Particle.bb Updated alienhit and aliendie functions Download the Particle gfx here. These need to go in the particle dir in the gfx folder. In engine.bb - Put draw particles here. drawmap(ScreenX,ScreenY,1) drawparticles() drawmap(ScreenX,ScreenY,2) drawbullets()And put updateparticles() here handleblasts() handlebullets() update_aliens() UpdateParticles() Any other decal references need to be removed, but I think that's got the lot. |
| ||
| Rob, yup that method was exactly what I was thinking - I knocked up a little test in excel at lunchtime (at work) based on flood-filling when you open a door, seems pretty straightforward if I 1) assume there'll always be a 'solid' wall round the outside of the map (which seems reasonable, else the player could wander off...) 2) allow 'vis' to seep through diagonals. I don't imagine this would be a problem, as maps with diagonally aligned 'solid' walls will look a bit funny anyway, and probably only apply to 'pillar' type walls, in which it makes sense that you can see through them! Will get on to it now... |
| ||
| Mark, one 'problem' I've thought of... Your flood fill will have to flood one block further than the collision (ie include the collision boundry) otherwise you won't see the walls. |
| ||
| New Aliens.bb Aliens now have a bit more AI, they have an added field called mode that is the AI state they are in. They will now only attack if they can see the player. They will stop attacking if they lose sight of the player. If they get shot at they will attack with vengence!! |
| ||
| Hrm... if they lose sight of the player? So if you stand at a corner and fire... duck behind the corner... they lose sight and go back to what they were doing? Should maybe have a timer on that. If they lose sight for more than a few seconds maybe....... Just an observation. |
| ||
| Kanati... If they lose sight of a player they still keep heading in the direction they were going, but yes, the AI is still crap... but getting there. |
| ||
| Rims, hang on, I've just finished my base fog of war code, incorporating all changes up to Robs last one. My changes are quite invasive. I'll add in robs aliens change to my stuff and upload; will post again in 5-10 mins... Rob, yup, had already figured that I needed the first boundary. The base version does 'the bare minimum' really; by just finding the first boundary you lose some of the neat extra detail within some boundaries (vents near start for example). Will need to work on that. Also not convinced about a pure black background for non-visible, but not sure what else to do. One good side effect is aliens in areas not visible don't need to be updated, so that can massively reduce AI, etc going on. |
| ||
| Rob, I think you've been testing it with debug off, because I keep getting array errors in the aliens.bb->update_aliens() function. I think the tile check is being given the wrong coords. This works fine with debug off. I've modified the gettile function so this doesn't try and access a wrong dimension in the array. I've updated the code.zip. Get it in my sig. |
| ||
| doh! Can you integrate this version into your code, Mark? |
| ||
| gah! Ok, I'll drag my code out of my zip and stick it into yours. Gimme 20 mins... |
| ||
| sorry dude! |
| ||
| No problem: Here it is incorporating all above changes -> *clicky* I've done a bit more tidying of files: added map.bb and util.bb - engine.bb is now almost purely the game loop. vis is in, although possibly a little basic. Note that the map is obviously still a test map so 1) it takes ages to check vis on startup in debug mode (very minor delay in non-debug) due to the massive visible area, and 2) you might find areas where you *think* the vis has screwed up, but it hasn't, it's the map. ;-) I can't see any noticeable delay when checking vis on opening doors, although it's conceivable on larger areas. Once we start designing proper maps (or even just setting up a decent enclosed/small area start point on this map) this will go away by making sure our maps are sensible. Unforunately it doesn't immediately give the 'suspense' feel I thought it would, but again, I think that's the map, not the principle. I'm not sure about the fully black background for non-visible areas. But I don't know what to replace it with. I think we also need to consider the fact that my code is currently limited to just seeing one block into 'solid' objects. You can no longer see the vents in the walls near the start, which is a shame. Not entirely sure how to address this one though...maybe non-visible areas should be covered in 'roof' tiles until they are visible, and we class the wall detail the same?!? A neat side effect is that aliens now don't do anything until they are visible, which should help us when designing maps and piling huge numbers of aliens in different rooms - they won't impact performance (much) until their door is opened... One feature request from me though: animated backgrounds. stuff moving behind those vents. corpses that twitch every 5 minutes. Just enough to make you think "did I just see that, or...?" And more constantly animated stuff - intex systems ought to animate, plus fans, maybe flickering lights? |
| ||
| Mark, animated backgrounds already thought of that, it'll be an extra map layer that will hold additional info like sound emitters, spinning fans, alien positions, that sort of thing. Regarding the vis, maybe it should just spread onto top-of-wall blocks? (80,81,82,83 and 5) this list may increase so we'll just have this as an exception. A bit crap but should do the trick. I'm not a big fan of hard coding this sort of thing but I don't think there would be many more expections? Bit more splatter: Updated alien die updated line on particle Global alienblood = LoadAnimImage("gfx\particles\splatfade.png",64,64,0,8)New particle media |
| ||
| Nm, I got it to compile. I'll see if I can come up with something. |
| ||
| Updated test.map to work with the vis better Also spotted that the check vis is called every time the open door is called, the problem with this is that the open door is called recursively so vis is checked several times for one door, without checking the code is this going to have any major impact? |
| ||
| Agreed with the animated things. I think rob's noted this. I like your implementation of the fog. It gives me a sense of suspense, but like you said, this can be hightened with a good map. I've added an animation include. This replaces and implements blast.bb. This will allow you to put looping animations in the map at coords. Functions: ; create an animation using this image ; at these coords ; running between these frames (s -> e) ; an looping "loop" times. loop=-1 means infinitely. Function createAnimation(image,x,y,sf,ef,speed#,loop=-1) Updated the code.zip to contain your updates. |
| ||
| Updated opendoor function to only check vis once. |
| ||
rob your particles are having a problem with these lines:range = p\lastframe - p\firstframe life# = Float(p\totallife - p\life) / Float(p\totallife) frame = range * life frame = p\firstframe+frame If frame > p\lastframe Then frame=p\lastframe If frame < 0 Then frame=0 DrawImage p\graphic,p\x-p\offset-ScreenX,p\y-p\offset-ScreenY,frame specifically the frame. Image frame out of range. I tried doing some error checking with the last three added lines, but it doesn't help. |
| ||
| What's the problem, I don't get any errors? Anyway... Time for bed... It's 00:13 and I've got work tomorrow! |
| ||
| I'll update the code.zip tomorrow. I'll go for your method: update once at night... maybe twice. This is looking nice. We need some graphics though. I know I'm crap at graphics. |
| ||
| Rims - Thinking about the particle system problem, I'm assuming you did download the new Particle.png media? That had an extra 4 frames in it. If not, then you'd run out of frames. [edit]Looking at your code it doesn't look like you changed the number of frames when loading the new graphic.[/edit] |
| ||
| Rob, I had decided that the recursive opendoor vis check wasn't a problem - if any connecting tiles have already been marked as visible, they're not checked. So the first opendoor does the full CheckVis, and subsequent ones enter and exit CheckVis just once (as all surrounding tiles are already checked); so I didn't see it as an overhead. Doesn't matter as you've prevented that little inefficiency anyway. As for the central wall blocks, this isn't as simple as it ought to be. You could floodfill vis the internal wall tiles every time you hit a solid wall, but this could make large sections of a level visible when you don't want it to. I'm thinking (top of my head at the moment) that the collision layer could have 0, 1 and 2 (if other values aren't already used? I'm at work). For normal collisions, anything other than 0 means a collisions. For vis checks, only 2 counts. This does mean an extension to the map editor, and we'll have to specifically mark out vis sections. But I think it would solve this problem...will mull it over whilst pretending to work today... |
| ||
| Mark, the vis thing is really cool so we need to make this work,. The idea of the tristate collision could work, what if central blocks were marked as type 2? So when the flood fill hits the edge it check surrounding blocks for type 2s, if it finds any type 2s it flood fills the 2... Hmmm... Actually that won't work unless the map is specifically design for it... Also I noticed where I've put a locker or something similar against a wall this causes problems as you end up with a black block in the middle of it... ... hmmm... Yes we need 3 states of collisions... Players will hit 1 or 2s but vis will only hit 2s. I think that should solve the problem. [edit] This is exactly what you said isn't it! Doh, yes I agree! [/edit] Something else, I've mentioned it a couple of times already, but I think with the vis added we will need more doors, so we should either have some doors that are keyless, or security levels on doors so you get the basic level security that opens up a few doors and later you find higher security level passes to get you further into the map. Obviously you'd still have your red, green, and blue keys for special doors. Thoughts? |
| ||
| Oh, something else as a fairly urgent todo before we get carried away with all these fx... Improve collision on weapons > aliens Add player health and lives When alien hits player causes pain on player. Also some more thoughts... I really think we need more rotation animation, I think we could probably lose half of the animations we've currently got and use those to produce in-between rotations (22.5 degs), I just think it would make it looks much smoother. Discuss... |
| ||
| Had a thought on an algorithm for the vis thing that I think will work. Please discuss before I get home and start coding tonight (8 hours from now!)... 1) Do the vis as currently, but add all newly visible wall blocks in a new wall_vis_list. 2) Once normal vis is complete, work through each item in this new wall_vis_list 3) From each of these tiles, 'draw' 4 lines (up, down, left, right) outwards until you hit a) a non-internal wall tile, b) a lit block, or b) the edge of the screen 4) If you stopped at the edge of the screen, or an already lit tile, all intermediate tiles are lit. Add all of these to the wall_vis_list to check. Note that hitting a non-internal wall that isn't lit means no tiles get lit. 5) repeat until you've checked all tiles in wall_vis_list The only 'minor' problems with this are: 1) As soon as you hit a room on the outer edge of the map, all internal wall tiles around the edge of the map become visible. However, I'm not sure this is too much of a problem, as it helps players visualise the level size. 2) If you have a 'secret' room completely surrounded by rooms you've already been in, it will be obvious that there's something there (because it's black, not filled in). However this would be a problem with the collision layer=2 model too, and would only be 'fixed' if we covered mom-visible areas with a default 'roof' tile. It's also a neat feature IMHO, as astute players will spot such unexplored areas on the map (when I implement it!). I think this works (having played with a simple map in an excel spreadsheet!), and avoids us having to predefine vis areas, which I really don't like the idea of. (predefined vis areas is really what we mean by a new '2' collision layer state). Too much potential for error, and we ought to try to avoid it if poss. Agree we need to sort some fundamental stuff out. player / alien collisions for one. player & aliens extremeties overlapping walls for another (this is a problem when going under the netting near the start of the level, your gun and alien arms stick out the sides). And damage / lives to actually make this a game! I also want to get a map display in, if only to make sure the vis stuff really is doing it's job! At some point we'll need to think about story / structure though. I'd quite like to see a (slightly) rpg feel, going to different locations rather than just getting deeper into one 'dungeon'. And based around buying / selling / finding upgrades, rather than full on stats based crap. Intex systems can provide the latter, but we'll also need notes / documents as pick ups (if only to provide the pwd to get the full level map off the intex). I've got a few story ideas rumbling round in my head, I might put something in a doc later today. Somehow try to avoid the cliches... |
| ||
| I don't see unseen blocks being in the middle of maps as a problem I think it would make people say... "How the hell do I get to see that bit, what's in there?" Without thinking too much, that sounds like a perfect reasonalble way of going about the vis, and I agree with the predefine vis. I agree there should be plenty of puzzles to solve, I liked the old 8 bit arcade adventures where you had to pick up the plunger, wire and dynamite then use all 3 to blow up a door for example. Or you find the access pass to get into the computer, etc etc. I like the idea of this being more of an adventure rather than a straight alien blast. Regarding the deeper into the dungeon feel, if you played Alien Breed tower assult that was cool, you had an area of play that had several building in it, each one had it's own theme of sorts although they all had the same feel. I liked this as it gave you a non-linear game and you could explore the buildings in pretty much any order you wanted if you'd found the right access passes, or got a generator working etc etc. |
| ||
| Tonight I'm going to write a sound library, so no-one else do that! I've got the idea that you just throw sounds at it and it deals with if you can hear it, where to play it etc etc. Also it'll check for sound emitters and if you can hear those. How many sounds playing at the same time etc etc. Anyway... I'll do it tonight! |
| ||
| Story's coming along nicely, I hope you'll like it, but you'll have to wait until tonight ;-) I'm afraid there are a couple of cliches - unavoidable with the genre really. But several twists. Even if we never implement what I produce, I think it will at least spark a few neat ideas for features / tiles / maps... I agree with the 'freedom' / 'non-linearity' ideas above, have some degree of that incorporated. My concept is of a story driven blastfest (as opposed to a pure blastfest!), so although there is occassional story telling (in game), including an upfront tutorial / intro level, it's kept to a minimum unless you decide to read every note / book / intex email you find... ;-) |
| ||
| Basic sound include: Because this sets up an array this include needs to be included before other stuff. Blitz is funny like that! This include is only for one shots not for sustained sounds... I'll deal with those later! Get the sounds from the alpha breed download in this thread and put them in an sfx directory. Alien.bb update to include a bit of sound: |
| ||
| Ok, so here it is -> Possible Story It's very ambitious, and I certainly don't suggest we try to build all this now. Or even at all. I don't know that we'll ever get that far. But to make a true game, we need something to aim for, and even if we discard the above completely, it serves to provide a context within which to design a new tileset and maps. It also shows up a few more potential todo's: 1)Documents lying on the ground which are read when picked up 2)Intex system to give access to individuals emails (logons on the documents), which not only develop plot but provide access codes to some doors (to ensure players get the key plot emails!) 3)'Alien' types that you shouldn't shoot (NPCs) 4) Limited conversations with NPCs (i.e. no interaction, trigerred by entering a room / killing all aliens / boss energy level being low) 5) Level structure / completion conditions / in between level media 6) Reward structure such that shooting only aliens (not real humans) is rewarded (maybe a 'hero' rating?) However, as Rob has stated before, we need to get some more core elements working before we tackle many of those. But how's that for starters? (And I'm quite happy to be shot down and told this is crap, and for it to be thrown away at some point. Hopefully it will at least have served the purpose of igniting discussion and fuelling further ideas...) |
| ||
| I'll be up on this tomorrow guys. Wow, mark, I LIKE the story. Very nicely thought out! |
| ||
| ta. now we just gotta make it... ;-) There's a bug somewhere in the alien logic I think. If I stand still (or not) for a while (10 secs), an array index out of bounds occurs in gettile. I'm guessing it's the alien AI for roaming, but haven't had a chance to check it out - almost there with the vis... ...speaking of which, can we move all 'internal' wall block to a set location in the list (beginning, middle or end, just together somewhere) to simplify my vis check. 'fraid I don't have to do it myself right now... |
| ||
| Guys, I sent an email to a guy called Zeb who does alien fan art, I got an email from the guy who runs the site saying that Zeb is a nice guy and will probably say yes to using his pictures, or maybe... just maybe he might do some for us. I said it's a freebee game so we can't pay anything but will give as much credit or links to sites as he wants... Anyway... here's a link to some of his stuff: http://www.brian-oshaughnessy.com/alien/Fan-Art.html I thought it would make great inbetween level images with the briefing appearing over the top. Regarding the story... Not sure how much of this investigation should happen by the player and how much should be narrative. I think if you try to have too much thinking work in the game it'll slow it down. Having it as a narrative would keep the action of the game in place but still maintain the plot without slow bits. I think you've got to have one or the other, I don't think a blastathon followed by basically a point and click adventure (or there abouts) will work, and it'll make the game engine complicated as hell. I do like the story though, I just think the more complex parts (investigation and so on) need to just be told rather than explored by the player. Also, you've got to take into account the two player mode so it's potentially not one man against the world, it's a team. So maybe you could have a crack team that go down and have a set piece where most die, all except one or two? Just my thoughts. |
| ||
| Story: Space baps. The End. |
| ||
| Like the set piece bit. My thinking on how the narrative would unfold is a small number of key documents / emails / conversations that *must* happen (i.e. they unlock a door / ending for a map), but have other supporting stuff if you go looking. I'm thinking just one or two key things per map - and some maps might simply be blastfests with no key info. Anyway, here's an updated vis. It's not *quite* right (try adding a building with 4 rooms in and thick internal walls and you'll see). I've run out of time tonight, will fix tomorrow... Again it's a little slow, but let's see where this goes for now... |
| ||
| I'm all for adventuring, finding keys, security passes to get through the level. I'm just thinking with emails and things you don't have to do anything about it, it just happens. This needs more discussion... Ideally down the pub... Anyway... time for bed said zeberdee! |
| ||
If your getTile() function doesn't have these lines in it, add them. They check for out of dimension calls. You should also add these lines to putTile() as well.If x < 0 Then Return If y < 0 Then Return If x > 7552 Then Return If y > 7552 Then Return I'll upload the code and new media in 10 minutes. |
| ||
| ok, updated. Check in my sig. |
| ||
| Made some changes to descrease the players health: In Player.bb: Player Type: change health to health# Add to global variables: Global playerHealthDecrease# = 0.1 ;used to determine how quickly the player loses health when touched by alien In Player.bb - Player_UpdateAll ;Check player health If pl\health = 0 Then ;TODO: Death of player End If In Alien.bb - Update Aliens
; check collisions with players
For pl.player = Each player
If mr And circlesoverlap(al\x+2,al\y,al\radius,pl\x,pl\y,playerradius) Then mr=False
If ml And circlesoverlap(al\x-2,al\y,al\radius,pl\x,pl\y,playerradius) Then ml=False
If md And circlesoverlap(al\x,al\y+2,al\radius,pl\x,pl\y,playerradius) Then md=False
If mu And circlesoverlap(al\x,al\y-2,al\radius,pl\x,pl\y,playerradius) Then mu=False
;Check for player damage
If circlesoverlap(al\x,al\y,al\radius*1.2,pl\x,pl\y,playerradius) Then
pl\health = pl\health - playerHealthDecrease
If pl\health < 0 Then
pl\health = 0
End If
End If
Next
To alert some aliens of a player's presence, you could add some trigger fields on the map - ie. around doorways. It's really starting to come together - you guys have done a great job! |
| ||
not bad so far:09-09-2004 : Rims - Changed rob's .wav to .mp3 in the sound lib. - Added pickup of key and health sounds in player.bb as well as shoot sound - Moved sounds to sounds.bb file - Added player hurt sound to aliens.bb - Moved code effecting player's health to player.bb -> Player_affectHealth(p.player,h) Matt - Added player decrease in health (aliens affect player) 08-09-2004 : Rob Farley - Added a sound lib. Added to util.bb - Updated alien_hit with sounds. - Added media from coffeebean's alien breed alpha. New media.zip Coffeebean Very, very useful sound media Mark Tiffany - First version of story. - Updated vis function. Rims - Added a version const so we know where we are. - Hold down space to see alien states. 07-09-2004 : Rob Farley - Particles.bb added replacing decals.bb - Updated alien.bb->alien_Hit and alien_Die functions - New particle media added. - New alien states. - Updated openDoor function. - Modified test.map Rims - Added animation.bb for animation loops. - Changed the history.txt to be more readable. Mark Tiffany - util.bb and map.bb added for more code separation - Main routine formatting tidied (indented!) - Added map visibility. Updated at start and opening doors, alien code also uses vis to determine who gets updated Rims - Added alien kinds and radius+offsets. - Updated alien_drawAll to accomodate new alien drawing. As soon as we get some new face hugger media we can get them drawn and moving around. - Updated the getTile function (error checking) 06-09-2004 : Poed Boy - Added decals instead of tile splatters Rob Farley - Modified decal include to act as a basic particle system CoffeeDotBean - Added Gun flash code Rims - Added HUD and corrected player 2 strafe mode bug Rob Farley - Added the basic console for intex systems - Added control.bb, outline for better control methodology 04-09-2004 : Rob Farley - Retreat/strafe mode, when holding down fire the played doesn't change direction - Turnaround added so aliens and players don't switch from left to right they go round all available turning positions, makes it look better. - Alien media tidied up a bit - Bullet media added - Alien blood media added - When aliens dies they leave blood 03-09-2004 : Rims - Different weapons Rob Farley - Different visible bullet types for the weapons, also this type is carried over to the kill_bullet to allow for different blasts depending on the bullet type - Basic collision on the aliens so they don't run over each other, although they sometimes get stuck so this needs to be improved. 02-09-2004 : Perturbatio - Improved and fixed a couple of bugs in the editor Matt - Updated shooting and object collection to deal with clips Rob Farley - Removed offset from positioning of bullets and blasts - Added shooting of aliens, alien health and alien death 01-09-2004 : Matt - Fixed the shooting bug Poed Boy - Seperated out the player code into functions and tidied up the main loop Rob Farley - Refixed the players getting stuck at edges bug! - Added alien gfx and basic alien handling code 31-08-2004 : Rims - Blast and shooting includes (athough shooting appears to be a little buggy) Matt - Fixed players getting stuck at edges bug 29-08-2004 : Rims - 2 Player code Rob Farley - Updated temp hud - Media, added block overlay on map, added object tiles. - More Media, doors and keys now work. Door opening needs animation though Coffeedotbean - kindly donated the media from his Alpha Breed project. 25-08-2004 : Rob Farley - First release, basic map editor, game engine and tileset. |
| ||
| Certainly not bad for 2 weeks work! I've actually signed up to a couple of extra forums after seeing these referrers from these sites to my site... http://forum.team17.com/showthread.php?p=308676#post308676 http://www.lemonamiga.com/forum/viewtopic.php?t=354 Anyway... I've only got one more night of work on this before I go away for 2 weeks... I think I'll have a go at the face hugger! |
| ||
| I've tried but I'm so crap at graphics that it looks almost cute and cuddly scuttling around. |
| ||
| ok, I've made a pretty drastic update to several files, I started keeping a changelog, but there was a helluva lot to change to get this to work: Added a new layer type to the editor (hit point layer) this allows you to create destructible objects (at this point, only doors) I had to modify a lot of the files to get it working, too many changes to list here. You can download a zip with all the code files here I created a new include: consts.bb this contains easy to read consts instead of hard coded values all over the place. Not all the relevant code has been updated to reflect this, but I'll eventually get around to it, just wanted to post this to make sure I get it in before someone else updates. (to adjust the hit points for a section, switch to hit point layer, left click to increase value, right click to decrease, hold left ctrl to inc/dec by 5) *EDIT* oops, forgot: Use middle mouse in map editor to set a dynamic collision object *EDIT* in map.bb, add the following to the bottom of the select clause in Function DamageTile ;default action for any other destructible object Default Map(x,y,LayerObject) = 0 Map(x,y,LayerCollision) = 0 |
| ||
| I'll be back in a few hours and have a look. |
| ||
| Ok, it's all updated. Check the sign. |
| ||
| Ok, a very basic map. I needed this to think about vis rather than anything else, and it needs work. But I thought it worth posting anyways... First up, you need *this* new file: gfx/tiles_small.png. I'm sure we could generate this on the fly (when loading the big tiles), but this ended up being simplest. In engine.bb, where tiles are loaded, amend it to read as follows: Global tiles = LoadAnimImage("gfx/tiles.png",32,32,0,maxtile)
Global tiles_small = LoadAnimImage("gfx/tiles_small.png",16,16,0,maxtile)
Global objects = LoadAnimImage("gfx/objects.png",32,32,0,maxobject)
MaskImage tiles,255,0,255
MaskImage tiles_small,255,0,255
MaskImage objects,255,0,255and in the same file, where the keyhit checks are at the end of the main loop, add this: If KeyHit(50) Then showmap(1):time=MilliSecs()-period ; M In intex.bb, in the Intex() function, amend the input code to look like this: itemno = intexmenu("Testing|Testing|One|Two|Download Map|Exit",150,itemno,player)
If control(pfire1,player)
If itemno = 5 Then
;TODO: request password for map
; light up everything
For x=0 To 255
For y=0 To 255
map(x,y,LAYER_VISIBLE)=1
; TODO: Consider setting mapped but unexplored areas differently to show them as such on the map?
Next
Next
;TODO: ought to visibly confirm the map has been downloaded (or not)!
End If
If itemno = 6 Then Exit
EndIfOn the way, a little 'bugfix' that helped out: in players.bb add this line to the end of player_create()... Player(id)=pl In map.bb, replace drawmap with this: And finally, also in map.bb, add the new showmap() Which is kinda handy. However, it has proven to me (along with several test maps*) that I don't think we can use dynamic vis - I think we need pre-calculated vis blocks as discussed above. I may be able to reuse my current code however to 'guess' those vis lines for you in the editor, so maybe all is not lost. Will try to fix this over the weekend, but am away at the in-laws... *If you're interested in maps that screw the vis, create a large building in the middle of an empty map with thick internal walls. Divide it into 4 rooms with a big +, making sure the centre of the plus includes lots of internal walls. Play it. You'll be able to see the outline structure of the building *and* the internal walls. There are other problems too (put more structure around the outside and you'll see), but this was the one that broke the camels back for me... |
| ||
| Time for a new thread? |
| ||
| Absolutely... |
| ||
| Rims... Did you get my face hugger gfx. |
| ||
| Yeah, it's in there. Did you get my mail? You couldn't have a look at the code. Specifically: aliens.bb->Alien_DrawAll(). I've cludged the face huggers walking around. |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=38223 |
   |