It's funny how things can sneak up on you. I've been working on adding lasers, fixing bugs, mucking about in Blender, and adding animation to my recent art acquisitions. There have been a lot of evil, evil bugs to fix, and I've been pretty heads down. So today, after I hunted down the last bug in a rather long series, I was testing the fix when I had the sudden and shocking realization that the game I've been working on full time for two years and five months had become a game!
Not a monstrous pile of code. Not a graphics demo. Not an engine. A game.
I could show it to a grandmother and she'd recognize it as a game. People can play it. Quite a few people I suspect. Not as many as I need it to, but a lot.
It's still missing many of its big features, and it has lots and lots of bugs, but it is undeniably a game.
More importantly, it is THE GAME!
The catalyst for this project was the great times I had playing co-op LAN games on Tuesday nights with my buddies. I had a vision of the kind of game I wanted to play. None of the big game companies ever made that game. At long last I can play that game.
So cool! So amazingly cool. Wow.
No, you can't play it yet. Sorry.
Last night I needed a square root function that would work on 64-bit unsigned integers. I have been using the standard library's sqrt
, but my first thought was that an integer square root could be faster.
I looked around and found what was said to be a "fast" integer square root on Stack Overflow
by Craig McQueen. I used the code as-is except that I changed it to use 64-bit unsigned ints because that was what I needed.
It seemed like a reasonably performance efficient algorithm, but I had always heard that sqrt, even in hardware, was slow. Because sqrt gets used a lot, I thought better safe than sorry, so this morning I decided to benchmark the integer algorithm against sqrt
just to be sure.
I'm not much of a gambler. I don't buy lottery tickets. When I went to Vegas, the only gambling I did was with my change from breakfast. But I don't mind if someone else wants to gamble with their money. I've been thinking a bit lately about the growth of gambling in MMO games and whether its an element I want to include in my game's economy.
I took a couple days off for spring break, but I've been working on getting my models to share rendering resources. I'm afraid I have to let you in on a secret: not all MMO development is super exciting. Up until today, each time I loaded a model, I loaded its complete scenegraph including transforms, and allocated a material list, a vertex array and and a set of meshes for every instance of that model. If I had 20 identical objects on the screen, rendering all those duplicated meshes was really super inefficient.
I had a few requirements:
- I wanted model loading to be asynchronous.
- Models should share meshes, vertex arrays and material lists allocated by the renderer.
- I wanted to be able to customize models individually (hiding submeshes, and moving/scaling/rotating model components.)
The asynchronous loading part was the simplest. I used an AVL tree template to build a model cache, then made a quick little task to do the loading when models aren't already in the cache, then schedule it in my task system. The asset system was already re-entrant so loading the model scenegraphs was no problem. Then I added a lock-free queue to put the finished models into and a step in the update to poll that queue for finished models, and Bob's your uncle. No possibility of long frames during model loading.
Once I had the loading working, the really tricky part started. In order to share renderables between model instances I used a super handy shared pointer template
I generally try to avoid optimization until nearer the end of a project, but my new art showed up a real slow point in my game. I have a serialization system which can read or write most in-game classes into bit-packed buffers. This is super helpful for putting classes into network packets or into files on disk. In addition to bit buffers I also have a database serializer that can use a database as a storage system and an XML one that writes neatly into XML files. Handy right?
I discovered this week that loading the new models which had 5000+ polygons was taking up to 3.5 seconds per model. I already limit model loading to one per frame, but loading up 20 in rapid succession meant a few very long frames in a row and an apparently hung game. Digging in, the culprit turned out to be loading the vertex and mesh arrays.
With my new shield effect last week I've been thinking a lot about the appearance of my game. The art style, what effects I'll need, lighting, what I'm going to do for models. There are a lot of complex art issues. And I'm really at the point where my small volume of art isn't cutting it anymore. So after talking it over with my CG Supervisor nephew over dinner last Sunday, I decided it was time to start spending some money on art.
On Monday I purchased a package of models from 3DRT.com
which is when the real fun began.
I like to quest. One of the features Bioware built into The Old Republic is a quest helper. Every quest you get appears as a destination on your map. You go there, do your thing, then the marker changes to wherever you need to go to collect your reward, and the quest is done. There's no exploration. There's no discovery. There's no challenge. You just follow the map. How on earth did this fun-obliterating feature make it into the game?
Fun day! I've been working on a new shield effect the last couple days and I got it working today. The idea was to develop something like this fresnel soap bubble effect
. I have to say, WebGL is pretty cool. I never thought I'd be following 3D rendering examples that run live in a web browser. Really nice of them to supply the source code
for the shader.
Not that it's a simple drop in...
One morning when my daughter was very little, I was shaken awake by a very frustrated little girl. Opening my eyes, she was pulling and pulling on her little arm, which was completely underneath me. Seeing I was awake, she looked up at me, straight in the eye, and despite having only recently started to talk, she opened her mouth and clear as a bell, she said "STUCK!!!" Today I can relate to how she felt.
A couple days ago I was reading the November Game Developer magazine, always a source of good stuff. There was an article The Game Entity by Michael A.Carr-Robb-John. I have an entity system in my game, so I was interested to see what he had to say. Now there was a lot of good stuff in there, but one thing really stuck out for me. He mentioned that it is nice for game entities to have variable update frequencies so that entities that nobody is particularly interested in don't burn a lot of CPU cycles. Now for me, expecting to have hundreds of thousands of entities, each with maybe a dozen components being simulated on a single server, this was a brilliant idea, one that could save me a fortune in server costs!
Add to that, he mentioned briefly about the potential of multithreaded updating of entity systems to more effectively use newer CPU's. Another server capacity bonanza.
With apologies to Winnie the Pooh, something I've really come to appreciate working with other people's code is code that compiles warning-free.
When you compile code with warnings you have to ask - are the warnings there because you've done something wrong? There's no way for you really to know. You need to look at the code, figure out what it is doing, and decide if it is correct. That's not always easy. But it always takes time.
Multiply a couple minutes of investigation by several hundred warnings, and new code can be a real pain to integrate. Not to mention that every time you integrate a new version, you have to look at the same warnings all over again or, if you've fixed the warnings, you have to integrate those fixes into the updated codebase.
So if you're making code for others, take the time to get rid of the warnings. When a new one comes along, it will be easy to spot and it'll most likely be in code you just wrote so it will be easy to fix. You might even consider turning on the compiler setting to treat warnings as errors.
One last thing, no points for using #pragma or compiler settings to suppress warnings. There are very rare occasions where the code is right and the compiler is wrong, but hardly ever.
From the programmers' wisdom file.
Thanks, I'm still looking for ideas of what people think could be fun to do in an open world RTS.
Sounds awesome to me, i like the idea of NPC encounters/quests etc,one thing i found when i played was you are right once you build a base and get harvesters running etc, if noone is there to fight you kinda float about waiting. Dont know what you ...
I had an absolute grand time playing this weekend. Thanks for helping me out whenever you could, Rob!
Looking forward to an awesome future
Hey Dondergod, what firewall program, and what did it complain about? It's not BitDefender
I tried to get in, but my firewall kept blocking it.
Unfortunately I did not have the time this weekend to look further into it. Probably an easy fix, but I had too much to do.
Hope I will be able to enter the next test!