Mediaeval Play by eMail (Beta)

[Mario F.]

Hello everyone,

I'm releasing a beta/alpha/before-the-verb version of the client software for Mediaeval, a Play by Email strategy game set in a fantasy world.

I won't enter into details about it so this doesn't become one big post. However, Mediaeval was something I was developing in between MURK (see signature) boredom cycles. It just happens that it slowly grew on me and I've started working on it more and more as time passed. Partial blame goes to the wxWidgets library. I really do have lots of fun working with it.

You will find in this post some screenshots plus info on known bugs, leaks and a snippet of my current TODO list dealing with what you are seeing. The executable can also become available on request or if you remind me of some place I can upload it to.

Application typical Main Window with a selected hexagon.
The selected hexagon is built from a byte array with alpha channel support. Something like XPM on steroids. Quiet a cool technique. See: http://www.wxwidgets.org/wiki/index....ing_PNG_Images

Map Window detail with cursor over hexagon.
The map is built on the fly from the database (see Map Legend). Currently the database doesn't hold any info other than terrain type. I'm also planning the code for country border drawing (which is not an easy task despite apparencies). Everything else however is done and the elements you can see at the center of the map, although with their locations being hard coded, are already being drawn with the map elements drawing routines.

MiniMap detail
The small white frame is calculated dynamically on map window size and scrolling operations. The MiniMap implements all of the expected operations on a control like this, except for frame drag which will be there when I get to reduce the minimap flicker.

Map Legend
Map elements are fast to draw; Hexagons are polygons, rivers and roads are splines, borders will be lines and settlements, flag and forces are tiny XPMs. These last are built from static data and colors are set at runtime so that just one byte array is needed (e.g. there's only one army byte array that can be used to draw all 4 army types on all terrain types, except sea of course). This also allows me to draw without transparency support, which makes the whole thing much faster.

KNOWN BUGS:
. The map coordinate panels don't update on first scroll event. Only subsequent events update it, which results in the coordinates not being in sync with map scroll events (and only map scroll events). I know why this happens and it can be fixed. However it's an annoying fix that forces me to change the map window from a wxScrolledWindow object to a wxWindow object with scrollbars. It's on the bottom of the current todo list.

To refresh the coordinate panels and display the right coordinates, just move the mouse pointer inside the map.

LEAKS:
. 78k, as reported by Visual C++ 2005 Express, originating from a singleton object. That is, you can expect a 78k leak per run and no more than that, no matter what you do or how long the app stays on. I've started a thread on this issue on these forums, but unfortunately I allowed it to die. I apologize sincerely to all that replied; It's just been hard these days to be online. I shall reintroduce this issue later. For now I'll endure it.


TODO:
. Everything?

. There's yet some optimizations possible to map drawing. Clipping regions is one and I do need to study about this technique. Another is, naturally, my own code which can probably be improved. If I am going to worry with it or not (particularly reviewing my own code), will depend on general feedback on current map performance.

. The MiniMap flicker is awful and needs to be fixed. This is actually an excellent oportunity to study about those clipping techniques.

. Wait for the next wxWidgets stable release to replace wxNotebook for wxAuiNotebook in the main frame. Not using wxAuiNotebook yet because it leaks on AddPage(). Thankfully it is already fixed on the CVS. wxAuiNotebook has the type of functionality I want to offer users; individual tab close buttons, tab reorder and tabs scroll buttons.

. Users will be able to create and save their own colour schemas for all map elements.

. Will eventually need to ask for help with all the legal mumbo jumbo. The nature of a PBeM game makes it hard for code to be available as Open Source since players can then know all the little secrets of the game. However I would like for at least the client application to be available as open source until I figure out a way to make the server application available without giving away the game secrets that must remain forever away from the players... Anyways, The idea is that anyone can change and do whatever to the code, they however must retain the original authors names, or something like that.

[Sang-drax]

How many emails would it take to complete a game? That is a big map.

[indigo0086]

You've been busy.

Maybe rather than using e-mail you can make a kind of interruptible mailbox client/server dealy.

[VirtualAce]

Looks very good. And what a huge map.

And BTW it is Medieval not Mediaeval.

The MiniMap flicker is awful and needs to be fixed. This is actually an excellent oportunity to study about those clipping techniques.

I don't know anything about wxWidgets but using pure Windows API you would create a memory DC and a screen DC. Draw to the memory DC and when done drawing blit the memory DC to the screen DC.

As for clipping regions you can use the Win32 API equivalent of InvalidateRect() if you do not wish to redraw the entire map every time a movement is made. You just Invalidate a small rect area around the hexagon or hexagons that you need to update. Then when your paint or draw function is called it will only update those invalidated rects. I ran into this with my tile editor quite often and this solution helped a lot.

[Mario F.]

Thanks Bubba, that's exactly what I've been reading about this past weekend. Minimap flicker has been reduced to... 0

> Looks very good. And what a huge map.

14060 Hexagons to be precise. Map actual data is managed by said singleton. It's just a 78k heap object. Since the screen drawing is only based on the current client area size, the application keeps a low memory footprint.

> And BTW it is Medieval not Mediaeval.

Actually both forms are acceptable being that the latter is old-style, from all that I know. Regardless the name is actually sort of a code-name since this won't be the final one.

> How many emails would it take to complete a game? That is a big map.

Each game can house up to 150 players each playing their own country. Country management is complex involving economy, society, military and diplomacy. Countries can form alliances and become part of existing (or form new ones) kingdoms and empires... all in all, considering the number of players, a game is a never ending experience since no one can claim victory over the whole continent.

However games this nature may tend to stale. World politics may become to entrenched. Players can sign to a new game or I can expand the map to accommodate new players.

[Perspective]

> And BTW it is Medieval not Mediaeval.

Actually both forms are acceptable being that the latter is old-style, from all that I know. Regardless the name is actually sort of a code-name since this won't be the final one.

How clever that your evaluation media is named Mediaeval

[mike_g]

Hey that looks cool I think one of the old Civilization games was playable via email, tho I never tried it. I was thinking about having a go at making a strategy game too, something simple and turn based like advance wars. Anyway congrats on getting it (mostly) finished. Must have been quite a bit of work.

[Mario F.]

> How clever that your evaluation media is named Mediaeval

Gosh! I wished I had seen that one.

> Anyway congrats on getting it (mostly) finished. Must have been quite a bit of work.

"mostly" is definitely not the word. I don't even consider I began. This is just the client software, the one players are going to use to read their reports, issue orders, and send them. And none of that is done yet. Just the core code for map drawing and general application behavior.

There's the server software. This will be responsible for receiving player orders, process them and update the world. This is going to be a major part of the game development.

And then there's the DLL with the game engine. This will be used by the server software only. But I need it to be separate from the rest of the code because I plan to release both server and client application as Open Source and yet no allow players to have access to all the secrets of the game. i.e. players know the game rules but they don't know all the details of the rules; things like to-hit percentages, exactly how the world, regional and country economy works, etc...

No. It's not mostly finished. It is mostly started

> I think one of the old Civilization games was playable via email, tho I never tried it.

It is possible. During the early 90s computer strategy games were commonly played also by email. The whole PBeM thing was still very much alive. Today it has died a little. Mostly because the serious PBeMs are asking for money which is not something many people are willing to do for "low-tech" games.

I plan to offer better for no money at all. Wish me luck.