Mineth Studios

I recently made the switch from BlitzMax to C++, so I’m currently still working on porting all of the old code over to C++. First is the map format which I’m working on, along with map editor. I’ve been playing around with Win32 API programming for the map editor, and it’s coming together quite nicely.

Once I’ve implemented the map engine itself I can start building on the editor, along with some additional features for it I came up with in the meantime. These are mostly performance-based issues. Having better and faster access to pixel-manipulations on sprites/images nowadays (one of the main reasons for switching to C++) opens up a lot of opportunities. Think about heat background distortion, real-time palette shifting (like colored suits, heat glows on Samus’ suit and on the environment (tiles), things like that), but also real-time buffering the whole level into chunks (images consisting of 64×64 tiles) and drawing those, instead of drawing each tile individually This was already made in BlitzMax, albeit in a hacky and slow way.

I’ve also plans to look at OpenGL rendering later, to see if I can tweak performance any further. But alas, there are more important things to do first, like the map engine and network multiplay (which will be my top priority after I got the map engine implemented once again). Also a note, I’m currently developing the code so that it can be easily ported for different platforms later (wrapping native and library calls in my own functions). This means that I can branch the client to SDL later and theoretically compile it for the OpenPandora and much, much other platforms and OSes which SDL supports.

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.