Help with Space Invaders type game
harrio
Member Posts: 234
what's cooking chefs,
well, i thought i was going to knock some simple games to get the hang of gs and then start designing some higher level ones for the iphone. no such luck. i am getting crushed by my very first 'simple' game. it's suppose to be a space invader clone.
i was creating the enemy movement and that's where i have been stuck ever since. this is killing me because i thought i would be simple. i'm glad i didn't do all the art work first, then i'd really be pissed.
the movement is basic:
start moving right (game.enemy direction=right)
when the enemy hits the right side border (x=445) or the left (x=50) then it should drop down (self.position y)-10
once it drops it will change direction and the cycle continues.
but of course that's not what happens.
it begins in whatever direction i direct it by setting enemydirection before i preview. but when it goes to the right it stops at the border, turns back without dropping down and then continues to the left until it scroll wraps. if i start to the left, it just scroll wraps. can anyone see something bone headed in my rule setup. sorry if it's hard to see. gs is not to foregiving with real-estate. especially when you're on a laptop.
http://docs.google.com/View?id=dcrvmt6h_15czh4pzc3
any help would be greatly appreciated. i'm already bald, so i have no hair to pull out.
well, i thought i was going to knock some simple games to get the hang of gs and then start designing some higher level ones for the iphone. no such luck. i am getting crushed by my very first 'simple' game. it's suppose to be a space invader clone.
i was creating the enemy movement and that's where i have been stuck ever since. this is killing me because i thought i would be simple. i'm glad i didn't do all the art work first, then i'd really be pissed.
the movement is basic:
start moving right (game.enemy direction=right)
when the enemy hits the right side border (x=445) or the left (x=50) then it should drop down (self.position y)-10
once it drops it will change direction and the cycle continues.
but of course that's not what happens.
it begins in whatever direction i direct it by setting enemydirection before i preview. but when it goes to the right it stops at the border, turns back without dropping down and then continues to the left until it scroll wraps. if i start to the left, it just scroll wraps. can anyone see something bone headed in my rule setup. sorry if it's hard to see. gs is not to foregiving with real-estate. especially when you're on a laptop.
http://docs.google.com/View?id=dcrvmt6h_15czh4pzc3
any help would be greatly appreciated. i'm already bald, so i have no hair to pull out.
Comments
Side Wall actors: These control the enemy movement.
-When wall collides with enemy: Change a game attribute, enemymove, to 0. And Timer after .8 seconds change it to -1 or 1 (depending on which wall).
Enemy actor:
-If game attrib == 0: Move To Position: (self.Position.X, self.Position.Y-10)
--Otherwise Move: Direction 0, Speed= game.enemymove * 180
-If collides with bullet: Destroy this actor
Then the normal player actor and projectile actors.
http://www.gamesalad.com/game/play/7093
I've not got time right now to go into details, but I fiddled with an idea I had for about 10 minutes and came up with this:
http://gamesalad.com/game/play/7088
Essentially I have two actors.
Actor 1 moves always to the right at speed 100 (so you need the movement behaviour at the top that says move right at speed 100).
It then has a rule that states:
If position X is greater than 450, then put in these behaviours:
timer - for .3 seconds move down at speed 100
timer - after .3 seconds spawn Actor 2 (then at the end add a 'destroy this actor' behaviour).
Actor 2 is the same, except you change the movement to go the left, change position x to read less than 50, and spawn Actor 1
The actors in the game example shown are 16x16 in size.
It's not perfect, but I hope that helps or gives you some ideas!
Cheers,
QS
Dr. Sam Beckett never returned home...
Twitter: https://twitter.com/Quantum_Sheep
Web: https://quantumsheep.itch.io
With that being said this is how I would START my thinking. I assume you want them to follow a set path. Use simple move to commands. (I'm gonna use simple IF - THEN statements, I'm assuming you can convert this to GS Format)
ENEMY move to X - aaa / Y - bbb
If ENEMY X/Y = aaa/bbb then move to ccc/ddd
etc...
Do this for your whole 'route'. Obviously you may have to play with this to get it fluid & looking nice, but this is where I would start looking at the problem.
You can even loop your route if you want them to do this continuously until they die.
Your last point on your route would be wherever you want the loop to start from.
The trick with this is to use the exact X/Y. Each movement is a separate rule. Especially with the loop. Thats why the last X/Y needs to be where the loop will start. This will constantly search to see if the mob is at that EXACT X/Y. Also I could foresee a problem if you happen to have it cross the EXACT X/Y again unintentionally during the route. You would be fine as long as it doesn't cross over at the EXACT starting point of a loop. But just try it & see what happens.
This should at least help lead you in the right direction. Again this is theory, I haven't done this & I'm simply using my Divine Given, Awesomely, Mighty, Powerful WISDOM to reason it out. So it SHOULD work... maybe...well it might... hopefully...on second thought just don't come to me if it crashes your laptop!!
Thanks for tuning in again to JGary's daily:
"I'm reasonably sure it won't crash your laptop" segment. See ya tomorrow when we try to NOT crash someone else's computer!
EDIT: I just noticed Code Monkey posted up above saying this probably isn't the best way to do it! O well, I tried. I told you I wasn't sure if it would work =p
I also moved this to the Game Design Support section.
codemonkey, i know it can't be seen in my diagram but my condition for the enemys changing direction covers whether they 'hit' the border or 'cross' it. it is thus...
when any condition is valid
self.posx = 50
self.posx < 50
self.posx = 445
self.posx > 445
so by my thinking, it should catch it no matter what. and it always catches the right-side border it only fails on the left-side border.
as for the 'invisible wall' method. it has merit in schemes where it is necessary but i don't think it is needed for this movement scheme. i started to go that route and then i read a couple of other chefs talking about elegant algorithms and optimized design. it reminded me of my programming days so i decided not to hack the solution when math should suffice.
if i am wrong please correct me but space invader mvt is very simple; they begin from a set position and move in a set direction. they start to the right...hit the right border...drop down a fixed increment and change direction...move to the left...hit the left border...drop down a fixed increment and change direction...until they are killed or until they kill the player or make it down to the players level, which kills the player also.
now if i were programming this on the radioshack trs-80's i used to learn basic back in the 80's, no laughter please, this would be plainly simple a math problem. so i felt it should be at least equally as simple to do this in gs. i should not need invisible walls for this particular algorithm. do you agree?
quantumsheep, i understand your example but i can't help but think, and this is what i am trying to express to the headchefs, that simple mvts should be simple to design. this is not pathfinding or and rts or such. a twelve year old should be able to figure this out with some experience in programming and i'm nearly 30 years to the wrong end of twelve and vexed at this problem.
could there be another 'move to' behavior that functions more like a teleport or a peek/poke instead of like a lerp. meaning, it instantly disappears from it's current position and appears at the designated x/y position. this could help many different game types i think...not just my ailing game.
jgary321, i started this rule trying the 'move to' for all the mvts, it was a nightmare of epic proportion. maybe i just implemented it incorrectly which is highly possible but once again, this is not a difficult mvt scheme. it should lend itself to easy implementation. this would be thoughtlessly easy in gamemaker, mmf2, tgb, novashell, construct or others. but they lack what gs has, a mac centric path to gameplay in the browser and to the iphone which i see the value in. and which is why i am begging for not just help for me, but help for keeping simple movement solutions simple. as they should be.
thanks for renaming and moving the thread codemonkey. my bad there.
i'll be banging my head against this some more today...i'm stubborn and i refuse to let space invaders do me in. oh the horror of it.
One more thing, if you are checking on the position of the actor to change direction of all the actor's movements, when you use the otherwise, it may be fighting itself to change direction. e.g. you move so fast to the left that you've gone to 49 on one invader. The game attribute finally switches to the right and your actor is moving right, but you are still below 50 as it is moving right so it sees that and changes the attribute to left, etc, etc.
codemonkey, i played with stacked and additive back and forth and neither changed the mvt behavior, so i don't know what if any affect they will have for my scheme.
so you think i should break the movement down into individual functions with no otherwise statements used. i guess i can give that a try. it's not like anything else has worked. i have to say this really is frustrating me. if i can't get this working by weeks end then i will probably admit logic/programming defeat and try an invisible wall hack. oh the shame.
i already anticipated what you said about the changing direction dilemma that's why i have the speed set to 20 and i only use one enemy instance for my testing. that's whats so frustrating. it moves dead cat slow with only one enemy and it still does not catch the direction change and i can't figure out why. there is no conflict because each enemy checks it's position individually. this elegantly, at least i thought so when i built it, changes direction because only one enemy is needed to change the direction for all the rest when it hits a left or right border.
i'll give the 'no otherwise' approach a shot and let you know how that goes. i also plan on documenting my trevails with this game as a learning document for beginners that you can place innocuously on the wiki if you so choose.
i'm off to battle the bits and bytes...wish me logic
it would be good to be able to label rules or groups as ignored aka commented out and thus not performed during runtime.
in trying to fix my game i have to try different methods but that means i have to totally erase the other custom methods i've made to include the new ones. if i could just make them 'ignored' then i could visually compare those with the new methods as i troubleshoot what's wrong instead of trying to remember what i did before.
just a thought to making it better for everyone...
here's what i have so far...
http://docs.google.com/View?id=dcrvmt6h_19c4xcjrgn
- i took jgary321's suggestion and went back to 'move to' statements
- codemoney's suggestion to separate each mvt action to eliminate problem otherwise stmnts
- created 'move down' game boolean to tell the enemy if it has moved down recently
results...
- the enemy moves to the right until it hits the 'right-limit' and then it moves down...yeah...unfortunately, it does so continuously and screen wraps vertically.
- when it moves to the left it still does not recognize the 'left-limit' it just continues and screen wraps horizontally.
any ideas...? since i have no hair, i'm all ears
my apologies to whoever is already tiring of this thread. this is part an parcel to my 'process' for debugging/troubleshooting, so i hoped to share it with others that might benefit. but i realize i may be wearing my welcome thin for others.
here's what i have now...
http://docs.google.com/View?id=dcrvmt6h_2686t3zhf4
- continued codemonkey's advice of separating as many operations as i could. it's helping, but i don't know why. the head chef will have to break this down to me so i understand why this is helping.
- i removed the multiple mvt calls from the last setup and now have only one mvt call for each different mvt type; left, right, down. i let variables control reversal of direction.
- although i don't know if it helped, i started fresh with a blank actor and remade my rules from the last iteration as i decided what to change.
results...i'm really close
- the only rule that does not work properly is 'enemy down mvt'; if i set it for 'run to completion' the enemy moves to a border and then goes down continuously. screen wrapping vertically. if i take off 'run to completion' the enemy ping pongs back and forth impressively as it reaches the borders but it never goes down a level when it hits each border.
anyone with a suggestion is welcome to toss it at me. i'm too close to give up now. i know i can solve this movement scheme with math alone and no controller hacks. i just have to crack this last nut.
this is the occasion when too many chefs in the kitchen is a good thing.
It could be easy to visualize with paper and pencil. Draw out the movement pattern of your actor. Each time that path changes direction, you are in a different state.
So perhaps where you change the direction with 'left' and 'right', add a state of 'down' so the left/right movements do not happen. Then put the change attribute behaviors for changing to 'left'/'right' into a timer that happens after you've given enough time to move downward.
codemonkey, i'm a little concerned now. are you referring to the 'latest' iteration? because the down state is the very first one listed.
as of now, it either runs the left/right states but not down, or, if i select 'run to completion' in the down state, it will move in whichever direct i initially set 'enemy direction' to and then move down continuously.
time allowing, could you check again. i'm certain the down state is there.
oh yeah...and thx for the help. i have to remember to thank people in the midst of struggling to beat this problem...codemonkey, jgary321, quantumsheep.
i see what you mean. great observation! that's why more chefs in the kitchen make a better stew. i will re-implement the rules using just 'enemy direction' as the single state controller and see how that goes.
to be honest, i don't really know why i separated 'down' from the other states. it makes more sense and it's cleaner to manage them all from one state variable. klutzy move on my part.
by the way, great solve on that 'random mvt' thread...
i re factored the rules to just use 'game.enemy direction' as the sole state controller and 'game.reverse direction' to control the 'game.enemy direction' after a down mvt. i thought this would kick the nut, but no joy.
http://docs.google.com/View?id=dcrvmt6h_35gjvzbqhd
the same results...
- it ping pongs back and forth correctly at the left and right borders but it won't go down.
- when i select 'run to completion' for the down mvt rule it goes to whichever border then goes down continuously, screen wrapping vertically.
this is really miffing me. because now that the logic is sound, i really have no idea why it is not working. not a good feeling.
any suggestions from the chefs...?
i'm surprised you guys, & gals if there are any, didn't hear me screaming all the way from qatar. aye the nut...she's been cracked!
http://docs.google.com/View?id=dcrvmt6h_45gd59knc7
i changed one rule, enemy down mvt, and made it a move behavior instead of move-to. codemonkey, can you explain why move-to won't work for all three movement states. logically, i don't see the difference. they should both work the same. but they don't.
all is well that ends well. i've got complete math/logic control of the enemy movement now...sweet. i know it's just space invaders, but it still feels good to beat this problem.
thanks to everyone who helped and everyone who decided not to thread bomb me for being a continual annoyance.
now let me think up another problem that will probably keep me from finishing this.
by the way, i'd be interested to know if there are in fact any female chefs here?
well it didn't take me long to find more problems. now that i have a working behavior group, i want to delete the old 'my behavior' custom group. but gs won't let me. how do i remove behaviors from the 'my behavior' section?
my mvt scheme works perfectly for one enemy. but when i added more, things fell apart. first i just added instances of the actor prototype to the scene to see if the mvt behavior scaled. they are not synchronized in their actions. they move left to right perfectly together but once they reach a border, only one performs the down mvt. then they all reverse direction and do the same thing on the other side. the same thing being, only one of the actors performs the down mvt.
so i tried replicating the actor, which seemed to work perfectly until i saw that only the initial actor uses the behaviors. the rest just uh...replicate what the main actor does. which is not good because they don't adhere to the border rules. once i read the documentation in the wiki, i saw that they are just visual copies of the initial actor.
could you have two types of replicators, one for visual copies and one that makes actual actor instances?
does anyone have an idea why the actors don't move in synchronicity? is it a lag in the runtime?
any word on deleting old behavior groups from 'my behaviors'?
that's cool. it will definately help to able to get rid of busted behaviors.
i'm still trying to crack this synchronized mvt nut. i noticed of the two 'invader' clones you posted in the game section; the first utilized replicators, i'm guessing, because they move in sync but they never move very far laterally, but the second used actor instances and i see that they do not remain 'in sync' as they move. is it just not possible or should i keep working at it?
codemonkey; i saw what you posted in the wiki about the different movement behaviors. good stuff. but what caught my attention was the throw away remark you made about a 'combination of behaviors to mimic movement'.
you listed timer + chg attr as a possible method. does this mean that i can utilize something like [ every x seconds chg attr actor:(pos_x & pos_y) ]? will there be something else needed or will a statement like this move an actor from one position on the screen to another position instantly. how is the redraw handled?
i'm very interested in this method because it will help me circumvent some of the problems you mentioned in the wiki with the move behaviors.
But yes, you can do that. It will move it instantly. The smaller the increments, the less you notice that the actor going to the new coordinates and thus looking like a smooth moving.
that may be exactly what i need. i'm sure you know that 'space invader' mvt is actually not smooth. in fact it is obnoxiously incremented and as you destroy more aliens the increment speeds up, adding a sort of 'built-in tension' to the game. so in this particular instance, i don't really need linear motion. the old school 'now i'm here...now i'm there' will work perfectly.
and now that i have modularized my rules set, at your advice, it makes it easy for me to try this method. i can just pop in this method in the mvt rules and all the math that checks the borders and reverse directions and what not, will function the same.
well codemonkey, you almost had me dejected enough to give in.
one, because i checked out your example game and it did almost exactly what i wanted to do. two, because i messed with a copy of gamemaker 7 i have, and got exactly the movement i wanted in less than ten minutes. but i was determined to find a way to make it work.
two things ended up being key; i used the 'non-physics' movement that you eluded to in the wiki. this helped take away the physics movement conflicts - and it added an easy timer based way to take care of the 'staggered' movement style of space invaders. plus, i had to figure out how to emulate your invisible wall controllers from within each enemy instance.
movement: i think you should write up an entry about this movement method because it will help the games that don't need physics movement, but still want control over their actor movement. i would write up what i have experienced but i'm sure you know more about this method than i have just recently learned while smacking my head into it repeatedly.
direction control: after a combination of looking at your example and replaying my behaviors a gazillion times with my enemies setup different ways on the screen each time. i figured out that, because i was using a global variable for the movement state, and changing the movement state globally, i was somehow only enabling the first enemy who met the border wall conditions to respond accordingly. no matter what configuration of enemies i placed on the scene, i found that the first to hit either the left or right border would move down and change direction but the rest would just change direction. obviously this gave me fits and i've only just properly apologized to my laptop for the filthy names i called it. in the midst of hot swapping rules, i decided on a hunch/whim to remove the change direction rule and just see what the enemies did. lo and behold they all moved to one side, hit the border and moved down in perfect sync. then they stopped. which made sense because i removed the ability to change direction. but then i realized somehow, this rule because it applied to the global direction state was only being performed by the first enemy to hit it, then it would reverse direction and continue on. now i thought all the instances would do this but only the first did. the rest just recognized that the global direction state had changed and reversed course. i still don't quite know why this did not work right. but nevertheless i decided to perform the reverse direction change as a local instance instead of globally.
so the left, right and down are handled globally, but the decision, after moving down, to change direction is handled locally by each instance. when i did that....eureka!
it now staggers exactly the way it does in space invaders, which is what i wanted. not smooth movement. so there it is. space invaders movement with no invisible wall controllers. i guess i'm just stubborn.
i'll post the rules as a template for anyone who wants it. though i doubt an efficient space invaders rule setup will be in any great demand..lol.
but that [ timer + chg attr ] movement style should definitely be posted as an option to the physics type movements.
thanks for every ones help.
especially codemonkey for enduring my treating him like my personal customer support tech.
now i may be able to start some art. until i find another problem...ugh.
i'll have the template done soon but i wanted to add this info for codemonkey. this is not a bug but more a suggestion for functionality.
when i was setting up the border rules conditions, each condition had two statements that had to be fulfilled. ex. if (self.positionx = 445) and (game.enemy direction = right) then execute right border rules. however i could not put all the statements in one rule because it won't except groups of conditions like;
if (self.positionx = 445) and (game.enemy direction = right) or
if (self.positionx > 445) and (game.enemy direction = right)
these are four conditions, but they are actually two conditions with two criteria each. but because the (any / all) declarer applies to everything listed in the criteria, there was no way to put them together even though they all relate to the same condition.
i don't know if this was a deliberate design decision to keep separate each listing of criteria, or if it just was not thought of to enable groupings of criteria within the condition statement.
as usual...hope this helps
here's the movement rules as promised.
http://docs.google.com/View?id=dcrvmt6h_47hq7zj7cj