Damn that's spooky, I was thinking something along those lines.
I imagined a large cyborg production facility stamping out an army of cyborg soldiers. Each one fitted with a power plant capable of supporting life on a small planet. The power plant enables (through E=mc^2) the creation of ammunition in real time, which feeds the cyborgs arm guns. That's right instead of arms the cyborgs have heavy duty firearms (no pun intended)!
Suddenly malfunction. The cybernetic leg formation process has gone wrong and a cyborg rolls off the production line without the use of his legs. Immediately the automated systems jetison him for scrap (raggy doll style). However the cyborgs onboard computer (intel based pending sponsorship tie in) starts to compensate for the lack of motive power in his legs by dramatically increasing the firing rate and bullet mass of his arm guns. Effectively allowing our new hero to manouver through the conservation of momentum principle. By utilising both arm guns and a full range of 360 degree movement in each shoulder joint he has to fly, slide, recoil and fight his way back through the facility to shut it down for good.
I always think the best way is the Metroid way, which is why I want to try Kid Icarus.
I reckon you could do something interesting with a single analogue stick, involving rhythm... a rocking from side to side style movement thing, instead of just pressing left, you start left, swing right and so forth... then a fighter style half arcs and up downs, to perform tasks, within a fairly standard 2d platform environment.
Similar to the reinvention you get from Jungle Beat. But with a stick.
Hmm sort of like Rag Doll Kung Fu, which I have to say was dissapointing largely due to the control being totally non instant.
I want instant control, as soon as I nudge the stick in a direction he should start firing in that direction. Possibly distance of stick from centre position might dictate rate of fire. Haven't decided whether that's over egging it (probably is).
You don't move by firing at the ground. You jump by firing at the ground. Allow me to give some examples. Imagine the number pad of your keyboard is an analogue stick, 8=up, 1=down-left etc. etc.
4,4 fires left, but due to recoil pushes him right
6,6 fires right, but due to recoil pushes him left
4,8 or 8,4 fires left, but due to the increased force pushing him down roots him to the spot so he doesn't move
2,2 makes him fly up in the air.
3,3 makes him fly up and left into the air.
It's basically the complete oposite of the norm as you can only move towards something by firing away from it. Level design and enemy placement will need careful planning and adjustment accordingly. So basically you could do a 1,1 to launch yourself up and right then carry that momentum forwards carefully controlling your trajectory with the guns. Maybe holding one stick in the 4 position to provide some forward thrust whilst gunning at a target on the ground with the other stick in a 3 position.
I think it would be mind meltingly complex and yet allow for a skilled player to develop their own subtle variations. You have to think of the guns as both weapons and thrusters simultaneously.
Plus our hero is dissadvantaged to some extent by this restriction in movement, which might make for some interesting confrontations with some fully working cyborgs in the later levels. We'll probably never know.
Am I mad? Oh and explain the Kid Icarus thing to me. I have it at home on NES, but never played it.
Small hitbox - absolutely essential. The hitbox will basically be the circular area where the arms pivot from. A hit there will cause the arms to fall off and spin wildly out of control still firing and taking out enemies. Whilst the rest of him crumples to the ground.
I like the sounds of that... I remember reading alot about Star Fox... and as we know that is perfect blend of control and level design... something that is sometimes forgotten. You can have perfect control, but suffocating, useless level design. The native English speaking guy who made the Star Fox engine said that the Japanese level designer, whose name escapes me, was properly insane over level design to the point of never sleeping... or some such. I'm sure thats a complete injustice.
From what I've read, Kid Icarus is billed as a blend of Super Mario and Metroid... which sounds unbeliveably good, its on the VC, but I'm on a game purchasing hiatus... I've waited 15 years a few weeks or months wont hurt...
So would disabled cyborg adventures... DCA... be a single screen puzzle affair? because me and paper went through Megaman the first one and that was very much a single screen puzzle, then next screen and so on... the technology controlled the game and it was kinda nice to know that you had a screen to get through or a series of screens... that kinda tangiable progression is what I like.
I reckon you could do something interesting with a single analogue stick, involving rhythm... a rocking from side to side style movement thing, instead of just pressing left, you start left, swing right and so forth... then a fighter style half arcs and up downs, to perform tasks, within a fairly standard 2d platform environment.
Second thoughts that could work in a Jet Set Radio graphitti sort of way where you combo moves together by swinging the stick as opposed to pressing a button. Could be really interesting if implemented well.
You could have wires that's whip out of the bottom of his leg-less torso and latch onto certain objects scattered through the game that allow him to use them for movement for a limited time (a hovercraft fan for example). You could then be able to use his arm cannons only for attack, basically spinning the controls system 360 (firing left no longer makes you move right allowing you to attack into an enemy instead of sending you away from them) - could be a real headfuck!
______________________________________________________________________________ When's 'Wii Carlton' coming out?
So would disabled cyborg adventures... DCA... be a single screen puzzle affair? because me and paper went through Megaman the first one and that was very much a single screen puzzle, then next screen and so on... the technology controlled the game and it was kinda nice to know that you had a screen to get through or a series of screens... that kinda tangiable progression is what I like.
hmm originally I'd thought of it as a multi-directional scroller, but with suitably dinky sprites and the obvious need for you to be 100% aware of what's waiting for you when you make a move then it probably would work better as a fixed screen game. I think Megaman stayed flip screen for some considerable time. Megaman4 is a flipper iirc.
You could have wires that's whip out of the bottom of his leg-less torso and latch onto certain objects scattered through the game that allow him to use them for movement for a limited time (a hovercraft fan for example). You could then be able to use his arm cannons only for attack, basically spinning the controls system 360 (firing left no longer makes you move right allowing you to attack into an enemy instead of sending you away from them) - could be a real headfuck!
A sage like suggestion and one I'd toyed with for a bit. I envisaged Dual Shock style control, clicking in either stick to launch and disengage a grapple line. I sort of mentally parked it as an idea as it seemed to me to add yet more complication on something which was already going to be high concept and alien to normal people. Maybe as a time limited powerup it could work or maybe it's something to save for Dissabled Cyborg Adventures 2.
Have you lot played Lethal Application? It's a 2D vertical scrolling platform shooter where the movement is fairly similar to what you're describing, but more simplistic.
If you haven't, I'll record some footage to show you what it's like.
Don't you just hate it when someone has already implemented your ideas :grrr
Tell me about it, I thought I was gonna die a very rich man when I came up with Nutchos the worlds first Nacho Cereal - the Mexicans were gonna flip for it!!! Poxy Nestle and their evil brain spies and time travel machines...
Using pygame I have the very bare bones of a working prototype of "Disabled Cyborg Adventures", which now comes under the working title of "Fire Arms". So far I have the twin stick thrust shooting mechanics more or less there, but I have to add in some friction and inertia to aid player control as it's all a bit floaty at the moment, plus I need to do some tweaking on my bullet/player mass ratios and rate of fire. I've sort of fluked a set of values that make the player character pretty manoeuvrable, which is cool.
There's also an annoying 'not dropped' referencing bug, which means that shots that go off screen aren't destroyed and garbage collected by the python interpreter. I can get around that by putting in some walls all around the edge of the screen, since collision detection and bullet removal works fine for these elements.
next steps are to implement some enemy behaviour. So far I have one enemy type (a fixed gun emplacement), which doesn't fire, so I need to get some enemy bullet sprites in there and some rules as to how these should work. I have some ideas for other enemy types too and a couple of scoring handles that will require the player to think about their approach to a level somewhat in order to maximise score.
Once that's done then I need to write some code to parse some level files into walls, platforms and enemies then get busy scripting some levels. Since this is all prototype stuff I'm working on a fixed screen (window) resolution, which is a bit pap, but then this isn't for public consumption really. Also I'm not sure how the game will react to a different controller (I'm using a PS2 pad through a magicbox). In theory pygame should sort this out, but there might be some oddness with different joystick axis if, for example, I plugged in a USB 360 controller (which I don't have).
Graphics are all horrible place-holder stuff that I've put together in inkscape and then exported to bitmaps at various sizes. So far the player sprite is just a box with a circle inside, so he'll need some work, frankly though I'd rather spend the time tweaking the gameplay and level design.
Also there's no sound, music, explosions or sprite animation as yet, just a mass of bright cyan and magenta bullets that you can fire in glorious sweeping arcs across the screen. I'm genuinely quite pleased by the control. It requires a fair amount of mental gymnastics to use the guns for thrust and attacking, which was always the intention. Once I have a full level put together I'll need to give it some proper play time to see if the controls click in with prolonged play.
That sounds great! I've never heard of Pygame before, I really would love to try something like this. I'm so sick of working myself half to death for Future, I want to try something creative for a change. Using your guns as means of moving your character is a great idea, I demand vids when this is done!
I already knew a bit of Python, which is a really easy programming language to learn imo. Pygame is a library for Python, which has most (in my case all) of the functionality needed to build a game. No doubt there's been a learning curve to go through, but last night I made a hell of a lot of progress in a very short amount of time (after several nights of slow and frustrating coding). I don't think you'd use Pygame to build a full on game for public release, but for quickly prototyping something this was the obvious choice for me as I was already aware of Python syntax to a degree. It made it relatively easy to get what's in my head into something that I can demo to get the central ideas across.
At this stage I've not gone for a scrolling game. Fixed screen is much easier for me to build as a first project. This also means I have to come up with some very compact and tight levels to try out some ideas for different enemies and scoring opportunities. I want the scoring to be a little bit like Bomb Jack, where the order in which you approach things is very important. This means you might need to work your way past some enemies to kill one that's a way off to maximise score. I can work this through the different coloured bullets (cyan for the left arm and magenta for the right). This way I could build in some colour based scoring options and/or enemy shields that are colour coded. I'm a way off getting any of that going though and might change my mind completely and take it in a different direction altogether.
I didn't make much progress last night. I've got some irritating collision detection bugs due to the way in which a sprite jumps from point A to point B it means it can pass through an object far enough to teleport to the other side of it. This requires a significant rethink on how to approach collision detection as I need to store the old position of the sprite (trivial) and use that information together with it's new position and what it has collided with to dictate what should happen.
I aslo tried to get some enemy bullets up and working last night, but there's a bug that's stopping them from being drawn to the screen, probably something dumb.
I created a score class to keep track of score and multipliers. My code is getting quite long now, time to split out parts into different modules, score being an obvious starting point as that is something that provides some functionality that I may well want to reuse in the future. I think I probably need to do a fair bit of tidying up and consolidation now before I try anything extra otherwise I'm going to get lost in my own code.
--EDIT-- Looks like I can solve my collision detection woes with some bitmasks using Pygame's Mask objects. I'll need to swat up on this a bit first.
I need to check my ambition otherwise this is going to run away with itself. Sorted out the score class last night and got that rendering to the screen. I'm quite pleased with it as I've managed to pack in all the functionality I want and pop it all into a separate module. Keeping score in my main game loop is now a couple of lines of code, which is nice and clean.
Scoring ideas are now starting to come together in my head and I think I've settled on a set of rules for scoring (more or less). I've got the design for my first level sketched out too, but not implemented it yet.
The bloody enemy gun turrets are still giving me a headache though as I can't seem to get them to fire more than once. Grrrrr. Once I have that sorted and some collision detection for the enemy bullets then I have something which could be considered a game. Then vids...
It's python (including the pygame library), so it compiles to bytecode in a similar fashion to Java. Then you have a platform specific VM to execute the code as per Java. So in theory it will run on Linux, Mac and Windows. I'm developing on Linux atm. There is a pygame subset for android, but I don't know what the subset includes. It's also a bit of a faf as you have to have a pygame package installed on your device = rubbish!
Portability wise the difficulty would be reimplementing the game objects e.g. sprites etc. in a series of Java classes. I have no idea what's in the Android SDK in terms of dealing with 2dimensional images, but presumably this could be done in OpenGL and thinking about it because I will need to do a fair bit of rotational transformation then some of these aspects will probably be easier in OpenGL. In Pygame I'm having to muck about with rectangles, 2D sprite rotations and translations and it's a bit of an arse to be honest.
All the maths naturally are a cinch to port to any language.
Now I need to string these all together and get them talking to each other. I've also tweaked the gun turrets to slow the barrel tracking down, so the barrel now changes elevation with constant angular velocity and tries to lock onto the direction of the player.
OK, so I had a bit of a breakthrough last night and now have something that with a little bit more work could be considered the first level of a game, nearly...
Recent changes:
>> Combo Bar is now in and working
>> Timer is now in and working
>> Fixed the flicker on the turrets and many odd gfx problems
>> Fixed the destruction of the turret base and turret barrel sprites so that both are now destroyed correctly
>> Added background graphics to brighten it up a bit
>> rejigged turret bullets and sorted out the firing rules. Turrets now have a fixed speed of rotation and will charge a shot only if they're not rotating.
>> fixed the collision detection for enemy bullets
To do:
>> Fix collision detection bugs between player and scenery.
>> Fix spawning of turret bullets to occur at the end of the muzzle
>> Add arms to player sprite and animate
>> Add animated explosion
>> Add some sound fx
>> Split turrets into red and blue types for scoring purposes
>> Implement lives
>> Adapt combo system and score multipliers to fit scoring system
>> Implement game over and level complete logic.
And then.... if I can be arsed:
>> Add new enemy, powerup and environmental objects.
>> Devise system for storing, retrieving and building level data
>> Build Attract/Menu screen.
>> Complete gfx and sfx overhaul - not my strong point.
I'm such and idiot! I related my collision detection woes to a colleague and I think he has come up with a suggestion that will fix it using 1 line of code. The issue is that I'm checking for collision every time the display is updated. What I need to do is update the position of my sprites inbetween display updates and check collision then.
From my list above I've now split the turrets into red and blue types. If you colour match your bullets to the turrets then you score double, so red on red yields 200 pts, whilst red on blue or blue on red yields only 100 pts. This is coupled with a combo timer, which you can keep going by destroying turrets before the bar runs down. keeping the combo going adds to the score multiplier. Destroy all the enemies in a level and it's level complete, I've still got to do the logic for this, but basically I want to convert remaining time (from the master level timer) to points once the level is done.
I now have logic for the loss of a life, (resets the player sprite to the start position and resets score multiplier) and the loss of all lives (currently this just restarts the level).
I've drawn some explosion graphics, but not implemented these in game yet. I spent a fair bit of time tweaking the movement last night to make it less jittery and have made some real improvements. The real trick was to resolve momentum vectors from the fired bullets 2 at a time (i.e. buffer in 2 bullets before calculating momentum). I'd also inadvertently added a bug to do with the variable joystick deadzone I have, which cocked up the range of angles you could fire at (now fixed).
I'm so close now to having a complete 1 level game. I've got ideas for a couple more levels too, but I really want to get this first level working right before doing any more level design.
The 2 key areas which need to be spot on are: scoring (nearly there with that as I think the system I have is well balanced albeit a little different to what I had originally intended; and player control, which still needs a very subtle implementation of friction and some drag to apply some deceleration to horizontal velocities. The control does feel right, but your character is perhaps a little on the heavy side, I need to tweak his mass down a bit to see how that affects the feel. At the moment the best I can describe it is it feels a little bit like flying one of those 3 channel radio controlled helicopters you can buy. Which is a good thing.
I remember this thread! Since the last time I posted in here I've spent a couple of years working as a programmer in the industry, so if there's anything you need help with feel free to ask!
As for collision, how often does your game logic update? If it's running at a fairly high frame rate (e.g. 60fps) and you're still having problems with objects moving through each other you could always use continuous collision detection. If you're using axis-aligned bounding boxes (AABBs) for your collision then doing a simple sweep test shouldn't be overcomplicated:
Hi, good to hear from you and thank you for the offer of some help. I may well need some!
I've locked framerate at 60fps, but basically my game logic and screen updating were all triggered from the same event. What I want to do ideally is update the logic and refresh the screen separately. I'll need to take a look at that intersection test method. Thanks for the linky
I did a little fork of the code to see what would happen if I just let the logic update as and when it felt like (or rather as fast as my main game loop), using the clock to work out how far things should more etc. This didn't produce good results. Motion became a bit jittery and didn't look as good. What I need to do is pop another event on the queue so the game logic updates between frame refreshes, that will help. This is really a learning process for me, since I've never really attempted anything like this or been trained in how to do it. Some of what I've done though is certainly reusable and will, I hope, allow me to play around with a couple more ideas that I have once I have this prototype finished.
Ah that gamasutra article is pretty much what I want. I hadn't thought about thinking of this as a time domain problem. i.e. working out the exact time when the objects overlap and then using that as the basis of the position update. Neat.
Put together a couple of classes last night, 1 for a single particle and another container class that allows multiple particles to be instantiated from a single point on the screen. The effect is actually pretty good as I've got some code in there to gently transition the colour of the particles between two values as they move.
By injecting some randomness in the velocity of each particle and it's duration you can get a pretty cool looking firework type explosion.
I'd intended to use an animated explosion sprite in my game (already drawn the assets for these), but I'm seriously considering using these particle effects instead. If I set them to be the same initial colour as my enemy sprites and make the particle size big enough I can probably get away with using them as an explosion.
I'm grabbing an hour or two late night to do some coding. That's just about long enough to tick an item off the to do list. My code is pretty messy though, so I should take some time to document properly, write test scripts and consolidate my classes. There's quite a bit that could be consolidated if I used inheritance properly.
Put together a simple class last night that loads in a level map (stored as a 50x37 pixel .gif) and then uses the pixel data in the map to build the level. This will allow me to quickly build levels using a simple paint program. There's loads more to do though, way more than I'd originally imagined...
Damn that's spooky, I was thinking something along those lines.
I imagined a large cyborg production facility stamping out an army of cyborg soldiers. Each one fitted with a power plant capable of supporting life on a small planet. The power plant enables (through E=mc^2) the creation of ammunition in real time, which feeds the cyborgs arm guns. That's right instead of arms the cyborgs have heavy duty firearms (no pun intended)!
Suddenly malfunction. The cybernetic leg formation process has gone wrong and a cyborg rolls off the production line without the use of his legs. Immediately the automated systems jetison him for scrap (raggy doll style). However the cyborgs onboard computer (intel based pending sponsorship tie in) starts to compensate for the lack of motive power in his legs by dramatically increasing the firing rate and bullet mass of his arm guns. Effectively allowing our new hero to manouver through the conservation of momentum principle. By utilising both arm guns and a full range of 360 degree movement in each shoulder joint he has to fly, slide, recoil and fight his way back through the facility to shut it down for good.
Why what did you have in mind?
So he moves by shooting at the ground?
I always think the best way is the Metroid way, which is why I want to try Kid Icarus.
I reckon you could do something interesting with a single analogue stick, involving rhythm... a rocking from side to side style movement thing, instead of just pressing left, you start left, swing right and so forth... then a fighter style half arcs and up downs, to perform tasks, within a fairly standard 2d platform environment.
Similar to the reinvention you get from Jungle Beat. But with a stick.
Hmm sort of like Rag Doll Kung Fu, which I have to say was dissapointing largely due to the control being totally non instant.
I want instant control, as soon as I nudge the stick in a direction he should start firing in that direction. Possibly distance of stick from centre position might dictate rate of fire. Haven't decided whether that's over egging it (probably is).
You don't move by firing at the ground. You jump by firing at the ground. Allow me to give some examples. Imagine the number pad of your keyboard is an analogue stick, 8=up, 1=down-left etc. etc.
4,4 fires left, but due to recoil pushes him right
6,6 fires right, but due to recoil pushes him left
4,8 or 8,4 fires left, but due to the increased force pushing him down roots him to the spot so he doesn't move
2,2 makes him fly up in the air.
3,3 makes him fly up and left into the air.
It's basically the complete oposite of the norm as you can only move towards something by firing away from it. Level design and enemy placement will need careful planning and adjustment accordingly. So basically you could do a 1,1 to launch yourself up and right then carry that momentum forwards carefully controlling your trajectory with the guns. Maybe holding one stick in the 4 position to provide some forward thrust whilst gunning at a target on the ground with the other stick in a 3 position.
I think it would be mind meltingly complex and yet allow for a skilled player to develop their own subtle variations. You have to think of the guns as both weapons and thrusters simultaneously.
Plus our hero is dissadvantaged to some extent by this restriction in movement, which might make for some interesting confrontations with some fully working cyborgs in the later levels. We'll probably never know.
Am I mad? Oh and explain the Kid Icarus thing to me. I have it at home on NES, but never played it.
Forgot to mention.
Small hitbox - absolutely essential. The hitbox will basically be the circular area where the arms pivot from. A hit there will cause the arms to fall off and spin wildly out of control still firing and taking out enemies. Whilst the rest of him crumples to the ground.
I like the sounds of that... I remember reading alot about Star Fox... and as we know that is perfect blend of control and level design... something that is sometimes forgotten. You can have perfect control, but suffocating, useless level design. The native English speaking guy who made the Star Fox engine said that the Japanese level designer, whose name escapes me, was properly insane over level design to the point of never sleeping... or some such. I'm sure thats a complete injustice.
From what I've read, Kid Icarus is billed as a blend of Super Mario and Metroid... which sounds unbeliveably good, its on the VC, but I'm on a game purchasing hiatus... I've waited 15 years a few weeks or months wont hurt...
So would disabled cyborg adventures... DCA... be a single screen puzzle affair? because me and paper went through Megaman the first one and that was very much a single screen puzzle, then next screen and so on... the technology controlled the game and it was kinda nice to know that you had a screen to get through or a series of screens... that kinda tangiable progression is what I like.
I reckon you could do something interesting with a single analogue stick, involving rhythm... a rocking from side to side style movement thing, instead of just pressing left, you start left, swing right and so forth... then a fighter style half arcs and up downs, to perform tasks, within a fairly standard 2d platform environment.
Second thoughts that could work in a Jet Set Radio graphitti sort of way where you combo moves together by swinging the stick as opposed to pressing a button. Could be really interesting if implemented well.
You could have wires that's whip out of the bottom of his leg-less torso and latch onto certain objects scattered through the game that allow him to use them for movement for a limited time (a hovercraft fan for example). You could then be able to use his arm cannons only for attack, basically spinning the controls system 360 (firing left no longer makes you move right allowing you to attack into an enemy instead of sending you away from them) - could be a real headfuck!
______________________________________________________________________________
When's 'Wii Carlton' coming out?
So would disabled cyborg adventures... DCA... be a single screen puzzle affair? because me and paper went through Megaman the first one and that was very much a single screen puzzle, then next screen and so on... the technology controlled the game and it was kinda nice to know that you had a screen to get through or a series of screens... that kinda tangiable progression is what I like.
hmm originally I'd thought of it as a multi-directional scroller, but with suitably dinky sprites and the obvious need for you to be 100% aware of what's waiting for you when you make a move then it probably would work better as a fixed screen game. I think Megaman stayed flip screen for some considerable time. Megaman4 is a flipper iirc.
When I say dinky I mean bangai-o dinky.
You could have wires that's whip out of the bottom of his leg-less torso and latch onto certain objects scattered through the game that allow him to use them for movement for a limited time (a hovercraft fan for example). You could then be able to use his arm cannons only for attack, basically spinning the controls system 360 (firing left no longer makes you move right allowing you to attack into an enemy instead of sending you away from them) - could be a real headfuck!
A sage like suggestion and one I'd toyed with for a bit. I envisaged Dual Shock style control, clicking in either stick to launch and disengage a grapple line. I sort of mentally parked it as an idea as it seemed to me to add yet more complication on something which was already going to be high concept and alien to normal people. Maybe as a time limited powerup it could work or maybe it's something to save for Dissabled Cyborg Adventures 2.
Have you lot played Lethal Application? It's a 2D vertical scrolling platform shooter where the movement is fairly similar to what you're describing, but more simplistic.
If you haven't, I'll record some footage to show you what it's like.
edit: There you go http://www.youtube.com/watch?v=NiPQQbUjvYk
No I haven't, but that's the sort of thing I'm talking about. At least it proves that the core concept is sound. Thanks for the vid.
I think I need this game... It looks ace.
Don't you just hate it when someone has already implemented your ideas :grrr
Implementing an extra thruster/gun though plus mixing in some ground based combat might make for an interesting derivative.
Don't you just hate it when someone has already implemented your ideas :grrr
Tell me about it, I thought I was gonna die a very rich man when I came up with Nutchos the worlds first Nacho Cereal - the Mexicans were gonna flip for it!!! Poxy Nestle and their evil brain spies and time travel machines...
That game looks hype! Cheers for the vid!
Using pygame I have the very bare bones of a working prototype of "Disabled Cyborg Adventures", which now comes under the working title of "Fire Arms". So far I have the twin stick thrust shooting mechanics more or less there, but I have to add in some friction and inertia to aid player control as it's all a bit floaty at the moment, plus I need to do some tweaking on my bullet/player mass ratios and rate of fire. I've sort of fluked a set of values that make the player character pretty manoeuvrable, which is cool.
There's also an annoying 'not dropped' referencing bug, which means that shots that go off screen aren't destroyed and garbage collected by the python interpreter. I can get around that by putting in some walls all around the edge of the screen, since collision detection and bullet removal works fine for these elements.
next steps are to implement some enemy behaviour. So far I have one enemy type (a fixed gun emplacement), which doesn't fire, so I need to get some enemy bullet sprites in there and some rules as to how these should work. I have some ideas for other enemy types too and a couple of scoring handles that will require the player to think about their approach to a level somewhat in order to maximise score.
Once that's done then I need to write some code to parse some level files into walls, platforms and enemies then get busy scripting some levels. Since this is all prototype stuff I'm working on a fixed screen (window) resolution, which is a bit pap, but then this isn't for public consumption really. Also I'm not sure how the game will react to a different controller (I'm using a PS2 pad through a magicbox). In theory pygame should sort this out, but there might be some oddness with different joystick axis if, for example, I plugged in a USB 360 controller (which I don't have).
Graphics are all horrible place-holder stuff that I've put together in inkscape and then exported to bitmaps at various sizes. So far the player sprite is just a box with a circle inside, so he'll need some work, frankly though I'd rather spend the time tweaking the gameplay and level design.
Also there's no sound, music, explosions or sprite animation as yet, just a mass of bright cyan and magenta bullets that you can fire in glorious sweeping arcs across the screen. I'm genuinely quite pleased by the control. It requires a fair amount of mental gymnastics to use the guns for thrust and attacking, which was always the intention. Once I have a full level put together I'll need to give it some proper play time to see if the controls click in with prolonged play.
That sounds great! I've never heard of Pygame before, I really would love to try something like this. I'm so sick of working myself half to death for Future, I want to try something creative for a change. Using your guns as means of moving your character is a great idea, I demand vids when this is done!
Thanks man.
I already knew a bit of Python, which is a really easy programming language to learn imo. Pygame is a library for Python, which has most (in my case all) of the functionality needed to build a game. No doubt there's been a learning curve to go through, but last night I made a hell of a lot of progress in a very short amount of time (after several nights of slow and frustrating coding). I don't think you'd use Pygame to build a full on game for public release, but for quickly prototyping something this was the obvious choice for me as I was already aware of Python syntax to a degree. It made it relatively easy to get what's in my head into something that I can demo to get the central ideas across.
At this stage I've not gone for a scrolling game. Fixed screen is much easier for me to build as a first project. This also means I have to come up with some very compact and tight levels to try out some ideas for different enemies and scoring opportunities. I want the scoring to be a little bit like Bomb Jack, where the order in which you approach things is very important. This means you might need to work your way past some enemies to kill one that's a way off to maximise score. I can work this through the different coloured bullets (cyan for the left arm and magenta for the right). This way I could build in some colour based scoring options and/or enemy shields that are colour coded. I'm a way off getting any of that going though and might change my mind completely and take it in a different direction altogether.
I didn't make much progress last night. I've got some irritating collision detection bugs due to the way in which a sprite jumps from point A to point B it means it can pass through an object far enough to teleport to the other side of it. This requires a significant rethink on how to approach collision detection as I need to store the old position of the sprite (trivial) and use that information together with it's new position and what it has collided with to dictate what should happen.
I aslo tried to get some enemy bullets up and working last night, but there's a bug that's stopping them from being drawn to the screen, probably something dumb.
I created a score class to keep track of score and multipliers. My code is getting quite long now, time to split out parts into different modules, score being an obvious starting point as that is something that provides some functionality that I may well want to reuse in the future. I think I probably need to do a fair bit of tidying up and consolidation now before I try anything extra otherwise I'm going to get lost in my own code.
--EDIT-- Looks like I can solve my collision detection woes with some bitmasks using Pygame's Mask objects. I'll need to swat up on this a bit first.
I need to check my ambition otherwise this is going to run away with itself. Sorted out the score class last night and got that rendering to the screen. I'm quite pleased with it as I've managed to pack in all the functionality I want and pop it all into a separate module. Keeping score in my main game loop is now a couple of lines of code, which is nice and clean.
Scoring ideas are now starting to come together in my head and I think I've settled on a set of rules for scoring (more or less). I've got the design for my first level sketched out too, but not implemented it yet.
The bloody enemy gun turrets are still giving me a headache though as I can't seem to get them to fire more than once. Grrrrr. Once I have that sorted and some collision detection for the enemy bullets then I have something which could be considered a game. Then vids...
w00t Gun Turrets with barrels that track the player around the screen DONE!
Impressive! How portable is the code? Do you compile it for a platform? Or does it run in Pygame land only?
It's python (including the pygame library), so it compiles to bytecode in a similar fashion to Java. Then you have a platform specific VM to execute the code as per Java. So in theory it will run on Linux, Mac and Windows. I'm developing on Linux atm. There is a pygame subset for android, but I don't know what the subset includes. It's also a bit of a faf as you have to have a pygame package installed on your device = rubbish!
Portability wise the difficulty would be reimplementing the game objects e.g. sprites etc. in a series of Java classes. I have no idea what's in the Android SDK in terms of dealing with 2dimensional images, but presumably this could be done in OpenGL and thinking about it because I will need to do a fair bit of rotational transformation then some of these aspects will probably be easier in OpenGL. In Pygame I'm having to muck about with rectangles, 2D sprite rotations and translations and it's a bit of an arse to be honest.
All the maths naturally are a cinch to port to any language.
Timer object DONE!
Combo Timer and bar DONE!
Now I need to string these all together and get them talking to each other. I've also tweaked the gun turrets to slow the barrel tracking down, so the barrel now changes elevation with constant angular velocity and tries to lock onto the direction of the player.
OK, so I had a bit of a breakthrough last night and now have something that with a little bit more work could be considered the first level of a game, nearly...
Recent changes:
>> Combo Bar is now in and working
>> Timer is now in and working
>> Fixed the flicker on the turrets and many odd gfx problems
>> Fixed the destruction of the turret base and turret barrel sprites so that both are now destroyed correctly
>> Added background graphics to brighten it up a bit
>> rejigged turret bullets and sorted out the firing rules. Turrets now have a fixed speed of rotation and will charge a shot only if they're not rotating.
>> fixed the collision detection for enemy bullets
To do:
>> Fix collision detection bugs between player and scenery.
>> Fix spawning of turret bullets to occur at the end of the muzzle
>> Add arms to player sprite and animate
>> Add animated explosion
>> Add some sound fx
>> Split turrets into red and blue types for scoring purposes
>> Implement lives
>> Adapt combo system and score multipliers to fit scoring system
>> Implement game over and level complete logic.
And then.... if I can be arsed:
>> Add new enemy, powerup and environmental objects.
>> Devise system for storing, retrieving and building level data
>> Build Attract/Menu screen.
>> Complete gfx and sfx overhaul - not my strong point.
I'm such and idiot! I related my collision detection woes to a colleague and I think he has come up with a suggestion that will fix it using 1 line of code. The issue is that I'm checking for collision every time the display is updated. What I need to do is update the position of my sprites inbetween display updates and check collision then.
From my list above I've now split the turrets into red and blue types. If you colour match your bullets to the turrets then you score double, so red on red yields 200 pts, whilst red on blue or blue on red yields only 100 pts. This is coupled with a combo timer, which you can keep going by destroying turrets before the bar runs down. keeping the combo going adds to the score multiplier. Destroy all the enemies in a level and it's level complete, I've still got to do the logic for this, but basically I want to convert remaining time (from the master level timer) to points once the level is done.
I now have logic for the loss of a life, (resets the player sprite to the start position and resets score multiplier) and the loss of all lives (currently this just restarts the level).
I've drawn some explosion graphics, but not implemented these in game yet. I spent a fair bit of time tweaking the movement last night to make it less jittery and have made some real improvements. The real trick was to resolve momentum vectors from the fired bullets 2 at a time (i.e. buffer in 2 bullets before calculating momentum). I'd also inadvertently added a bug to do with the variable joystick deadzone I have, which cocked up the range of angles you could fire at (now fixed).
I'm so close now to having a complete 1 level game. I've got ideas for a couple more levels too, but I really want to get this first level working right before doing any more level design.
The 2 key areas which need to be spot on are: scoring (nearly there with that as I think the system I have is well balanced albeit a little different to what I had originally intended; and player control, which still needs a very subtle implementation of friction and some drag to apply some deceleration to horizontal velocities. The control does feel right, but your character is perhaps a little on the heavy side, I need to tweak his mass down a bit to see how that affects the feel. At the moment the best I can describe it is it feels a little bit like flying one of those 3 channel radio controlled helicopters you can buy. Which is a good thing.
video to follow soon.
I remember this thread! Since the last time I posted in here I've spent a couple of years working as a programmer in the industry, so if there's anything you need help with feel free to ask!
As for collision, how often does your game logic update? If it's running at a fairly high frame rate (e.g. 60fps) and you're still having problems with objects moving through each other you could always use continuous collision detection. If you're using axis-aligned bounding boxes (AABBs) for your collision then doing a simple sweep test shouldn't be overcomplicated:
http://www.gamasutra.com/view/feature/3383/simple_intersection_tests_for_games.php?page=3
Then again, if you've got the collision working fine already then doing anything extra is probably overkill
Hi, good to hear from you and thank you for the offer of some help. I may well need some!
I've locked framerate at 60fps, but basically my game logic and screen updating were all triggered from the same event. What I want to do ideally is update the logic and refresh the screen separately. I'll need to take a look at that intersection test method. Thanks for the linky
I did a little fork of the code to see what would happen if I just let the logic update as and when it felt like (or rather as fast as my main game loop), using the clock to work out how far things should more etc. This didn't produce good results. Motion became a bit jittery and didn't look as good. What I need to do is pop another event on the queue so the game logic updates between frame refreshes, that will help. This is really a learning process for me, since I've never really attempted anything like this or been trained in how to do it. Some of what I've done though is certainly reusable and will, I hope, allow me to play around with a couple more ideas that I have once I have this prototype finished.
Ah that gamasutra article is pretty much what I want. I hadn't thought about thinking of this as a time domain problem. i.e. working out the exact time when the objects overlap and then using that as the basis of the position update. Neat.
I has particle effects \o/
Put together a couple of classes last night, 1 for a single particle and another container class that allows multiple particles to be instantiated from a single point on the screen. The effect is actually pretty good as I've got some code in there to gently transition the colour of the particles between two values as they move.
By injecting some randomness in the velocity of each particle and it's duration you can get a pretty cool looking firework type explosion.
I'd intended to use an animated explosion sprite in my game (already drawn the assets for these), but I'm seriously considering using these particle effects instead. If I set them to be the same initial colour as my enemy sprites and make the particle size big enough I can probably get away with using them as an explosion.
This sounds like a super awesome project. Can you remember the names of your family?
My family are a distant memory...
I'm grabbing an hour or two late night to do some coding. That's just about long enough to tick an item off the to do list. My code is pretty messy though, so I should take some time to document properly, write test scripts and consolidate my classes. There's quite a bit that could be consolidated if I used inheritance properly.
level data loader.
Put together a simple class last night that loads in a level map (stored as a 50x37 pixel .gif) and then uses the pixel data in the map to build the level. This will allow me to quickly build levels using a simple paint program.
There's loads more to do though, way more than I'd originally imagined... 