Monthly Archives: January 2014

Cleaning the engine

January 29, 2014 | Filed under: programming

It’s tricky to get the timing right. Some people do nothing but update their engine. they have re-factored it so much and re-implemented everything so often that it is a true work of art, worthy of actually putting in books on how to code. These people never ship a game. The other extreme is people who are still using assembly language routines for loading in ini files because they wrote them in 1996. These people have tech support issues galore, and are probably still using Directx3.

In between there somewhere is common sense, if you *are* going to write your own engine and not use someone else’s. I think, from chatting to devs and surfing a lot on developer forums, that people tend to want to redesign their engine after every game. They consider that quite a major compromise compared to their real hidden urge to do it every morning. The thing is, if you are doing that you aren’t really writing an engine, you are just writing a new game from scratch all the time.

lexus

I tend to go with a system of marginal improvement. I still have some code from about 5 games ago (non critical stuff like ini file loading, text handling, game timers and some math stuff), but a lot of it is fresher. The graphics stuff, as you would imagine gets a major refresh more often, and my engine only contains some pretty ‘raw’ directx wrapper and vertex buffer / text engine stuff. The actual ‘scene management’ for my games is done in the game itself.

Despite the occasional between-project update and maintenance, occasionally you have to step in and clean things up. The last big update was when I went from Directx7 (Democracy 2, Kudos games…) to Directx9 (GSB,GTB,Democracy 3). This time I’m updating almost everything BUT the directx version.

I recently bought Visual Studio 2013, mostly for the concurrency profiler to enable me to experiment with multi-threading more. This was a good opportunity to take a look at some of the flakier things in my engine. I have a lot of warnings in there for data-conversion and other sloppiness. I also have code I never use (I’m culling it), and the worst and most embarrassing thing is that I can’t decide if I like char* or std::string. I Figure that std::string must be at least a bit better, more robust and safe than char*, so I’m trying to purge all that char* from the engine, and eventually, the game. I’m also planning on re-wiring stuff so that the main game code doesn’t have any FILE* or other old fashioned stuff, but uses my file wrapper more.

Why? Mostly because I can see me heading towards cross platform eventually. maybe not with the next game, but baby-steps and all that… Plus it makes life easier if getting my engine ported is a less messy business. I’m sure after a few days of sorting out this stuff I’ll be climbing the walls and wanting to code some explosions again…

redshirt_Logo_transparent_500width

Attention crewmembers! Did you know you can have a life IN SPACE for 50% off the normal cost? It’s true! Our wonderful space comedy life-sim game Redshirt is now 50% off, whether you grab it from the redshirt site or from steam!. If you are on the fence, you might want to know that redshirt is the only game to feature bisexual aliens that stalk you through social media. If that doesn’t guarantee a sale, I don’t know what will, but here is a reminder of the megalodon nine recruitment video for you:

And of course you might want to check out the redshirt website before buying. Now either grab it from this buy link here, or from steam at this linky here.

Enjoy! And don’t forget to tell everyone about the sale using social media, which is of course amazingly ‘meta’ given the game…

Positech has been around a long time. I am OLD. I remember before VHS. I remember before CD’s. i was there when Sauron was defeated and men were shown to be weak. As a result, I’ve had a website for a long time, and probably due to mere inertia, it’s got a lot of SEO from inbound links, and a lot of (my) games on it, and therefore, it acts as quite a good funnel for traffic and sales. I’ve also advertised a lot over the years and pointed at it, so that has boosted traffic too.

Lets look at some numbers.

In the last year, my direct sales have been $170,000. That actually surprises me. I thought it was less than that. Not bad for an indie website in these days of ‘everybody buys on steam’. If I look at web traffic I get these stats over the last 365 days:

2,700,000 unique visitors according to awstats

23,000,000 pages according to awstats.

site1

That seems pretty good to me. Maybe some of that is my games checking for updates? If I check google analytics, the site got 1.8 million visits. 417k were from organic search. That’s a decent figure. I’d love to know how it compares with other indies sites, and smaller portal/bundle sites. I should also state these figures ignore redshirts site and the gratuitous tank battles site, both of which have their own base domains.

What this has got me thinking is that in effect, I own a mini-portal. I’d wager indies get a fair few emails along the lines of ‘We are an exciting new game store and we would like to grab 30% of your revenue despite having virtually no traffic, if you agree to sell through us!’. I know I do, and I wonder if those sites have less traffic than me. I have signed deals in the past that have earned under $10k a year in sales through a channel, even under $5k. 5% of my direct sales is more than that. You can probably see where I’m going with this?

