HexScape

[Lyrgard]

Thanks a lot for the tips, Xorlof.
I'll try to make a DIY light tent, and the lego can provide a turntable and camera mount. I'll see how it goes !

I'll gladly use your zombie model, too. I you still have photo shoot of others picture that you didn't turn into 3d model yet, will you be willing to share them too ?

what follows is an answer to Xorlof speaking of HTTP and Websocket and is quite technical and probably boring for not tech-savy people

Spoiler Alert!

I don't intend to make an HTTP or websocket based version of HexScape. HexScape client/server communication are made directly on top of TCP and UDP protocols.
The HexScape server is a simple java application (*.jar) with no gui that open a socket (currently on port 6143) on the server. All you need to run the server is to have java installed.

That being said, if jMonkey evolve to support webGL, a browser based version of the HexScape client would become possible, but that's not for now.

More easilly, HexScape client could be "easilly" ported to Android. One would only need to develop the GUI for android, but all the core functionnalities (including 3D rendering) can be used. HexScape was made with this in mind, all the core functionnalities are in the hexScape_core project and are not tied to any system. For desktops, I went to use Swing to make the GUI, and all Swing specific code are in the hexScape_gui_desktop project. If all goes well, I'll probably some day make a hexScape_gui_android projet to be able to run the client on Android.
HexScape_core exposes services that allow to interact with the game, and shoots events on an event bus to notify when something happens. So all an HexScape GUI client need to do is to bind its boutons to services methods and listens to events to be aware of game state changes.

But I shouldn't get ahead of myself, all that is for a distant futur and IF there is a need for that.

[caps]

Way cool that you're doing this Lyrgard. Wish I could +rep you. I'm also glad to see you're keeping the implementation separate from the interface.

[Porkins]

An Android version would be soooo sweet!

[caps]

Originally Posted by Porkins

An Android version would be soooo sweet!

Yes.

--

Spoiler Alert!

A little off-topic, but I thought Xorlof and Lyrgard might both find it interesting:
The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter

I played this game over LAN with my brother when I was a kid.

[Porkins]

Cool article caps. That game is the source of my screen name. I played that game when I was an adult with random strangers.

[Lyrgard]

Interesting article, caps ! I already intended to use a mix of UDP and TCP, depending of the importance of the packet, and this article give valuable insight on this point.

As for an android version, it'll probably be hard to make one for the small screen of smartphones. For tablet, though, it'll be perfect. Only need to add support for touch input instead of mouse, but shouldn't be too hard.

[caps]

Originally Posted by Lyrgard

As for an android version, it'll probably be hard to make one for the small screen of smartphones. For tablet, though, it'll be perfect. Only need to add support for touch input instead of mouse, but shouldn't be too hard.

I bet you could come up with something. There would be inconveniences and limitations for the user, probably, but maybe not.

[Xorlof]

Interesting read, caps. I've always have enjoyed reading game development postmortems.

I've done a decent share of hobby game programming. You'll find my name in spots on various roguelikes, I've done some "fun" game projects, and most-directly-related to the immediate discussion, I created a Netware IPX to UDP/IP bridge to coerce the original Command and Conquer to play over the Internet instead of just a local network. It worked on other games too, but CnC was the reason I made it. Nothing too exciting, but I've done enough that I feel pretty confident in expressing the following opinions:

Caps' article is, as he says, a little off-topic. The network, transport and session layer lessons learned from a realtime action game coping with the network infrastructure that existed 17 years ago do not apply well to a turn-based game with today's network infrastructure.

Simply put, for this sort of thing, a client/server model with HTTP done Comet-style or WebSockets is where it's at! Why? Lots of reasons:

1. It has low enough latency and enough throughput for a 'scape game. All moves and chats will feel realtime. Basically, I'm saying it'll do the job needed and it will do it well.
2. Good programming libraries exist for this for all major languages which should make implementing it straightforward and will make interoperability (if needed down the road) easier.
3. Being HTTP (or HTTP-ish) traffic means traffic is pretty much guaranteed to be allowed to go out, getting through both perimeter and local *outgoing* firewalls and proxies. This isn't a huge problem yet, but it is increasing. No network provider is going to turn their back on HTTP for the foreseeable future.
4. Sticking with client/server vs peer-to-peer lets the server record all games for player record-keeping purposes, later game reviews, etc. The data can be stored in a central repository and won't be "lost."
5. But MUCH more importantly than #3 or #4, it will addresses two *huge* issues that didn't exist very much 17 years ago related to incoming traffic--doing NAT traversal and getting past incoming traffic firewalls. If you're rolling your own peer-to-peer network communication over some random tcp or udp port, be prepared to deal with those things or you'll have lots of people unable to talk to each other. If not peer-to-peer, you still have to deal with issue #3.

