March 10, 2013 • No Comments
So inXile, the company behind a pretty successful Wasteland 2 kickstarter, a totally oldschool postapocalyptic cRPG, has launched a second kickstarter. I think you can guess which one. A new Torment game. I would have never thought something like that happens, not even a year ago, but I guess things like amazing success of Project Eternity has proven that people like their good old cRPGs.
We’re talking about Torment here though. The original is the best game for me, period. It’s widely regarded as the best cRPG ever. If you haven’t played it, do that. Now. If you have, read the original vision statement. I have mixed feelings for such an undertaking. Of course the original wasn’t perfect: the combat was mostly awful, you needed certain stats to get “the best game experience” and other minor things. But what if the new Torment won’t be on par with the original? Just the name itself holds so much weight for so many people. Now, the new Torment won’t be set in Planescape because of licensing issues. Numenera will be the new setting and it does sound like a good fit for a Torment’s spiritual successor. Dev team has a healthy dose of people who worked on the original. While Chris Avellone isn’t directly involved, he gave the project his thumbs up and I wouldn’t rule out his possible help later as a stretch goal. Colin McComb is the creative lead, he worked closely with Avellone on the original and contributed a lot to the core AD&D rulebooks. I’m cautiously optimistic.
The kickstarter itself is an astounding success already. They got their target amount in just a few hours. I believe it has also broken the record of fastest kickstarter to get one million dollars. Will it beat Project Eternity? I think there’s a fair chance. Now decide for yourself if you want to give them money (hint: you probably do) and go do that.
Posted by omeg in gaming
November 14, 2012 • No Comments
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.
Posted by omeg in information security, rant, usability, web, wtf
November 14, 2012 • No Comments
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.
Posted by omeg in C#, code, GUI, gwen.net
October 9, 2012 • No Comments
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.
Lastly, some character concepts:



Posted by omeg in gaming
September 13, 2012 • 2 Comments
Updated the SFML renderer to work with newest SFML version (Laurent finally removed the default font).
http://code.google.com/p/gwen-dotnet/
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!
Posted by omeg in C#, code, GUI, gwen.net
August 27, 2012 • No Comments
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.]
THE DEER SPEAKS. YOU STILL DARE NOT LISTEN.
May the Holy Cog have mercy on the gear of my soul.
Posted by omeg in gaming
August 2, 2012 • No Comments
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.
Posted by omeg in code, troubleshooting
July 31, 2012 • 1 Comment
Turned 0×21 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.

Posted by omeg in gaming, personal
July 17, 2012 • 2 Comments

Sorry, you can’t buy this. Go to the piratebay or something.
Posted by omeg in gaming, rant
July 10, 2012 • 1 Comment
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?
- Attributes
[AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
sealed class MyAttribute1 : Attribute
{
public MyAttribute1()
{
}
}
[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.
- 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.
- 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.
- 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 |
SelectShow> |
[AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
sealed class MyAttribute1 : Attribute
{
public MyAttribute1()
{
}
}
[AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
sealed class MyAttribute2 : Attribute
{
public MyAttribute2()
{
}
}
[AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
sealed class MyAttribute3 : Attribute
{
public MyAttribute3()
{
}
}
interface Interface1
{
}
interface Interface2
{
}
interface Interface3
{
}
class Class0
{
public int type = 0;
public virtual int ptype { get { return 0; } }
}
[MyAttribute1]
class Class1 : Class0, Interface1
{
public override int ptype { get { return 1; } }
public Class1()
{
type = 1;
}
}
[MyAttribute2]
class Class2 : Class0, Interface2
{
public override int ptype { get { return 2; } }
public Class2()
{
type = 2;
}
}
[MyAttribute3]
class Class3 : Class0, Interface3
{
public override int ptype { get { return 3; } }
public Class3()
{
type = 3;
}
}
/// <summary>
/// Class marker performance test.
/// </summary>
static partial class Playground
{
public static void MarkerTest()
{
// interface/attribute test
const long numObjects = 1000000L;
Class0[] objs = new Class0[numObjects];
Stopwatch sw = new Stopwatch();
// instantiate some objects
Console.Write("Instantiating {0} objects... ", numObjects);
for (long i = 0; i < numObjects; i++)
{
switch (random.Next(3))
{
case 0:
objs[i] = new Class1();
break;
case 1:
objs[i] = new Class2();
break;
case 2:
objs[i] = new Class3();
break;
}
}
sw.Stop();
Console.WriteLine("{0}", sw.Elapsed);
// interface testing
long c1 = 0, c2 = 0, c3 = 0;
sw.Restart();
for (long i = 0; i < numObjects; i++)
{
if (objs[i] is Interface1)
c1++;
else if (objs[i] is Interface2)
c2++;
else if (objs[i] is Interface3)
c3++;
}
sw.Stop();
Console.WriteLine("Interfaces:\t{0}, {1} {2} {3}", sw.Elapsed, c1, c2, c3);
// class testing
c1 = c2 = c3 = 0;
sw.Restart();
for (long i = 0; i < numObjects; i++)
{
if (objs[i] is Class1)
c1++;
else if (objs[i] is Class2)
c2++;
else if (objs[i] is Class3)
c3++;
}
sw.Stop();
Console.WriteLine("Classes:\t{0}, {1} {2} {3}", sw.Elapsed, c1, c2, c3);
// field testing
c1 = c2 = c3 = 0;
sw.Restart();
for (long i = 0; i < numObjects; i++)
{
if (objs[i].type == 1)
c1++;
else if (objs[i].type == 2)
c2++;
else if (objs[i].type == 3)
c3++;
}
sw.Stop();
Console.WriteLine("Fields: \t{0}, {1} {2} {3}", sw.Elapsed, c1, c2, c3);
// property testing
c1 = c2 = c3 = 0;
sw.Restart();
for (long i = 0; i < numObjects; i++)
{
if (objs[i].ptype == 1)
c1++;
else if (objs[i].ptype == 2)
c2++;
else if (objs[i].ptype == 3)
c3++;
}
sw.Stop();
Console.WriteLine("Properties:\t{0}, {1} {2} {3}", sw.Elapsed, c1, c2, c3);
// attribute testing
c1 = c2 = c3 = 0;
sw.Restart();
for (long i = 0; i < numObjects; i++)
{
if (objs[i].GetType().IsDefined(typeof(MyAttribute1), false))
c1++;
else if (objs[i].GetType().IsDefined(typeof(MyAttribute2), false))
c2++;
else if (objs[i].GetType().IsDefined(typeof(MyAttribute3), false))
c3++;
}
sw.Stop();
Console.WriteLine("Attributes:\t{0}, {1} {2} {3}", sw.Elapsed, c1, c2, c3);
}
}
|
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.
Posted by omeg in C#, code, Heimdall, performance