confining the play area of a space shooter
Author
I am making a 2D space shooter where the player is free to roam the area in all directions. How can I confine the user to my play area and keep them from going in one direction for an infinite distance? I dont really like the whole idea of wrap around to the other side of the play area.....any other ideas?
if (playerX < borderX) playerX = borderX;if (playerX + playerWidth > borderX + borderWidth) playerX = (borderX + borderWidth) - playerWidth;and so forth....
If you meant from a game mythology POV:
If they go to far the really bad ass aliens pop out and kill them!
Or do a star trek with a magic barrier that blocks all from leaving the galaxy despite being a ring shaped band only a few light years in thickness.
:)
If they go to far the really bad ass aliens pop out and kill them!
Or do a star trek with a magic barrier that blocks all from leaving the galaxy despite being a ring shaped band only a few light years in thickness.
:)
Quote:Original post by freeworldIn an 'open space' environment, this will give somewhat artificial results. Maybe it would suffice for the OP, but I imagine there are better solutions.
*** Source Snippet Removed ***
and so forth....
(Also, the whole 'x + width' thing is pretty inconvenient for all but the most trivial applications. It's better to put the 'hot spot' at the object's center, IMO.)
@The OP: To add to empirical2's suggestions:
1. When the player goes 'out of bounds', spawn a warning message, e.g. 'warning: leaving authorized area'. If the player doesn't return to the play area, impose some sort of penalty, or perhaps warp them back to a random spawn point (again, along with a warning, e.g. 'warning: warping in 3, 2, 1...'). Whether this sort of thing makes sense or not will of course depend on the game.
2. Similarly, sound a warning and then have the 'autopilot' take over if the player doesn't return to the play area. The autopilot can just slow down, orient the ship back towards the play area, and then accelerate, returning control to the player once the play area has been reached.
There are loads of options when it comes to this you just need to use your imagination.
For example, in this game world, ships are powered by a special energy field that extends around an area which just happens to be the boundary.
If they leave the area there power starts to decline because they are out of range of the supershippyfuel power transmitter, and the ship dies or explodes or w/e (warnings are a good idea!)
WoW has a similar system to prevent players discovering that the two main islands really are not in a tangible connected space :)
Remember, its your game your universe you make the physical laws. Thats whats great about programming games. A little touch of godlike powers :D
For example, in this game world, ships are powered by a special energy field that extends around an area which just happens to be the boundary.
If they leave the area there power starts to decline because they are out of range of the supershippyfuel power transmitter, and the ship dies or explodes or w/e (warnings are a good idea!)
WoW has a similar system to prevent players discovering that the two main islands really are not in a tangible connected space :)
Remember, its your game your universe you make the physical laws. Thats whats great about programming games. A little touch of godlike powers :D
Author
freeworld: i understand can do that....but not what i am looking for as the player just all of a sudden "stops" in space once they hit an invisible edge
empirical2: better about bad ass aliens killing them....still not quite what i want
jyk: think i like idea #2.
how should i graphically represent this "boundry"? so when the player sees it they know they are near the edge of the play area and need to turn around or lose control of their ship
empirical2: better about bad ass aliens killing them....still not quite what i want
jyk: think i like idea #2.
how should i graphically represent this "boundry"? so when the player sees it they know they are near the edge of the play area and need to turn around or lose control of their ship
Audibly only. The boundary should be far enough away from anything the player could conceivably care about that the only time she should encounter it is when she goes to see what's at the edge of the universe. Putting a big blue line there exposes the specifics of the game mechanic in a presence-breaking manner; having the player warned, then suddenly corrected, simply says "that's too far", keeping it fuzzy and qualitative rather than exact.
A complicated solution would be to have the game take resources about what is contained in areas of the 2d region (you can have empty regions between populated regions by simply not defining them). Make a cell based structure, where the level is streamed and the current scene (9 cells, the current one and 8 around it) is in memory and the cells are loaded on demand. That way you can simply have no cell defined for the far reaches, and randomly generated content or simply no content would exist there. This would work until the variables defining your player location go out of range. Or you could make the x/y locations for the current cell or current set of cells, and have cell co-ordinates also recorded (and manage location changes correctly when the player moves to another cell)
Interestingly, you could also make something the engine parse that marks regions or a set of regions as being a certain type of randomly generated region, allowing different types of enemies to spawn depending on requirements.
You could even put some really interesting secrets and easter eggs in like that.
I can't think of any limitations for that situation that are not simple to overcome, apart from the more complicated programming of such a design.
Many open world games do things in that sort of way.
Another solution would be to have the same idea of different enemies spawning, except gradually make some very tough enemies appear as the player gets farther from the intended area. It's sort of a more gradual way than the skifree solution, with the same eventual outcome forced at some point, but in a more transparent way.
Interestingly, you could also make something the engine parse that marks regions or a set of regions as being a certain type of randomly generated region, allowing different types of enemies to spawn depending on requirements.
You could even put some really interesting secrets and easter eggs in like that.
I can't think of any limitations for that situation that are not simple to overcome, apart from the more complicated programming of such a design.
Many open world games do things in that sort of way.
Another solution would be to have the same idea of different enemies spawning, except gradually make some very tough enemies appear as the player gets farther from the intended area. It's sort of a more gradual way than the skifree solution, with the same eventual outcome forced at some point, but in a more transparent way.
What about proper walls? If the acceptable playing area is surrounded by solid obstacles like canyon or tunnel walls, dense asteroid fields, tall buildings, giant starships, etc. limitations wouldn't appear unnatural and the player won't even think about leaving.
Walls can be lethal or harmless according to taste; for example Transcendence includes large arenas with energy fences that cause very slight damage and almost elastic bouncing.
Transcendence, a very important example of free-roaming space shooter that you should definitely check out, also has a useful incentive structure against delving too deep into the vast interstellar void: on one hand, it is completely blank, useless except to go from A to B in the relatively small occupied area of a star system or for tactical maneuvers; on the other hand, moving burns fuel and (if you don't want to starve and die) range is limited by your ship's reserves.
There's also a softer feedback mechanism against long and pointless travels: as you fly around, fights with an endless supply of "wandering monsters" deplete your resources (armour integrity, fuel, ammo) and force you to periodically go to a space station to make repairs, buy fuel, sell loot, and eventually upgrade the ship.
In a completely blank map, you might adjust entity spawn locations to ensure that if the player drifts far away old enemies keep moving, without wrapping artifacts, and new ones appear interestingly close; reference locations can be adjusted in multiples of the screen size (to preserve coherent formations) or interpreted relative to the player's current position (to preserve the designed encounter ranges).
Obviously, long straight flight shouldn't be encouraged: most enemies should be static or slower than the player (forcing the player to come back to attack them) or significantly faster (forcing a close range dogfight with lots of turning around), not as fast as the player (which would allow long pursuits).
Walls can be lethal or harmless according to taste; for example Transcendence includes large arenas with energy fences that cause very slight damage and almost elastic bouncing.
Transcendence, a very important example of free-roaming space shooter that you should definitely check out, also has a useful incentive structure against delving too deep into the vast interstellar void: on one hand, it is completely blank, useless except to go from A to B in the relatively small occupied area of a star system or for tactical maneuvers; on the other hand, moving burns fuel and (if you don't want to starve and die) range is limited by your ship's reserves.
There's also a softer feedback mechanism against long and pointless travels: as you fly around, fights with an endless supply of "wandering monsters" deplete your resources (armour integrity, fuel, ammo) and force you to periodically go to a space station to make repairs, buy fuel, sell loot, and eventually upgrade the ship.
In a completely blank map, you might adjust entity spawn locations to ensure that if the player drifts far away old enemies keep moving, without wrapping artifacts, and new ones appear interestingly close; reference locations can be adjusted in multiples of the screen size (to preserve coherent formations) or interpreted relative to the player's current position (to preserve the designed encounter ranges).
Obviously, long straight flight shouldn't be encouraged: most enemies should be static or slower than the player (forcing the player to come back to attack them) or significantly faster (forcing a close range dogfight with lots of turning around), not as fast as the player (which would allow long pursuits).
I know this may seem stupid, but considering it's a 2D game, you could as well just make the camera not scroll anymore and force the player to stay on-screen. Sure, that doesn't seem natural at all, but games aren't known for matching reality, and a rule like the one I've described is a well-known gaming idiom.
And of course, you could just put some kind of walls =P
EDIT: gah, this is what I get for reading too quickly. Well, yeah, walls could be anything. You could even make a special barrier that doesn't seem to make sense in the scenery but is an obvious gameplay element. Again, players know that the game doesn't really match reality, and expect game-specific rules to apply.
And of course, you could just put some kind of walls =P
EDIT: gah, this is what I get for reading too quickly. Well, yeah, walls could be anything. You could even make a special barrier that doesn't seem to make sense in the scenery but is an obvious gameplay element. Again, players know that the game doesn't really match reality, and expect game-specific rules to apply.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
