23% (4)
23% (4)
23% (4)
17% (3)
11% (2)Got a preference on duration?
Poll: What competition theme would you prefer?
Login to vote.
| |||||||||||
May 26 2011, 1:33 am
|
|
Stephen001
  |
Definitely a strategy game theme. BYOND is remarkably good for strategy games, and it's an undervalued genre here.
|
BYOND can't do Real-Time strategy because it doesn't support client-side selection boxes. Turn-Based strategy or dice games are just kinda boring.
Sidescrollers would be most appropriate at this point in time. Forum_account is always looking for ways to push his pixel movement lib onto others. If everyone was using it for the same competition we'd at least see a few improvements out of it, maybe even a finished game. | |
BYOND can't do Real-Time strategy because it doesn't support client-side selection boxes. Why does it have to be done on the client? Having all input processed by the server is a rare thing, but BYOND handles it reasonably well for most genres. If action games work, I don't see why an RTS wouldn't. | |
Why does it even need selection boxes?
Consider the Shogun/Empire series, where classically you select whole bodies of men at a time, and typically via single click on the body of men, or a ribbon with unit status. | |
Forum_account wrote:
Why does it have to be done on the client? ...but BYOND handles it reasonably well No, it doesn't. You can't even attempt to argue about this one, trying to have a server-side selection box is just silly. It would be much better to have a MouseSelection() proc like we do with MouseDrag(). Stephen001 wrote: Why does it even need selection boxes? Selection boxes are a very important part of an RTS's user input. It's like the second joystick in a duel joystick shooter. Sure, you could try to work your way around it but what you'll end up with will never be comparable to Starcraft. | |
SuperAntx wrote:
No, it doesn't. You can't even attempt to argue about this one, trying to have a server-side selection box is just silly. It would be much better to have a MouseSelection() proc like we do with MouseDrag(). MouseDrag() is executed on the server. I don't follow you. I suppose you can't update the graphical selection box on the client, but almost all visual effects are managed by the server. You can't update the player's position on the client, but games still feature movement. There's nothing that makes the RTS selection box different than anything else. | |
Forum_account wrote:
MouseDrag() is executed on the server. I don't follow you. What I was saying is the client should be able to screw around with the selection box on their end without any graphical lag, then when they're finished a MouseSelection() proc is triggered with a list of all the tiles in their selection box. I suppose you can't update the graphical selection box on the client This is what makes the idea of even considering a server-side selection box silly. | |
If we were talking about making a multiplayer RTS game from scratch then I'd agree that handling the client input on the server is silly. But we're talking about BYOND, and the BYOND server handles everything. The server handles all other input with acceptable amounts of latency, this would be no different.
I'll vote for RTS. I suggest putting together some code to provide contestants with a skeleton to work from. It levels the playing field a little and saves everyone time. | |
Forum_account wrote:
The server handles all other input with acceptable amounts of latency, this would be no different. No, this is where you're mistaken. When you push a button you send the server a command and your character runs it. Your business with the command is done as soon as you push the button. Having a selection box should be more like that. The client should be able to mess around with the selection box on their end, when they're done the command is sent to the server and some sort of MouseSelection(listofatoms,startpoint,endpoint) proc is called. | |
When you push a button you send the server a command and your character runs it. I'm not sure what you mean by "and your character runs it". The server runs the command and any actions that result from the command (movement, animations, objects spawned, etc.) are sent back to your client. Your client sends a command to the server and waits for a response before anything is updated on the client's end. This similar sequence happens whether you're pressing an arrow key to move or clicking and dragging the mouse. The client should be able to mess around with the selection box on their end, when they're done the command is sent to the server and some sort of MouseSelection(listofatoms,startpoint,endpoint) proc is called. I agree that this would be optimal, but it doesn't mean that suboptimal methods won't work. | |
Forum_account wrote:
The server runs the command and any actions that result from the command (movement, animations, objects spawned, etc.) are sent back to your client. Your client sends a command to the server and waits for a response before anything is updated on the client's end. You are correct. This is how commands are executed. There are multiple steps in the process. What I'm talking about is making the first step better, the step where the client sends its command to the server. I agree that this would be optimal, but it doesn't mean that suboptimal methods won't work. There are many ways around it. Starcraft for example allows you to ctrl+click and shift+click units to put them into different control groups. While these operations are nice to have, they're still only supplemental to the selection box. | |
random generation
| |
I wouldn't want to play a Starcraft particularly as it is, there are a few veins of strategy that can be explored here, and so it makes good competition material. Doubly so if Forum_Account's line of thinking holds and you get an acceptable selection box thing going on.
Better than the current stream of map generation and side-scroll demo play-tests everyone is currently having a whirl at, at least. | |