I have zero time and mental bandwidth, but I do muse over the idea of saying to indies who refuse to sell direct because ‘it’s too much hassle’ something along the lines of ‘I’ll do it for you, and take 15%’. This is just an idle thought, and I’d have to be very impressed with a game I’d add to my own site. But it is worth a thought.

I have been slowly investing in my site over the year. Check out the forums. They now support facebook, google and twitter as logins, and the individual forums have custom graphics. ooh!

 

I’m new to multithreading, and the visual studio concurrency visualiser. I have lovely multithreading code working. basically my main thread throws the Threadmanager a bunch of tasks. The threadmanager has a bunch of threads which all spin doing nothing until told to do a task. Once they finished their task, they set an IDLE flag, and the main threads WaitForAllTasks function then assigns them a new one. It works just fine…. but I notice an anomaly.

See below (Click to enlarge enormously)

bug

The highlighted connection shows thread 4828 sat on its fat ass waiting for the main thread, when it clearly idle and ready to do stuff. The things is, the main thread function is just this:

    bool bfinished = false;
    while(!bfinished)
    {
        bfinished = true;
        for(int t = 0; t < MAX_THREADS; t++)
        {
            if(CurrentTasks[t] == IDLE_TASK)
            {
                //maybe get a queued item
                if(!QueuedTasks.empty())
                {
                    THREAD_TASK next_task = QueuedTasks.front();
                    QueuedTasks.pop_front();
                    CurrentTasks[t] = next_task;
                    SetEvent(StartEvent[t]);
                }
            }
            else
            {
                bfinished = false;
            }
        }
    }

Which basically does sod all. How can this take any time? Setting event sets an event which the worker threads function is calling WaitForSingleObject() on. Again…how can this take any time? Is there some polling delay in WaitForSingleObject? Is this the best I can hope for? It’s the same case for all those delays, it’s just this one is the largest. I’m new to this. Any ideas? :D

 

 

Elaborating on my last post. Valve have made it pretty clear they are heavily betting on Linux. Microsoft, you missed the ball. You didn’t get the hint. What action did you take to get valve back? Apparently not enough. Regardless… Linux will be big for gaming. It’s 2% of my sales right now. This is going to grow and grow fast.
This is no big deal to me, apart from the fact that Linux also means OpenGL. I currently have my own engine which uses DirectX. What should I do? Here are my options…

steambox1) Do nothing.
Just stick with it. 2%? Even if it goes up to 20% so what? My current system is me doing the directx version, then paying a contractor to handle the OSX & Linux ports by converting it all to OpenGL. This works fine so far. This option is easy, but it seems like I just go further down a dead end. I don’t want to be the last guy using DirectX.

2) Prepare my engine to be more cross-platform friendly
I could re-engineer my code so that it’s more modular and easier (re: cheaper, faster) to port to OSX/Linux. This way I still keep directx, but make things simpler for a future transition. This is appealing because it’s a hedge towards either direction, and frankly engines should be built like this anyway.

3) Learn OpenGL.
This is the hardest because it involves serious work. I know everyone will say ‘it’s really similar’, but being ‘familiar’ with OpenGL isn’t what I want. Being VERY sure I know the BEST way to use OpenGL for my purposes is what I need. I love optimizing. I love pushing to get as rich a 2D experience as the hardware allows. I don’t want to trade a really fast DirectX engine for a slow OpenGL one. This involves the most work, to do it right. There is huge opportunity cost for that time as a programmer. This is also by far the most future-proof.

4) Hire a full time Linux/OpenGL coder.
Not a sensible option for me. I couldn’t keep them busy, I still don’t learn anything, and this is effectively 1) but more expensive and with more admin. All it does is guarantee me availability, but at too high a price.

5) Switch to middleware.
An option for 95% of devs. I hate middleware in general, but I also do something very unusual. The engine for GSB 2 works in a very specific way. At it’s core, it is a heavily optimised, shader & post-processing based, lots of render-target flipping 2d engine that assumes a huge amount of 2D objects. I’m not aware of any engines designed specifically to do this except mine. Plus there are costs in terms of learning that new engine,  which represents investment in something I neither own or control. I don’t like this.

I’m thinking about this a lot. I’m currently favoring 2), Possibly 3). I have discounted 4) and 5). Doing 1) seems lazy. This is something I need to get right at some point this year.
Feel free to add your thoughts :D