Multitroid Archive

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.

Regarding Multitroid, I’ve started to dedicate more time to it’s development. The damn thing labeled as ‘in development’ for over two years now and we still don’t have a lot to show at the moment (although most going on atm is technical stuff, networking and such). In case you wonder, I do plan to keep developing it and not ditch the project all together.

I can understand some of you think I’m lazy or won’t finish the project, seeing the lengthy development time, but do remember two things; First of all, this is a spare time project. I work on weekdays and usually have also other interests rather than also coding in evenings and weekends. Second, the core goal of this project is for me to learn, not the end result itself (although I’d very much love to finish and play it, don’t get me wrong). I know people will hate me for saying this, but it’s mostly a learning process for me. To get better insights and understandings how games (technically) work and how to make them. The past two years, I learned a great deal about all sorts of stuff I could/will incorporate in Multitroid development and future game development. New techniques and stuff. (This is the main reason why I rewrote the whole Multitroid engine from scratch several times.)

However, that doesn’t mean I haven’t made any progress the past two years whatsoever! Being mostly a remake of an existing game (Super Metroid, fyi), a lot of time and effort went into obtaining it’s resources (sprites and the like) and more importantly: documenting existing gameplay mechanics in order to achieve being a close replica to the original game itself. Luckily, unlike it’s predecessor Metroid Tournament, things haven’t gone lost over several PC crashes and reinstalls in the mean time. That means I could continue go forward with development, albeit rather slowly.

Nevertheless, as we reach a stage soon where I can incorporate actual visual things in the game and get closer to alpha, I will show more and more media about the game. So expect more videos and screenshots as the game reaches completion. After a few more video’s showing the physics engine, it’ll be mostly multiplayer gameplay with hopefully more and more features. And maybe a video showing the level editor, too!

Also a quick note, I also plan to share a bit more technical development information over time, so you guys can get a rough idea what part I’m working on at the moment and how I’m doing it.