Like I said, I will update this blog more often with technical and development details/status regarding Multitroid, so here goes:
Currently there are plans to build three standalone applications at the same time for Multitroid. These are:
The client (aka actual game), based on a SFML RenderWindow. This pretty much means cross-platform support, although Windows has most priority at the moment. Linux and Mac OS X ports will be compiled later.
A console-based dedicated server, incorporating the network functionality of SFML without the graphical stuff. Now, talking about servers, there are two types:
- Lobby-based. This means that everyone needs to gather in a lobby prior to the game so that everyone will start inside the game at the same time,
- Realtime. The server keeps running and cycling through levels at configured times, and people can join and leave during games as they want.
Most multiplayer games use either type. Take Unreal Tournament (PC) for example, the server just runs and people can join and leave as they like while the game is running. And now take the recently released Castlevania: Harmony of Despair (X-Box 360). People need to gather prior to the game until everyone is ready before the game can start. People can leave mid-game, though, but no players can join until that level is finished and they’re back in the lobby.
Quick note about Castlevania: Harmony of Despair: I recently bought this off XBLA, and I – being the Metroidvania nerd I am, greatly enjoyed it. It gave me some pretty cool ideas how to incorporate properly Co-op in Multitroid, although not the whole original Super Metroid storyline. I’ll post more about both Multitroid Co-op ideas and about how awesome Castlevania HD is, later.
My plans for Multitroid are to support both server types, since I believe each type has it’s advantages (and disadvantages). Mixing them would let users/hosters choose which type of game they want to play, although certain gametypes will likely support only one server type (Co-op being lobby-based only, for example), but this is subject to change. The client can still host either server type just fine with full functionality, but the dedicated server is an alternative for those who want to run a server while not playing themselves.
Finally, there’s the level editor. If you’ve read one of my previous posts, you might have noticed that I released a functional-yet-clunky version of the level editor over a year ago. This was done in BlitzMax back then, using non-intuitive keyboard keys for navigating screens overlapping, etc. As you can tell this was pretty much as mess, but it was required for me to make because I needed to test the tile engine I was working on. Without the ability to make maps, there was no way to test them, so I brew up the level editor back then and released it shortly after. It’s now unavailable for download, since a new one is being made. This is what I wanted to briefly talk about.
Most decent level and map editors use a intuitive GUI (Graphical User Interface, ‘menus n buttons n stuff’), so I started to look around in how I could add that to my level editor. After a few hours of messing around with failed to try to get wxWidgets to work, I think I’m doomed-eh, I mean tempted to finally go around and learn Win32 API programming, which means that the level editor will probably be Windows-only.
Although I might check out GTK+ and see what they have to offer later. In any case, SFML has native support to hook it’s renderwindow into Win32 static window views, so that’ll be a great help. Multi-platform support for the level editor isn’t as highly prioritized as the client and server are, so it might end up Windows-only.