Like many of the other privileged few of the PC Game Development World, Daniel and I attended Steam Dev Days last week. We met a number of lovely people, and unlocked crates filled with things that are potentially unstable but nonetheless have high economic demand.
We also went to a series of valuable, inspirational talks by Valve employees in which they explained their strategies for game development and how they do business. The effect on our game development has been startling. We think you will be pleased by our new business model.
With Daniel and I derailed by Hats, and with David out this week, work has been kind of spastic. I have a zillion tasks, on various boards, in various states of completion and coherence, and it’s all hurtling towards something. Some notable events around the office and in the code base since our last update:
– The game runs faster. In particular, we no longer cut our frame rate in half every time we move the mouse, and we no longer do 40,000 box/frustum queries per frame. My work machine hovers between 50 and 60 FPS now, and my machine at home (which is slightly newer) runs at a constant 60. Obviously, there is still work to do – there is no reason why my work machine shouldn’t also be hitting 60 FPS constantly, but the problems now have to do with state sorting and trickier optimization. There’s probably still low hanging fruit kicking around, but we’ll see. We also made several improvements to the actual speed of the simulation part of the engine, mainly to do with filling jobs: on Micah’s machine, we went from having 19 people take 10 msec per simulation frame to having 300 people take 2 msec per simulation frame. (This is total # of people, not each.) This includes pathfinding and collision avoidance. I’m not sure what we will do with this. Animals are still kind of slow, but we also optimized herd code and fixed a bunch of other dumb slowdowns in how we interface C++ and Lua.
– This STARTLING NEW FEATURE:
… sorry, false alarm. It’s just more hats.
– User Interface Stuff. David left me with a zillion sheets of UI to implement. Some of them, like the Jobs UI, are getting pretty close; others, like the commodities and the work party screen, are still somewhat of a mess. (Don’t even ask about the building creator.) The character panel, though, is starting to look like it’s supposed to. Here’s David’s notes, along with my first incarnation of the character panel, which we shipped Rev 1 with:
I then got it to look like this:
which David has covered in Numbered Demands. (#7: “Put a list of diseases (‘bloatlung’) in this area. #9: Hats.”) Here is the current state of affairs:
The two little icons on the display will take you, immediately to the character’s current a) home, b) work site. We will also eventually display the character’s hat preferences, hat vitals, and whether or not the character is wearing a hat that is in season and, in fact, how much he cares. Much of the user interface has now moved into a consistent location instead of floating windows; character windows also still float, but we’ll see if we end up liking it or not.
In other news, the pre-alpha has now most definitely swung from “this game doesn’t work on my computer at all” to “What is This UI, My Eyes”. Right now, I have to finish restoring the building creator to sanity – a lovely task that I will get into, in a future blog post, or possibly leave for Mr. Baumgart. The UI is half broken, and I have a bunch of improvements to make to the other half and… well, a picture with a hat is worth a thousand words:
One notable train of thought from the alpha testers is that there is no immediate feedback in game for when a job is activated to indicate that the game actually got it, other than its presence in the jobs UI – so, well, I have to add a bunch of that. This means little happy icons for everything indicating that they have jobs on them, arrows for people pointing to their job locations, all kinds of mummery and frippery. We are still having ongoing problems where people will basically stop working on anything, for play times ranging between 5 minutes to half an hour. Micah is busy implementing replay and logging code as we speak so that we can actually autopsy games and figure out what the heck happens and why nobody ever finishes their work. There is also the ongoing Campaign to Prevent Workers Being Trapped In Building Modules to think of – please, give generously.
We also think we have finally – finally! – cracked the problem of Science, and how to make it Fun and Enjoyable and Fitting Into The Rest Of The Game. So there’s that, but it deserves its own blog post.
So, yeah. Game development! Hooray!
I take it you guys got a steam box out of that? Have you tried firing up CE on the box?
Also, do you plan on allowing CE to be played with a control pad or will it all be point and click?
You can’t really restrict a game from being able to be played on a steam controller: it’s recognized as a keyboard and mouse HID. We’ll spend at least a bit of time optimizing for the controller, but I’m hopeful that it’ll translate pretty well just because mouse movement and the touch pads seem to go well together, as long as there’s not a lot of dragging and so forth.
Also, since the game will be playable on Linux, there’s no good reason to say you can’t play it on a steam box. I have one in my living room and am trying to get our internal build of CE to work on it. No luck yet, but it’s alpha software on beta hardware, so it’s going to be rough.
I’m suddenly wondering why TF2 DOESN’T have a hat-particle emitter for hats.
Your new hat tech seems really great and all, and I’m honestly really excited about it, but have you considered adding some kid of Energy system? I’m not a big fan of games that I can play for more than 15 minutes at a time without using gems I purchased with real money.
Funny you should mention that. There’s a bit of a Saga behind it..
I just really think you could Crush this business model.
Energy Crush Saga?
now I want that instead of this insipid game
Do the minimal system requirements suddenly drop, or are they still bounded by DirectX features?
EDIT: Daniel pointed out that this response is totally incoherent. Yes, we are still bounded by DirectX features.
Let me guess, Science will involve smashing large quantities of Large Hats together? There are more efficient ways to summon Yog-Sothoth, you know…
Why else would we need a Large Hat-ron Collider?
I LOVE reading your weblog. I have no idea what you are talking about 90% of the time, but I am looking forward to playing the finished product, hats or not.
“Fezzes are cool”
I now want to see a, ahem, blue telephone box random event as a means of removing madness-inducing artefacts.
could i see one bug next time?
Hats! Alright mates! You’ve returned my faith in humanity! Woohoo!