header image

EA – challenge everything

After reading an Eurogamer article about supposed Origin account hijacks I went to the account management just to check things. I doubt it’s anything substantial but it doesn’t hurt to have a look.

Everything was in order. I went to check my purchase history randomly. The site asked me to confirm my password and then…

What the hell? Why yes, that’s my account password in plain text. It’s HTTPS so sniffing it is not that trivial (unless you’re subject to a SSL proxy), but if their web developers think that passing plain text passwords in URLs is a good idea in any scenario, I seriously doubt their infrastructure is secure.

I was even more curious now. Let’s change my password to something weird, with lots of special characters. `!@#$%^&*()_-aA1 to be exact.

Clicking Submit and…

Riiight. Length? 16 characters. Lowercase letter? Check. Uppercase letter? Check. Number? Check. What’s the problem then?

After some investigation I identified that the following characters are not allowed in passwords: ?”\|/,.
This of course is not mentioned anywhere on the page. Good job. But wait, there’s more. You can’t use passwords that are exactly 16 characters long. aaaaaaaaaaaaaaA1 will be rejected. So they can’t write basic comparisons as well.

Challenge everything indeed.

GWEN.Net discussion group

I finally got around to creating a discussion group for GWEN.Net. You can find it here.

Also two people joined the project as contributors:

  • Robin Haudenhuyse aka Snorkel will maintain the OpenTK renderer.
  • Patrick Cosyns will contribute his fixes and possibly improvements to the library.

Project Eternity

If you haven’t heard about this chances are that you don’t have a computer/Internet access or don’t play games. Even if that’s true, read on.

Project Eternity is an isometric, party-based computer RPG set in a new fantasy world developed by Obsidian Entertainment.

Obsidian Entertainment and our legendary game designers Chris Avellone, Tim Cain, and Josh Sawyer are excited to bring you a new role-playing game for the PC. Project Eternity (working title) pays homage to the great Infinity Engine games of years past: Baldur’s Gate, Icewind Dale, and Planescape: Torment.

Project Eternity aims to recapture the magic, imagination, depth, and nostalgia of classic RPG’s that we enjoyed making – and playing. At Obsidian, we have the people responsible for many of those classic games and we want to bring those games back… and that’s why we’re here – we need your help to make it a reality!

More details here. Make sure to read the updates, the developers explain a lot of the design ideas there.

Seriously, if you liked old-school CRPGs, give these men some money. The project got funded in just a day, but the more they gather the better it will be. The campaign ends in a week from now.

And if you were living under a rock and don’t know what Obsidian is or who these people are, you should feel bad. Then play Planescape: Torment. Then read this actual design document.

Continue reading ‘Project Eternity’

GWEN.Net updated

Updated the SFML renderer to work with newest SFML version (Laurent finally removed the default font).


I really need to work on this more, there are still few annoying bugs with text rendering. Reworking the event system is also long overdue (as is bringing the port up-to-date with original GWEN). So if you’re reading this and would like to contribute (and have more time than I nowadays), feel free to do so!

For the Empire!

To the east: the sea. To the north: trees and swamp. To the south: forested bog.
Beware the Crustborer! It wasn’t a good idea AT ALL.
We all believed that anything that glowed so prettily must be harmless…
The Heliograph tower collapsed… communications lost…
We pickled the creatures for study back at the Capitol, but something terrible happened on the supply zeppelin home…
The Capitol is rolled in darkness. The Panopticon is lost.

Clockwork Empires (Copyright © Gaslamp Games Inc.)

Clockwork Empires [Copyright © Gaslamp Games Inc.]


May the Holy Cog have mercy on the gear of my soul.

Remote debugging trap

I’ve spent about an hour today trying to make remote debugging work with my test VM. For it to really work you need to have the same user on both machines, which can be problematic. My test machine contained a server process that needs to run under specific account, so I couldn’t change that. What I did was creating local user on a target (VM) machine identical as the one on the dev machine (with the same password). Then I logged on to VM as the new user, started msvsmon on the VM (as the newly created user by default), and started the server process as the other required user. This should work, just make sure the new account has administrative and debug privileges. Alas, when trying to attach to my program the following error appeared:

Microsoft Visual Studio
Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'admin@vm'.
The Visual Studio Remote Debugger on the target computer cannot connect back to this computer.
Authentication failed. Please see Help for assistance.
OK   Help   

On the target machine’s msvsmon I saw one line saying that a connection was successful. Well, at least successful one way. But apparently the VM couldn’t authenticate back for some reason. I tried accessing some host share from the VM – same result, authentication failed. I made sure I was using the right account and password. And then it struck me.

There is a setting in the Local Security Policy that dictates how LAN Manager authentication works. My dev machine runs Windows 7, while the VM was Server 2003. That particular option (Local Policies – Security Options – Network security: LAN Manager authentication level) was set to “Send NTLMv2 response only. Refuse LM & NTLM” on my dev machine. It basically means that only machines using the new protocol can authenticate correctly. Server 2003 sends v1 requests so it failed to authenticate because those were refused. I changed it to “Send NTLMv2 response only. Refuse LM” and behold, I could now debug to my heart’s content.

I must have changed that setting some time ago and forgot about it. It actually warns you about potential compatibility problems, so be careful if you fiddle with it.


Turned 0x21 today. Somehow looks better in this form 😉

Also I finally ‘completed’ The Binding of Isaac. I’m not sure what exactly is so compelling in the game for me, but it’s brilliant.

Steam sale in a nutshell

Sorry, you can’t buy this. Go to the piratebay or something.

Class markers: attributes, interfaces or something else?

You probably had to make such decision in the past. We have a number of classes, probably inheriting from some base. We need to mark some of them in a way that we can process their objects differently than the rest. To make a concrete example: entity components in Heimdall. Components are basic data containers for entities. Markers come into the picture when serializing entities: some components should be sent from server to the client (name, location, etc), while others contain internal object state only needed by the server. We need a way to mark “client-side” ones so that the entity serializer can properly filter data. What options are there?

  1. Attributes
        [AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
        sealed class MyAttribute1 : Attribute
            public MyAttribute1()
        class Class1
        var obj = new Class1();
        if (obj.GetType().IsDefined(typeof(MyAttribute1), false))

    The cleanest way, preferred by the .NET Framework Design Guidelines. Unfortunately testing if an object’s class has a particular attribute applied is clunky and involves reflection.

  2. Marker interfaces
        interface Interface1
        class Class1 : Interface1
        var obj = new Class1();
        if (obj is Interface1)

    Even cleaner than attributes in my opinion, easy testing, no reflection involved – what’s not to like? Well, the above guideline expressly tells us to avoid empty interfaces. It makes sense, interfaces are behavioral contracts, so an empty one isn’t very logical if you think about it. Still many people use them just for their syntactic simplicity.

  3. Virtual properties
        class Class0
            public virtual int type { get { return 0; } }
        class Class1 : Class0
            public override int type { get { return 1; } }
        Class0 obj = new Class1();
        if (obj.type == 1)

    Pretty simpe as well, easy testing and little overhead. Not very popular technique for the job though.

  4. Public fields
        class Class0
            public int type = 0;
        class Class1 : Class0
            public Class1()
                type = 1;
        Class0 obj = new Class1();
        if (obj.type == 1)

    We can expect this to be the fastest solution: no virtual calls, no overhead at all. Of course no sane designer would recommend public fields… 😉

So what did I choose as my solution? Component serialization happens quite often so speed is the primary requirement. Memory usage is also a big concern – when the game world is populated there will be thousands components present in the entity system engine. Well, I’m sure you know what happens next… Yeah, that’s right – let’s benchmark stuff!

Class markers microbenchmark code Show

And the results:

Instantiating 1000000 objects... 00:00:00
Interfaces:     00:00:00.0299656, 333887 333275 332838
Classes:        00:00:00.0183586, 333887 333275 332838
Fields:         00:00:00.0134517, 333887 333275 332838
Properties:     00:00:00.0187774, 333887 333275 332838
Attributes:     00:00:03.3878258, 333887 333275 332838

Not that surprising really.

  • Fields are fastest. Using them would increase memory footprint though, as each and every component instance would contain a marker field.
  • Properties are as fast as testing for object’s class directly and incur no memory overhead.
  • Testing interfaces is slower than classes/properties. Still not that much slower.
  • As expected, testing for attributes is dead slow. Over 100x slower than interfaces in fact. That makes them absolutely useless in any kind of performance-sensitive code despite design guidelines. Sorry. Of course you can cache the result somehow or generate some clever IL code to test in runtime… but that’s a bit overkill for such simple task.

So the winner is… Properties! At least in my case. Just remember, if speed is not your primary concern, attributes are perfectly fine.

Back in the saddle

I’ve been slacking a lot lately. Let’s blame Diablo 3, The Binding of Isaac, work and summer. I hate summer. It’s too hot for anything when I’m not in the office with nice air conditioning. Makes staying late so tempting…

Anyway, I’m back coding Heimdall. Right now the focus is on finishing the first prototype. What features are needed?

  • Basic account functionality: creating accounts, account persistence [done]
  • Client-gateway authentication and basic communication: logging in, selecting realm, creating characters [done]
  • Basic game server functionality: entity system with persistence, communication with gateway (player authentication, character info), client communication (receiving input, basic movement simulation, sending world updates) [mostly done, working on movement and updates]
  • Basic client-client interaction: clients should be able to move and see each other [to-do]
  • Graphical client prototype: basic UI, placeholder world rendering (just to see characters) [UI done, rendering to-do]

As you can see, most of the back-end infrastructure is in at least somewhat working state. I’m implementing movement now – it’s the first real Entity System in the engine so a huge step forward. Also movement is kind of needed for anything to work 😉

At first I was thinking to implement “discrete” movement (like in UO for example). My world is tile-based, so why not only allow players to move by specified amount in compass directions? Well, it’s tempting and quite easy to implement, but I feel I can do better. Discrete movement has some big disadvantages:

  • Limited player freedom, of course. I’d like to allow free movement, even if it makes collision detection harder.
  • Speed hacking! With discrete steps the only real metric of ‘speed’ is rate of movement commands, and this can be easily exploited (as in UO ;)) to gain speed advantage. You could of course implement some countermeasures and rate limits, but that’s not so easy (and costs time).
  • It’s hard to implement variable character speed (see above).

So what I’m doing? Well, my approach is to have more action-gamey movement. Each movable entity has a Location and Velocity components (basically 3d vectors). Game server will simulate basic kinematics, which is not hard with (mostly) constant speed values. Of course clients need to be kept in sync, which is not always easy, but with mostly 2D movement it should be OK. Because of network and processing latency I probably can’t afford to have clients as just “dumb terminals” displaying game world, they need to perform limited simulation themselves.

Basic information flow is like this:

  • Client logs in and selects character (character enters game world).
  • Server assigns character entity to the client connection.
  • Server constructs a “world state update” packet containing initial information about all entities in client’s “interaction radius” (I call it “client frustum”, frustum is mostly used in context of client rendering but for me it means “all objects that client should know about”). This initial packet contains list of entities with components needed by the client (like names, locations, velocities etc, no internal potentially sensitive server state is sent of course).
  • Client deserializes the update packet and initializes its own entity system with the received data. That’s the base for client-side simulation and rendering.
  • Player initiates character movement in a specific direction. GUI sends the ‘move’ message to the “world” object, and it in turn constructs a “movement request” packet containing direction and velocity. This requires that client knows about “potential speed” of its character, but is needed if we don’t want to wait for server acknowledgment before locally starting to move.
  • Client applies the velocity change to the character and uses the new state for rendering and collision detection.
  • Server receives the movement packet and validates it. If everything is OK it applies velocity changes to its entity state. No acknowledgement is immediately sent.
  • Server keeps track of each client’s frustum. If a new entity enters this region or a “visible state change” occurs for some entity, another “state update” packet is created and sent, but this time it’s a “delta” packet (containing only components that changed since last time). Because client frustum is slightly larger than rendering area it allows for smoother appearance of new objects that just “arrived”.
  • Client applies any state updates to its own entity system.
  • Collision detection is both client- and server-side. Server sends update messages on collision, because entity’s velocity changes. If client and server world data match, they both detect collision at the same time and will remain in sync (of course lag compensation, client-side interpolation etc is still needed, but that’s another topic). If the client has invalid data (like hacked world files) it will desync, but server will still have correct state.

Once the movement and world updates work properly it will be time to implement simple rendering and the prototype will be complete.