Multiplayer Games

Discussion and feedback on Construct 2

Post » Wed May 08, 2013 5:52 am

[QUOTE=LucasTorres] [QUOTE=jayderyu]
@LucasTorres
Yes, You could do DDtank like game. However, that game looks like it will have a lot of server based code. So it's going to be a lot of work and at this moment. Your going to need to learn a programming language... unlsess of course some one get's a cluster network going :)


I don't know. This wave of "is there online multiplayer" questions has a different feel to it.
[/QUOTE]

I work with Web Development Web.I know PHP.
is enough?

Sorry for language mistakes, I'm Brazilian and beginner in English[/QUOTE]

I'm not bothered by your English. I speak and write English as my native and only tongue, yet I am very poor at writing :D

no, PHP will not be enough for anykind of real time game play. Not only does PHP over TCP, PHP also script handling isn't as fast. PHP is meant to serve up core data and web pages.

However, you can use PHP for all the inventory and character management. but you will need at least Websockets for gameplay. You can use Velotjet plugin for that :)
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Wed May 08, 2013 8:41 am

Ok, let me see what we can whip up in the coming time.

It would be a bit more complicated than only a websocket rerouting messages.

We would add message-queues and a few commands so the controller can tell the server software (native binaries, no interpreted languages like .Net, Java or PHP) to handle some cases autonomously for performance.

Also there would need to be some provision for spawning new processes and commands for booting/blocking users.

I think a 'server' plugin and a 'client' plugin would make things easier for the developers in that you then can have events like 'on new client connect', 'on new session created' etc...

The client plugin then can have events like 'on joining new session' etc...

The biggest fun will be to make it scalable and performant. But then again, that *is* what I do for a living :)

@Jaderyu if you want to have a banter on this; let me know. I am going ahead with this, but maybe we can find a good modus operandi so you can still quit your current daytime job, or at least make a nice extra from it :)

With kind regards,
                  Adrianus
B
5
S
1
Posts: 11
Reputation: 750

Post » Wed May 08, 2013 12:12 pm

Update:

Well, I modified the websocket plugin a bit and fired up the server. It works pretty smoothly with queues and other parallelism-stuff in place so it can be scaled across multiple servers.

Now to make multiplayer easier to build, I think the plugin should have a few more actions, conditions and expressions specifically geared towards mp. So I want to recode it to a specific multiplayer plugin.

In the text below, the GUID's are client-specific(!). This means the server will translate them for each user transparently, but they will be different for each client. The reason for this is that a client can not subscribe to channels that are not available to him and guessing will not do him any good.

Things that I came up with on the top of my head are:

Actions (client):
- "Connect", param is API key, param is hostname/url: To connect to the server and to differentiate which game should be matched up with which controller/session manager (the API key is different for each type but consistent amongst all clients)
- "Set Nickname": just a label that can be shared with other players instead of the GUID
- "Subscribe Channel", param is channel GUID (will get to that in expressions): subscribes to messages from a specific channel. A channel is nothing more than an identifier to a specific stream of messages. Like a forum-thread, a mailinglist or an IRC channel. You should be able to use more than one channel if games have 'friend chat' or 'allied chat vs foe chat'. But also you can use channels to prioritize message handling (doing all the movement messages as fast as possible, doing the chat messages just once in a while).
- "Unsubscribe Channel", param is channel GUID: obviously you may want to quit a game or turn off the chatter from others.
- "Send Chat", param is channel GUID, param is message: I think it is best to have different message-types, so the server (and your controlling C2 code) can differentiate and process accordingly. Basically the server could ignore everything but game-specific messages and have all other types be rerouted blindly.
- "Send Command", param is channel GUID, param is message: this message type is for things like store/save/pause/taunt/give/take etc. type of messages. They are ingame but not necessary realtime
- "Send Realtime", param is channel GUID, param is message. These messages should be processed with the highest priority.

Maybe things like "Send Object", param is channel GUID, param is instance should be added so you can pick an instance and send the whole coordinates, velocity, behaviour params etc. directly to the server... have to think about it.


Actions (server):
- "Connect", param is API key, param is hostname/url: To connect to the server and to differentiate which game should be matched up with which controller/session manager.
It is important to understand that there need to be two server projects: 1 is the controller that basically handles all the boring lobby/matchup etc. code. The other gets started every time a new session starts and this is the one that handles the game and the players.
- Create Session, param is GUID: This tells the server to fire up a new controller and hand the GUID to it.
- Create Channel, param is name, param is type: You should be able to create global channels (i.e. for a lobby or for messages across sessions, moderator chat etc.) and session channels. Session channels will be created per session (duh) and global channels only once.
- Allow Channel, param is channel name(!), param is client GUID, param is R,W or RW: You should be able to mute clients or maybe you want the input on 1 channel and have the output on a different one so you can make life easier when copy/pasting event sheets.
- Forbid Channel, param is channel name, param is client GUID: Almost the inverse of the above, but not quite.
- Set Messagetype Policy, param is channel name, param is messagetype, param is policy (passthrough, block, handle): If the policy is passthrough then the messages will never arrive at your server Construct 2 code but be rebroadcasted to every client in the channel. Handy for chat or if you want clients to handle messages. Block is if you don't want events to happen for your server code.
- Disconnect Client, param is client GUID: closes the connection to the client.


Conditions (client):
- "On Chat message", "On Command message", "On Realtime message": Conditions are true if 1 or more messages for these have arrived. Probably should handle the messages in a for each loop except for the realtime (as a backlog may cause more delay, so realtime messages that are not processed before the next one arrives maybe should be dropped... have to think about this as well)
- "On Subscribe success", "On Subscribe fail": When a subscribe to a channel succeeds or fails.
- "On Send error": if a message sending has failed.

Conditions (server):
- "On client connect": whenever a new client arrives (maybe needs a client object....need to think about this)
- "On client disconnect": If a client connection drops or the client just quits the game. Your code should then decide whether the game can continue (if it is a MMORPG type) or if it should quit (if it is a 2-player card game).
- "On Chat message", "On Command message", "On Realtime message": Conditions are true if 1 or more messages for these have arrived. Probably should handle the messages in a for each loop except for the realtime (as a backlog may cause more delay, so realtime messages that are not processed before the next one arrives maybe should be dropped... have to think about this as well)
- "On Send error": if a message sending has failed.
- "On Session Ended": If a session has finished.

This is just a scrapbook list of things that, in my opinion should be available and which make it possible to handle a Construct cluster as a service.
Let me know if you can think of others or better ones. I will think about the expressions as well.

With kind regards,
                 Adrianus Warmenhoven
B
5
S
1
Posts: 11
Reputation: 750

Post » Wed May 08, 2013 4:48 pm

@awarmenhoven
What I do for a living is hold people down for nurses to restrain or look mean at drunks :D. Has nothing to do with computers :D

I'm keen on the idea of team project to get C2 a networking framework. I'll PM you with my email address. or maybe we can start a new thread in the game design area :)
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Wed May 08, 2013 5:06 pm

singular Send Object would be better.
client.SendObject(channel, object)

of course if you have anything that would says differentiating Chat/Command/Realtime would be better. I'll read anything in that design. But off the bat, I can't think how dividing the message structure would be better.

It would seem that the difference is best handled by the server with channel and session. I don't see a big difference between Chat and Command especially with Channel type.

Also if Realtime priortizizes a queue based on a threaded design. I don't think it will matter that much. if it's in a single thread design where the realtime queue needs to be empty before handling Chat/Command. Then Chat/Command could suffer at higher loads. At least that what sounds like it could happen :D

Also a way to get SessionList by game key/name... so on etc.
client.GetSessionList(apikey)

Finally. Are you planning to build the routing/server infrastructure from scratch. Or use an already existing server base. Personally i think it wuld be better to build on top of an existing core engine to reduce work :P

I think we should stop de-railing the guys thread :D
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Wed May 08, 2013 6:34 pm

@jaderyu my email addy is not hidden it is to be found at http://www.warmenhoven.co/contact/ (I do this in the form of a link as that page has a spamtrap and so my email address is not out in the open).

Now, as for your comment on derailing; let's use email after this.

And as for your comment on frameworks: I rather not use existing code as that tends to give bloat, lag and bugs. But the main core of messaging, scaling, clustering and all that large scale stuff is almost boilerplate for me as I have an extensive library.

I just finished up making it so that I can have any number of clients, any number of controllers and any number of physical servers, so that is taken care of :)

We should rather talk about the object/communication/plugin/usability design and I think we can have good banters on that :)awarmenhoven2013-05-08 18:35:46
B
5
S
1
Posts: 11
Reputation: 750

Post » Wed May 08, 2013 9:23 pm

For the record, as the developer of two multiplayer plugins (MultiPlayer and PhotonClient), I'll just set out here what my angle is on awarmenhoven's proposal:

My aim has been to produce plugins/behaviors that operate at a much higher level of abstraction, to make it as easy as possible for those who want to get into multiplayer gaming but have limited experience of low-level networking - or simply prefer to work with higher level operations. So, here's the very different basic set of ACEs in my C2 plugins/behaviors:

- Condition: New web player has joined
- Condition: Web player has been updated
- Condition: On collision with another player
- Condition: Web player/s to be created
- Condition: On my player moved
- Condition: Web player has left (use this to destroy the associated sprite)
- Condition: Game server is ready

- Action: Set the web player's ID (from the C2-allocated UID)
- Action: Initialise data of web player to create (from the server-allocated client ID and its current x/y coordinates)

- Expression: Get current X co-ordinate of web player
- Expression: Get current Y co-ordinate of web player
- Expression: Get web player's C2 UID
- Expression: Get number of web players to make (on joining game)
- Expression: Get the player's server-allocated UID
- Expression: Get the player's name
- Expression: Get the player's current score
- Expression: Get the player's current health

I'll continue on this development line, but follow awarmenhoven's work with great interest Velojet2013-05-08 21:28:11
B
105
S
20
G
12
Posts: 549
Reputation: 20,320

Previous

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 7 guests