I mentioned only hosting a server here at HSers if it were HTTP or Websockets. We might host something if it is otherwise, but it is much easier to say "yes" if it is those. That's because of security reasons. We can reverse-proxy that traffic through our nginx server, only directly exposing *that* battle-tested code to the Internet, hiding yours behind that protective layer. It also makes traffic inspection easy. (Another plus of the above approach). Also if hosting a server at HSers, I can provide what you need to use HSers login information. A player claiming to be "Xorlof" will be Xorlof, "Lyrgard" will be Lyrgard, and "capsocrates" will be capsocrates.

Of course do whatever works for you, Lyrgard. It's your project after all. Feel free to ask questions if the above doesn't make sense, but that's my opinion. (And I am willing to help with server-side things, including coding, if you want a hand with the HTTP stuff.)

BTW, I *love* the lego camera setup.

[caps]

Websockets are really cool. Got to use them for a work project not too long ago to make a webpage communicate in realtime with some C++ apps.

[Lyrgard]

After reading Xorlof posts and making some research on the internet, here is the new global architecture I'll make for HexScape :


The communications between modules will use buses, decoupling them a lot. Each module can post to the message bus, and each module can subscribe to receive some type of message. The client_core will post message for the server, that the client_network will receive, send to the server_network, that will post them in the server message bus. The server core will have subscribed for rthose message and will receive it. In fact, from the client_core and server_core, the network layer will be invisible, and all will work as if they were sharing the same message bus. This way, changing how the network layer work will be quite easy, if needed.

This bus architecture will make it super easy to add new modules. For instance, I'll be able to add a game recorder module in the server just by making it listens to some game event from the server message bus. Or a security module to handle authentication, ...

On the client side, the core layer is responsible of the functionnalities and the 3D. That why user inputs (Mouse and Keyboard) are forwarded to this layer to manage the 3D. All the GUI other than the 3D view are managed by the GUI layer. Apart from raw user inputs for the 3D view, all communications between the gui and the core will use the client message bus, making it once more super easy to change the GUI.

The dice manager module appears on both side (server and client) because it is needed locally when playing offline, and on the server when in a multiplayer game. The local version will just be shutdown as soon as the player connect to server.

As for the network protocol I'll use, I'm still reading right and left to make a decision. There definitively are good websocket java libraries out there.

So for now, HexScape is undergoing heavy structural changes to migrate to this new architecture. I truly believe it will ultimately help deliver HexScape faster AND make it easier to evolve. I'll let you know how it goes.

[Xorlof]

Sounds good Lyrgard. As I said, do whatever works best for you. I'm just out here speaking from the peanut gallery (a phrase which probably doesn't translate well). You can always change it later if need be.

I don't know if you planned to support server-less, peer-to-peer network games. If so, a while ago I devised a method for ensuring no peer cheats on die rolls. Your mention of both local and server dice managers made me think of it again. I'll type it up if it is of use for to you, but if not doing peer-to-peer network games, then I can't see any reason for including the complication to your code.

[Lyrgard]

Originally Posted by Xorlof

Sounds good Lyrgard. As I said, do whatever works best for you. I'm just out here speaking from the peanut gallery (a phrase which probably doesn't translate well). You can always change it later if need be.

I don't know if you planned to support server-less, peer-to-peer network games. If so, a while ago I devised a method for ensuring no peer cheats on die rolls. Your mention of both local and server dice managers made me think of it again. I'll type it up if it is of use for to you, but if not doing peer-to-peer network games, then I can't see any reason for including the complication to your code.

For now I'll stay with server/client network, as it allow some simplicity for the user to connect without having to worry to much about port and firewall. Also, with the server software available, anyone will be able to host a server. So I see no need of a peer to peer network (well, I wanted one at first, out of geekiness I guess, but well, I'll better deliver something that work more easilly )

I researched the same subject you're speacking of, and found a solution based on :
1) Each player generate a private number, hash it, and send the hash to the others players.
2) When all hashes are received, each player send its number. The hash prevent a player to change its number after seeing the others numbers. All the numbers are appended in the same order (using player id to sort, for instance) and hashed.
3) This common hash is used to generate the same dice result on every client.

Was your solution something like that ?

And you're right, "speaking from the peanut gallery" doesn't translate well, and its the first time I encounter this expression. Thanks to you and google, I'll sleep more erudit that night