Game Design, Programming and running a one-man games business…

Category: programming

Starting on the challenge stuff…

Posted on September 21, 2011

GTB is such a huge game that I seem to veer into certain areas of it for weeks at a time, then veer back into other bits of it and think “did I write all this code?”

One of the features from Gratuitous Space Battles that I was very happy with, was the online challenge system. It was very popular. About 226 trillion billion zillion challenge games have been played (roughly). Obviously I want a similar system incorporated into GTB, and naturally I want to fix the things that were not perfect, which I identify as:

  • The challenge browser was not as good as it could be. You couldn’t filter out played/downloaded challenges.
  • Any challenge that had content, be it DLC or a mod that you did not have, could crash the game, and not be pre-filtered
  • The emotional connection between you and the challenger was limited. (Rarely used messaging, and rating, but not leaving comments etc).

I plan to fix all of this, but the middle one is the current one of interest.

GSB had a binary .gsb format for a challenge, which basically packed in binary data for the fleets designs, deployments and orders, and a little bit of data about the challenge (custom settings etc) and that was it.

GTB will use a new .pak format I’ve written that will behave a lot like a zip file. (no compression yet, sadly). It will be a folder full of stuff for each battle, all the enemies unit designs, the deployment timings for their attacking units (or initial deployments of defending units), and all of the data from the scenario file, down to the location of every tree, crate, barrel, barbed wire etc…

That makes a GTB challenge file slightly larger than before, but I can live with that. They are under 100k. How many custom maps in games are under 100k now? It also means you could move a few trees or change the texture of a single tile, and upload an existing scenario trivially without any inconvenience.

Anyway…. The upshot of this new file format is that theoretically, if I write the code for it, the format could include custom sounds, graphics etc. That means you could do a mod for GTB which included different textures for the terrain, and custom units, issue it as a challenge, and EVERYONE could play it, because the required content gets downloaded with it.

Sadly, there is no way to prevent dupes there, so if you have a custom tank texture, and upload 10 challenges, someone downloading all 10 gets the texture 10 times, but I think that’s not so bad. Only a minority of players are likely to issue or play modded challenges anyway.

The main thing is, my pak file format pakker and unpakker all works fine, so it’s another step along the path to having online play working. Now I need to replicate a lot of the GSB functionality (and improve on it).

Edit: I swapped out my code to use some zip code instead , after finding a zip wrapper that was extremely lightweight.

Slipped back into graphics tartery…

Posted on August 24, 2011

Ok, so for a few days I was working on graphics stuff for GTB, rather than gameplay. A lot of this came about because I wanted some GUI in there for issuing movement orders to units, and that is mostly done now. It also looks pretty nice too. The idea is not that you will generally be issuing movement orders, because like most tower defence games, your troops attack on rails, but sometimes there is branching, and you might want to ensure a certain unit goes left, or right, so you can give them an override-path manually. My current thinking is that in the GSB style challenge battles, this just isn’t an option, so it retains it’s hands-off style for that game mode.

