Closed GoogleCodeExporter closed 8 years ago
[deleted comment]
Nah, it should be with collision detection, derby style a la FlatOut games!
Original comment by tapiovie...@gmail.com
on 21 Mar 2011 at 8:19
[deleted comment]
I'm changing the title to network multiplayer as a split-screen multiplayer
would be a completely separate issue.
I suggest that we use p2p (instead of client-server), so that we don't need to
bother with a game server (and I suspect we'd have 2, maybe max 4 cars, so the
p2p network management is not so hard).
For the networking library, I'd suggest http://enet.bespin.org/, which
originates from first-person shooters Cube and Sauerbraten and as such is
designed to be low-latency. It uses UDP protocol (to deal away the overhead of
TCP's package checks etc.) but provides automatic splitting of too long
packages and optional reliability, so we can easily and quickly spit unreliable
state data, but also send messages that must reach the destination (without
implementing our own check-resend layer).
Feel free to contest enet, and/or add you own suggestions with rationales.
This thing probably should be developed in a separate branch.
Milestones I can think of:
* Branch with a networking library as part of the build system, possibly some wrapper code to easen the usage, config vars to enable networking and then library init/deinit bits to code
* Simple p2p "Hello world" networking (e.g. push a button and the other peers see a message and vice versa).
* Initial multiplayer implementation (might be a bit laggy at this point still)
* Lag compensation and good collisions
* Polished, easy-to-use GUI interface (lobby)
* Multiplayer gameplay (e.g. determining and announcing winner etc)
* Master server for match making (should probably be split to a separate issue later on)
Implementation notes:
* Although 2-player games are most likely to make sense on such narrow roads, the networking should be built for more from the start (e.g. not just use one otherPlayer-variable but instead a list that is looped for players (and could theoretically hold arbitrary number of players)
* If there are random seeds involved (paged geometry?), they must be synchronized to all clients (or alternatively use pre-determined, hard-coded seeds).
I'm personally interested in this, but have currently limited time, so I wrote
my thoughts if someone feels like starting before I can.
Also upping prio a bit, I'd like to challenge the dev team into a race! :P
Original comment by tapiovie...@gmail.com
on 11 Apr 2011 at 12:56
There's now a branch called "networking", which has ENet added as a dependency.
Not much else to see yet.
Original comment by tapiovie...@gmail.com
on 12 Apr 2011 at 2:35
Original comment by tapiovie...@gmail.com
on 17 Apr 2011 at 8:02
A status update.
The first and second milestones mentioned in comment 4 are pretty much done.
There is still a lot to tweak, polish and test, but it seems that the p2p
network can now create all the missing links automatically after a new peer has
connected to an arbitrary member of the network.
There's also a simple master server implementation that should work and also
the client side bits for communicating with it, although they are not yet used.
This kind of completes most of the last milestone.
The area where I struggle the most is the GUI. I have visions (and mock-ups)
about it, but kind of hate dealing with MyGUI, so if someone wants to help
there, it would be much appreciated.
Original comment by tapiovie...@gmail.com
on 4 May 2011 at 6:10
[deleted comment]
[deleted comment]
A status update.
Cryham has been crafting the GUI and I have implemented most of it's important
functionality, so we have been able to test both p2p networking as well as
announcing games to the master server without ugly command line hacks. There's
still stuff to polish and tweak, but the GUI is already functional.
My rough estimation of remaining tasks and their sizes (procents are for the
Progress label):
10% Polishing and completing the GUI
30% Implementing the actual networked racing
10% Gameplay features (winners etc.)
10% Debugging crashes in the "final product"
Original comment by tapiovie...@gmail.com
on 9 May 2011 at 9:14
Since last comment to this issue is from before summer, a quick status update:
The development has been very slow, but there are now some code to send and
receive in-game car updates. It doesn't work yet, but we are roughly at a point
where I actually need to test and find the bugs rather than knowing beforehand
that something is not yet implemented.
Original comment by tapiovie...@gmail.com
on 1 Nov 2011 at 8:29
Development still much slower than I'd like, but an important milestone has
been reached: A game with two cars can be started and the car
position/orientation is updated between the clients, so that other player's
movement can be seen.
It's full of bugs for now, but this is definitely a good place to continue,
perhaps with renewed enthusiasm. I'm upping progress to celebrate :)
Original comment by tapiovie...@gmail.com
on 27 Nov 2011 at 8:15
Another update so soon!
I've tweaked the networking code and local testing suggests the car state
syncing works rather smooth now. Need to do real networked testing to tune some
parameters, but looks very promising.
Technical stuff: basing the syncing only on linear and angular speed works
surprisingly well due to having full physics simulation on the remote cars. Of
course over time there is bound to be error, so the received absolute position
and orientation is also used, but they are not forced, but rather interpolated
with physics engine estimation in order to counter jerkiness. Wheel states are
not yet synced, but they will be as it can lead to better simulation and
animation.
Apart from all the gameplay stuff like determining winner, there's also a pile
of GUI related work to be done, such as game password protection, using proper
cars for remote players, track syncing stuff etc - all of which have some code
already but need to be finished.
Original comment by tapiovie...@gmail.com
on 28 Nov 2011 at 9:55
Original comment by scrawl...@gmail.com
on 30 Nov 2011 at 3:30
Correct cars are now created for the players. Also, track as well as other game
property updates are communicated from the host to the other players.
Multiplayer gaming should not require quirks (like manually changing different
local cars to match the remote peers' choices) anymore.
I'm thinking that as soon as we get 1.4 out of the way, networking branch could
be merged to master and finalized there.
Original comment by tapiovie...@gmail.com
on 30 Nov 2011 at 9:21
We need urgently
1. other car positions on minimap (issue 102),
2. text nicks above cars,
3. hiding panel for gui Track tab.
Write down more if you know. (I'll try to add it)
Original comment by Cry...@gmail.com
on 21 Dec 2011 at 9:47
[deleted comment]
[deleted comment]
done 3. hiding panel for gui Track tab.
use: panelNetTrack->setVisible(true);
Original comment by Cry...@gmail.com
on 25 Dec 2011 at 12:14
Direct connect works, password protection and protocol versioning have advanced
(though not yet completed), only host can now change track and now the track
tab stats are synced with the game tab track.
Original comment by tapiovie...@gmail.com
on 26 Dec 2011 at 12:08
done 1. other car positions on minimap (issue 102)
Original comment by Cry...@gmail.com
on 26 Dec 2011 at 5:04
Tasks blocking (first) release:
* (medium) NAT punch-through / UPnP etc; i.e. make host's life easier
* (medium) Winning (lap tracking, winner announcing etc.)
* (smallish) Finish password protection and protocol versioning
* (small) Handle track reversion, boost_type and flip_type (and possibly other)
config vars
* (tiny) Do testing on race countdown start synchronization
I don't think issue #123 is blocking, but issue #102 could see some
improvements.
Original comment by tapiovie...@gmail.com
on 9 Feb 2012 at 8:16
Done:
* (medium) Winning (lap tracking, winner announcing etc.)
Looks bad, suggestions are welcome.
Original comment by Cry...@gmail.com
on 28 Feb 2012 at 8:02
Improved:
* (medium) Winning (lap tracking, winner announcing etc.)
has now separate window at end and winning messages on HUD.
Done:
* (small) Handle track reversion, boost_type and flip_type (and possibly other)
config vars
There are few small, new issues I'm going to solve.
Original comment by Cry...@gmail.com
on 17 Mar 2012 at 7:15
Original comment by Cry...@gmail.com
on 17 Mar 2012 at 7:15
Nearly there. Just testing.
Original comment by Cry...@gmail.com
on 1 Apr 2012 at 5:44
[deleted comment]
Ok. I'm closing. Congrats to all :)
If there is feedback then in new issues.
Original comment by Cry...@gmail.com
on 8 Apr 2012 at 7:50
Original issue reported on code.google.com by
Cry...@gmail.com
on 21 Mar 2011 at 8:13