MP Keen - Let's do it
- BlueGasMask
- Vorticon Elite
- Posts: 382
- Joined: Tue Nov 20, 2007 9:56
- Location: Wellington, New Zealand
- Contact:
MP Keen - Let's do it
there's been some talk about it, we should do it. Unfortunately to make the game multiplayer or even have alternate weapons there would be huge problems with using the old vorticons or galaxy engines so it's probably a good idea to either make it from scratch or try and build on Commander Genius. Either way this is going to take a hell of a load of work but if we can do it it'll be totally worth it. Who's with me?
- kuliwil
- Blue-tongued Yorp
- Posts: 1731
- Joined: Wed May 12, 2010 8:51
- Location: Facestalking Commander Spleen.
- Contact:
Re: MP Keen - Let's do it
I'm with ya.
I don't know how to mod well, so I'd be happy to help with sprite development and such in a minimal, time-restricted capacity.
CAN'T WAIT!!!!!!!
I don't know how to mod well, so I'd be happy to help with sprite development and such in a minimal, time-restricted capacity.
CAN'T WAIT!!!!!!!
"Hi, I'm Tom Sellick's moustache."
This seems to me like the nth thread about this topic, but well, as I see it the CG engine has already started to incorporate a few multiplayer ideas, so let's stay with it.
The multiple weapons idea, as in the pic posted by Ceilick somewhere would be pretty neat. But yeah there the real work would begin. Things like co-op or turn-based MP can easily be done in the original levels, but the multiple weapon feature calls for special deathmatch arenas.
Also, what most here crave is, I believe, internet support for MP.
The multiple weapons idea, as in the pic posted by Ceilick somewhere would be pretty neat. But yeah there the real work would begin. Things like co-op or turn-based MP can easily be done in the original levels, but the multiple weapon feature calls for special deathmatch arenas.
Also, what most here crave is, I believe, internet support for MP.
You crack me up little buddy!
Two things, first I would like to point out that this isn't really the right section to post this topic in, and secondly I'll point out how many other things we have to do with CG right now.
Once we have support for Keens 4-6 development will shift from Galaxy support to Dreams support and multiplayer. Dreams support is a feature that will eventually occur, but we are uncertain when.
As far as multiple guns goes, I don't know. That is definitely something we could do, but it could prove difficult to pull off well.
I do want development done on Multiplayer Deathmatch levels, for the vorticons games.
Once we have support for Keens 4-6 development will shift from Galaxy support to Dreams support and multiplayer. Dreams support is a feature that will eventually occur, but we are uncertain when.
As far as multiple guns goes, I don't know. That is definitely something we could do, but it could prove difficult to pull off well.
I do want development done on Multiplayer Deathmatch levels, for the vorticons games.
Then again that could be done in some sort of mod and not in the original CG, as it should use keen resources as a base... After all the new guns would change the gameplay a lot and are fan-made.pizza2004 wrote:As far as multiple guns goes, I don't know. That is definitely something we could do, but it could prove difficult to pull off well.
- Commander Spleen
- Lord of the Foobs
- Posts: 2384
- Joined: Wed Oct 31, 2007 22:54
- Location: Border Village
- Contact:
Welp, we could always make a tech demo that can be adapted into CG later. (I'm mostly liking the way it's turning out after seeing the latest snapshot, and it definitely has potential to be the standard way of playing Keen within a couple of years.)
Who do we have here with coding skills? I have enough network programming experience to create a basic concept. But it would be greatly sped up if someone can help work on aspects like physics and loading levels and graphics data.
Who do we have here with coding skills? I have enough network programming experience to create a basic concept. But it would be greatly sped up if someone can help work on aspects like physics and loading levels and graphics data.
Actually, if you have networking experience, it would be great to have you just help work on CG. If you really want, you can just use CG as a base and build what you want from that, then it would be much easier to implement back in later.
I would also like to establish bases for what I would like a multiplayer Deathmatch map to look like. These will of course need major testing, and I don't expect comprehensive Multiplayer support for at least 6 months, if not a year. Till then, we will be doing various things to improve what we have in all areas of the interpreter, as well as adding new features.
Maps should be:
Basic/Small: 50x25 minimum size, no enemies, minimum of three weapons spawn points maximum of 5.
Intermediate/Medium: 100x50 minimum size, up to 3 enemies, Minimum of six weapons points maximum of 12.
Advanced/Large: 150x75 minimum size, up to 20 enemies, Minimum of 8 weapons points no maximum.
Other than that, we will need some multiplayer things that are specific to each episode, such as teleporters in Keen 1 during deathmatch, and similar things in 2 and 3. Also, every map needs to have at least two spawn points, but 4 is preferable. (I don't think there is a high demand for three player maps.)
A few exceptions, anything that doesn't harm you (yorp, butler) is not strictly an enemy, and I will allow the level creator to use their own discretion when adding them, but make sure they aren't annoying. And don't make your level so huge that it isn't fun, unless there is something special about it.
Other than that, I can't think of much, so anyone who wishes, have a fun time designing some deathmatch levels, and we will make a dynamic loader that just loads maps from the deathmatch folder inside the episode folder.
I would also like to establish bases for what I would like a multiplayer Deathmatch map to look like. These will of course need major testing, and I don't expect comprehensive Multiplayer support for at least 6 months, if not a year. Till then, we will be doing various things to improve what we have in all areas of the interpreter, as well as adding new features.
Maps should be:
Basic/Small: 50x25 minimum size, no enemies, minimum of three weapons spawn points maximum of 5.
Intermediate/Medium: 100x50 minimum size, up to 3 enemies, Minimum of six weapons points maximum of 12.
Advanced/Large: 150x75 minimum size, up to 20 enemies, Minimum of 8 weapons points no maximum.
Other than that, we will need some multiplayer things that are specific to each episode, such as teleporters in Keen 1 during deathmatch, and similar things in 2 and 3. Also, every map needs to have at least two spawn points, but 4 is preferable. (I don't think there is a high demand for three player maps.)
A few exceptions, anything that doesn't harm you (yorp, butler) is not strictly an enemy, and I will allow the level creator to use their own discretion when adding them, but make sure they aren't annoying. And don't make your level so huge that it isn't fun, unless there is something special about it.
Other than that, I can't think of much, so anyone who wishes, have a fun time designing some deathmatch levels, and we will make a dynamic loader that just loads maps from the deathmatch folder inside the episode folder.
- Commander Spleen
- Lord of the Foobs
- Posts: 2384
- Joined: Wed Oct 31, 2007 22:54
- Location: Border Village
- Contact:
The problem is, network support will require a pretty hefty rewrite of the core code. Input and movement would need to be completely separate, tied together with a message system. For example:pizza2004 wrote:If you really want, you can just use CG as a base and build what you want from that, then it would be much easier to implement back in later.
Code: Select all
Client: Keypress -> Keypress Message -> Network Command Message -> Network Packet to Server
-> Local Estimation of Resulting Move
Server: Receive Network Packet -> Calculate Outcome -> Network Packet to Client
Client: Receive Network Packet -> Compare Resulting Move with Local Estimation -> Fix If Necessary
Code: Select all
Keypress -> Action
Code: Select all
Keypress -> Keypress Message -> Action
However, there's also the issue of the automated parts such as physics and AI. The randomised actions on the server need to be matched up with those on the client. Should be easy enough to do this with a random seed though.
- Commander Spleen
- Lord of the Foobs
- Posts: 2384
- Joined: Wed Oct 31, 2007 22:54
- Location: Border Village
- Contact:
-
- Vorticon Elite
- Posts: 1246
- Joined: Wed Dec 31, 2008 14:44
- Location: Frankfurt - Germany
- Contact:
Yeah, that sounds a bit complex. I'm not an expert with that, so sorry, I can't say much about besides I'm still working on some bugs and the galaxy support, so I have enough to do right now...The problem is, network support will require a pretty hefty rewrite of the core code. Input and movement would need to be completely separate, tied together with a message system. For example:
Code: Select all
Client: Keypress -> Keypress Message -> Network Command Message -> Network Packet to Server -> Local Estimation of Resulting Move Server: Receive Network Packet -> Calculate Outcome -> Network Packet to Client Client: Receive Network Packet -> Compare Resulting Move with Local Estimation -> Fix If Necessary
We don't have it like Keypress -> Action.Code:
As opposed to what probably goes on at the moment:
Code:
Keypress -> Action
A good start would be at least something like this:
Code:
Keypress -> Keypress Message -> Action
We have it now like this
Code: Select all
Keypress -> Playstructure -> Action
We made it that way, so it's easiert to support joysticks and gamepades of all kind. We might want to extend that structure. However it's pretty much independent. So here we could build on an independant interface. We might have to do some changes, but I think an efficient message queue won't be a huge problem.
I imagine, that it has to check sync of some variables. That could be difficult.That way, at a later date the Keypress Message part can be linked to Network Command Message and the Action part becomes referenced by Local Estimation of Resulting Move, Calculate Outcome and Fix If Necessary.
However, there's also the issue of the automated parts such as physics and AI. The randomised actions on the server need to be matched up with those on the client. Should be easy enough to do this with a random seed though.
- BlueGasMask
- Vorticon Elite
- Posts: 382
- Joined: Tue Nov 20, 2007 9:56
- Location: Wellington, New Zealand
- Contact: