2D Shooters on BYOND...possible? [Video Inside] in Design Philosophy

Page: 1 2
ID:151660
 
Oct 1 2009, 4:28 pm
http://www.youtube.com/ watch?v=l90QKqinMRQ&feature=player_embedded

So I guess BYOND doesn't embed youTube videos... but....


Would anything like that be REMOTELY possibly with BYOND?

Edit: Specifically, the shooting system/interface along with pixel movement
#1 Oct 1 2009, 4:45 pm
There have been 2d shooters on BYOND before, maybe not with pixel movement, but yeah.


It was called ArmiesOfTwo by Gotenks1992, i think.
#2 Oct 1 2009, 4:51 pm
That would certanly be possible. It would take a lot of work for sure.
#3 Oct 1 2009, 5:03 pm
Everything is perfectly possible for a single-player game (except you can only update the mouse position on a tile basis, iirc) but the pixel movement and smooth aiming falls apart in multiplayer.

D4RK3 54B3R's Faction Wars was a pretty good example of how far you could push the system before 4.0. I would suggest looking into SuperAntx's Decadence for a more current example.

Shadowdarke's Pixel Projectiles would be a good place to start if you wanted to make your own.
#4 Oct 1 2009, 7:01 pm
In response to DarkCampainger (#3)
I think that pixel projectiles are too laggy for shooters regardless, though. Any decent number of pixel projectiles on the screen will ruin the framerate and network lag.

A while back, DarkCampainger explored the use of trigonometry and geometry to cast rays rather than fire projectiles. I think that this is a far more feasible system when dealing with a large number of projectiles (bullets) in a short period of time.
#5 Oct 1 2009, 7:24 pm
The concept is doable, but it wouldn't result in anything that smooth.
#6 Oct 2 2009, 2:18 am
In response to DarkCampainger (#3)
As DarkCampainger mentioned, an internet-multiplayer platformer with non-atomic movement is not something BYOND handles very well using it's standard client/server model. Note that there are a lot of caveats in that statement, though:

- Gakumerasara has demonstrated that a server/server (or client/client, however you think of it) model can address scale and latency issues.

- Given the proper game design, some games may be able to get away with using standard atomic movement. Atom-platformers rarely play well, though, so I don't suggest this route.

- LAN handles BYOND's networking needs much more effectively than WAN (like the internet). IainPeregrine.JeetKuneDo was designed and tested on a LAN, as is another game I'm currently working on. You can even mix WAN and LAN players in the same game: connect your LAN players to regular characters, but allow WAN players to control less time sensitive game elements, like a support/medical/artillery droid that follows behind the gun toting players. In its most reduced form, your LAN players can play the game while chatting with their friends who are watching from the internet.
#7 Oct 2 2009, 2:32 pm
It looks good and smooth right now, but is that based on a real multi-player game session or is it just a offline test run?
#8 Oct 2 2009, 3:10 pm
In response to Foomer (#5)
Foomer wrote:
The concept is doable, but it wouldn't result in anything that smooth.

That's exactly what I was thinking :(
#9 Oct 2 2009, 6:02 pm
In response to D4RK3 54B3R (#4)
I'd ignore actual projectile objects in favor of instantaneous shots. Then the math could be done behind the scenes and players would only need to see animations at the start and end points. (I did this in Webcrawl.)
#10 Oct 3 2009, 6:16 am
In response to ACWraith (#9)
I also did this in ER, everyone's got in the habit of using projectiles when really they aren't needed (in some cases sure, they will be needed).

By substituting simple math for sprites you save the server from a lot of stress.
#11 Nov 17 2009, 12:50 pm
In response to Crashed (#10)
I'm currently working on a little zombie invasion game which has a similar control scheme, but I still use tile-based movement. You have to decide what is right for your game but pixel-based, as people said, gets complicated and generates a lot of overhead if you're not an expert programmer. One feature I had before but since removed was that if you clicked on the head of a zombie, you would get a headshot. Detecting the pixel coordinates of a mouse click is fast and easy, and allows you to incorporate pixel-based HIT detection without fancy ray tracing or whatever. But, I ended up removing this because it was more fun to just blast zombies than try to get accurate shots all the time. It's up to you, but people are expecting tile-based games on byond so if you can make it work with that, you might as well, rather than spending so much effort on a pixel-based system that won't really impress people considering the drawbacks in latency and all that.
#12 Nov 23 2009, 9:58 pm
Unless it's a matrix game, seeing bullets is silly. I'd rather see instantaneous damage. If it hits a blood splatter appears on the target, if it misses the area gets effected.
#13 Nov 23 2009, 10:19 pm
I think BYOND's mouse-tracking is a little underdeveloped for this (you have MouseEntered() on a per-tile instead of per-pixel basis), and even then it's a little slow (see the reference for more information).

You could set it up a little differently, where instead of having the character look at the mouse at all times, it responds to Click() calls---move the person around with the arrow keys as usual and then click on the screen to have the mob face the clicked point and shoot at the resulting angle.
#14 Nov 24 2009, 5:15 am
In response to Kuraudo (#13)
Actually, MouseEntered() has had the capability to give you the pixel coordinates of the mouse for some time now. Look up "mouse control" in the DM reference.

Click() isn't always sufficient. For some weapons, like say a submachine gun, a developer may want to use MouseDown() and MouseUp() instead so that fully automatic fire can truly be fully automatic fire. Though, MouseDown() and MouseUp() are a bit slower than Click(), last I checked.


Something I'd like to see is a system that is akin to Infantry Online. Where you're given keys to turn and to strafe rather than aiming with the mouse. Something like this would completely eliminate the need for Mouse procs and may be faster in the end, though may be somewhat difficult to create graphics for something like this.

Crashed had that in the works actually, with a shooter of his, but that didn't really go through.
#15 Nov 24 2009, 7:02 am
In response to D4RK3 54B3R (#4)
D4RK3 54B3R wrote:
I think that pixel projectiles are too laggy for shooters regardless, though. Any decent number of pixel projectiles on the screen will ruin the framerate and network lag.

A while back, DarkCampainger explored the use of trigonometry and geometry to cast rays rather than fire projectiles. I think that this is a far more feasible system when dealing with a large number of projectiles (bullets) in a short period of time.

My PixelProjectiles library actually has all the math for raycasting, though it undoubtedly is a little slower than a system optimized for that alone. Examine the "instant" shot in the demo. :)

Ironically, that library was based off of an earlier work of mine that was purely math based with a missile() call to show the bullet. You can see the basis of that system in Post [link]. (The sgn() and sd_get_dist() procs are provided later in the same thread.)
#16 Nov 24 2009, 7:36 am
In response to Kuraudo (#13)
Kuraudo wrote:
You could set it up a little differently, where instead of having the character look at the mouse at all times, it responds to Click() calls---move the person around with the arrow keys as usual and then click on the screen to have the mob face the clicked point and shoot at the resulting angle.

This is pretty much what I do and it works great in a multiplayer environment. You're best off creating a game tailor-made for BYOND with BYOND's limitations in mind rather than trying to make a hacky, watered-down version of 2D Counter-Strike. One-to-one precision controls shiny graphics just worth the huge performance hit, especially for an action game.

As for pixel movement, I'd hold off for now and just use the tile system. The client pixel variable seem to be a bit...unstable. It has all sorts of problems ranging from screen flickering to outright crashing. It's not quite ready to be used for pixel movement.
#17 Nov 24 2009, 12:16 pm
In response to The Naked Ninja (#12)
Lots classic arcade games show the bullets. Nothing new there.
#18 Nov 24 2009, 1:59 pm
In response to D4RK3 54B3R (#14)
D4RK3 54B3R wrote:
Actually, MouseEntered() has had the capability to give you the pixel coordinates of the mouse for some time now. Look up "mouse control" in the DM reference.

So you're saying that you can use MouseEntered() in such a way that if you move the mouse around without entering/exiting a tile, it will generate updates to the mouse coordinates?

In the video, if you moved the mouse up two pixels, the character followed. In DM---as far as I'm aware---you would have to move it up 32 pixels (or whatever the atom size is, I guess) to generate the next message. That doesn't model the mouse-following interaction of the video at all.
#19 Nov 24 2009, 3:20 pm
In response to SuperAntx (#16)
SuperAntx wrote:
Kuraudo wrote:
You could set it up a little differently, where instead of having the character look at the mouse at all times, it responds to Click() calls---move the person around with the arrow keys as usual and then click on the screen to have the mob face the clicked point and shoot at the resulting angle.

This is pretty much what I do and it works great in a multiplayer environment. You're best off creating a game tailor-made for BYOND with BYOND's limitations in mind rather than trying to make a hacky, watered-down version of 2D Counter-Strike. One-to-one precision controls shiny graphics just worth the huge performance hit, especially for an action game.

As for pixel movement, I'd hold off for now and just use the tile system. The client pixel variable seem to be a bit...unstable. It has all sorts of problems ranging from screen flickering to outright crashing. It's not quite ready to be used for pixel movement.

Must... play.... Decadence!
Page: 1 2