A bit of profiling through a lot of doubt over my claimed 400% increase, and it looks like it’s a lot lower than that :( I blame Visual studio often not realising it needs to overwrite an exe when you change configuration. pesky Visual Studio…

However, my profiling binge did point out something scary (and slowdown-inducing) which was that in some average night-time battles, I was calling SetRenderTarget about 45-50 times a frame. Ouch! This was mostly stuff like searchlights and laser beams, that render to the screen, then also get rendered to a light map for later composition and niceness. They were handling this individually, rather than being batched as they are now, meaning less that 18 SetRenderTargets per frame, and several more of those will get optimised away soon. Many of them are essential, for selection UI, lightmaps, shockwave distortion and fog of war.

The ups-hot of this is that I can play fullscreen, release-build 1920 x 1200 res with all graphics options on, at night-time, with toggling night vision on and off, explosions, lasers, searchlights, unit selection UI and range GUI, path selection-GUI and the windowed UI for minimaps and unit selection…. All at a consistent unwavering 60 FPS, with fraps and windows media player running in the background.

OH YES.

Like GSB, this will be a game that really sells itself through videos of gameplay.
Also today I might peak at 9.5kwh of power from my little garden power-station. When that pesky tree gets trimmed, it should climb even higher. Oh yeah.

400% speedup in a pesky transform thing

Posted on August 22, 2011

This code was slow*:

    D3DTLVERTEX* pvert = LocalMem;
    for(int c = 0; c < CopiedIn; c++)
    {
        pvert[c].dvSX -= TransformX;
        pvert[c].dvSY -= TransformY;
        pvert[c].dvSX *= TransformZoom;
        pvert[c].dvSY *= TransformZoom;
    }

This code runs in one quarter of the time:

    D3DTLVERTEX* pvert = LocalMem;
    for(int c = 0; c < CopiedIn; c++)
    {
        pvert->dvSX -= TransformX;
        pvert->dvSY -= TransformY;
        pvert->dvSX *= TransformZoom;
        pvert->dvSY *= TransformZoom;
        pvert++;
    }

Pointers FTW!

I’m doing this sort of stuff now, which isn’t as fast as actually using hardware T&L, but is better than my older, hacky software transforms which happened on individual sprites, rather than at the VB level. Yeah I know… everyone uses world matrices and hardware T&L, I won’t bore you with the reasons I’m not, but there ya go. It works! (GSB uses a per-object world -> screen software transform for each object).

EDIT: These measurements may be a glitch. I’ve run and re-run, and re-run the profiler on both versions and now cannot get as big a discrepancy (although there is still a speed difference). Getting accurate measurements on a multi-core PC that has a live internet connection and various background services running is hell. Now I know why people like console dev :D

*relatively speaking.

Programming RTS Unit selection outlines

Posted on August 19, 2011

Programming RTS Unit selection outlines is a pain. I had an amazing GUI mocked up by an artist, and most of it is now in Gratuitous Tank Battles, but today’s todo list included unit selection outlines. He had mocked up this:

And now I want to batter him with a baseball bat.

(I always tell artists to do the best stuff they can possibly imagine, and let me worry about how I’ll make it work. Reach for the stars etc…)

You might think it’s easy. Just draw the image bigger first, with a flat shaded effect (I use render states, but YMMV), and then draw the unit on top. WRONG!

Firstly, that means your UI doesn’t shine through smoke or other effects layered on top, which isn’t as cool. Secondly. it means the units shadows are cast onto its own selection UI (yuck) thirdly, it just plain doesn’t work.  It works with squares or circles or other basic shapes, but take a complex image, scale it up, then draw the smaller image inside it. See what I mean?

What I really need is some way of doing what photoshop calls the ‘stroke’ effect, where the outline of an image is expanded. Not expanded directly from the image center, but expanded in all directions.

One solution mentioned online is to draw the flat-shaded bit (enlarged selection) 4 times, moving it up down left and right by 1 pixel each time. That’s great if you want a 1 pixel outline, but 1 pixel sucks, and beyond that, you will get corner issues, plus… 4x rendering potentially every unit in your army every frame is not nice.

Another solution would be to have extra versions of each sprite, already-scaled up in photoshop, and render them for the enlarged versions instead. This has issues where the image already touches the sprite corners, and in any case, that means that the selection outline is a fixed percentage of the unit size, rather than a uniform 4 or 8 pixels, which would look tons sweeter.

So… how did I fix it?

I haven’t yet… It’s driving me bonkers :( I am considering an offscreen render target that blurs a matted sprite, but that wouldn’t be crisp, which I think would look better. I wonder how they did those outlines in age of empires 2?

Note, almost all discussions online about this refer to 3d meshes. I use 2d sprites with alpha channels. Totally different :(

 

edit: this is what I have so far, quite like it, may compromise on it…

Cross platform angst and my hatred of middleware.

Posted on August 14, 2011

I do not have cross platform capability. if you play my games on linux, it’s through WINE, and if you play them on Mac, they were ported by a third party company. In the long run, this is likely to be a business weakness of mine. The ipad is great, and I can see it’s a huge market. Inexplicably, people seem to want to play games on phones, and with Microsoft making it more and more difficult to let people just download an exe from the internet, and the dominance of portals online approaching 100%, a move towards html5 or php / flash games seems like a sensible move in the long term.

Of course, people say that the down-loadable PC market is huge and not to worry, but I’m thinking 10,15 years ahead. if I’m still in PC gaming in 15 years, I need to think on those sorts of timescales. (I’ve been reading lots of warren buffet, it’s affecting me :D)

I recently checked out unity, because a top-secret-side-project-i-wont-discuss-yet is being developed in unity, and I’ve never even seen it. I was immediately put off. I can see how for many developers, unity is AWESOME. It certainly provides a ton of tools, functionality and easy-to-use stuff. It seems a lot of the fiddly, hard work has been done for you.

The problem is, I just HATE middleware. I don’t like the way other people code (as a rule, ancient-james excepted), I hate it when documentation says “you can ignore this coding concern, we handle it under the scenes” and I fear black-box code which promises to be ‘optimised’ but doesn’t tell you how, or with what assumptions.

I hate the fear that a bug will crop up after I ship, and not only can I not find it, I can’t fix it even if I could. That sucks big time. It’s rare, but not unknown. Plus I fear that ALL middleware has been built with certain limitations, and certain assumptions. Make no mistake, Unity is designed for 3D real time games. It might be ok to make a 2D turn based game in it, but you will be fighting against the tide, not with it, and carrying a lot of 3D engine bloat with you.

I celebrate the existence of unity for making many devs lives easier, but so far (I may be converted), it really isn’t for me. I like to code from the ground up, with complete control of everything. I’m a guy who uses char* and fopen(). By 2025 I might have moved entirely to std::string and CreateFile, but don’t hold your breath. Also, there is an element of ‘if it ain’t broke…’. I’ve made quite a few games with my own engine, so maybe I should build upon that, not throw it away in favor of someone else’s code?

A decision for after GTB ships, methinks.