Ogre: Standing on the Coccyxes of Giants

(Editor's note: I'm not entirely sure if that's the correct pluralisation of "Coccyx".)

I'm currently spending a lot of time working with Ogre (for complicated reasons I can't go into). Having spent a bunch of time with a number of graphics engines over the years, it's certainly an interesting prospect. My previous beau was Irrlicht, though that was as much due to its inclusion in ProtonSDK (which has been my project quickstart of choice for most of a decade now) as to any particular quality of the engine. My previous experiences with Ogre had led me to believe it was pretty much more of the same; bargain basement graphics coding mostly interesting due to the ability to fork it and hack it about any damn way I feel like, at the cost of looking like complete and utter crap.

Well, it turns out Ogre's changed somewhat in recent years. While most other freeware Open Source graphics engines have dwindled in a world in which any indie can grab CryEngine, UE or spits Unity* and have shinies aplenty, a rather devoted corps of volunteers has taken on the task of turning Ogre into a modern graphics engine. The Ogre forums are now actually active again, with people asking questions and getting answers from the devs.

And blow me down if they haven't actually succeeded in their quest to some degree, too! The latest Ogre, version 2.1, comes with a fully-realised Physically Based Shading model that currently works on PC and iOS. Examples are included for everything from radiosity models to SSAO. To add to this, the current version of Ogre is without a doubt the most blindingly fast engine I've seen in a very long time: My test mesh subdivision scenes for work hit 12 million polys onscreen before the renormaliser died. I set up a 40x40 grid of 12,000 poly cubes to test the instancing system out; I got 40-50fps in debug. On an iPhone SE.

The core premise behind the current version of Ogre was to implement DOD and AZDO concepts, and honestly, I'd suggest they succeeded in spades. If you want a really fast engine to render some not-quite-bleeding-edge-but-still-very-very-pretty graphics, pick Ogre. Especially if you don't need anything overly complicated like IK or overly hand-holding like automated navmesh generation, and just need something to push your polygons for you!

BUT. Oh, and there was always gonna be one, wasn't there? The current version of Ogre is new and barely stable and oh heavens is it a mess in so many damn ways.

- Want documentation? Either take the months-out-of-date versions from online, or spend ages trying to work out why the doxygen build doesn't seem to work!
- Want a starting barebones project? Literally only just added in - and to make matters worse, it uses the overengineered sample code shell too!
- Want an art pipeline? Hope you can persuade DERGO to run! ... In Blender! Good look persuading your artist to use that!
- Want to do some custom shader work that works with Pbs? Hope you like poring through hundreds of lines of template code!
- Want to use point lights, which is to day BY FAR the most common light type in most interior game environments? Well then do remember to turn on Forward3D - because it's not on by default, and point lights just flat-out don't work without it!

Yeah. It's not a professional development by any stretch of the imagination. By the standards of open source projects it's doing pretty well, and I'm not going to lose sight that this is just a few guys beavering away at this in their spare time. But there are just so many little frustrations with it that spoil what would otherwise be a pretty stunning engine.

All that said, though... with such a dedicated team, I look forward to the possibilities. Right now Ogre users aren't quite standing on the shoulders of giants, but who knows how high we could climb?

---

* I have a powerful irrational loathing for Unity. Part of it is because C# just shouldn't be a scripting language, part of it is because the tools irritate the hell out of me in exactly the way Unreal Editor never has, and part of it is because it's responsible for the recent deluge of some of the worst shovelware I've ever played (as well as being a really obvious millstone around the neck of some of my favourite games). But I'll do a full post about my irrational Unity hate some other time.

On Early Access and Alpha Nonsense

Ever since Minecraft, I have had a huge liking for the survival-crafting-open world type of game. I've thrown countless hours into titles like Terraria, ARK, 7 Days To Die, Empyrion, Starmade, Even a lot of my other favourites have some portion of that kind of gameplay in them - State of Decay being an obvious example.

With the exception of Terraria and State of Decay, though, all these games have one thing in common:

This Caption Is Not Yet Complete

In fact, the whole survival-crafting-open world kind of genre is completely overrun with "Early Access" games. Most claim to be in a state of early "alpha" development, with endless new versions being uploaded to rapturous responses.

Another favourite genre of mine is the roguelike simulation genre popularised by Dwarf Fortress and recently given a new lease of life by Rimworld. Here's a recent Rimworld release note. There are 97 bullet points in that list and each is a significant game change. It took them a large chunk of a year to release this "alpha".

So what's the problem?

Well, it's not exactly a problem. I play these games all the time, and I look forward to each new Alpha release as much as the next frothing fanboy. Indeed, I'm currently fighting off the urge to fire up 7D2D and get eaten by wolves. Again.

The Age of the Wolf Is Upon Us

Alpha 16 of 7D2D. Alpha 17 of Rimworld. Alpha 6.0 of Empyrion (they like to do lots of point releases). All of them extensively tested before being released to the public; hell, the latest Empyrion Alpha went through half a dozen experimental releases before reaching a "release candidate".

Yeah. A "Release Candidate" for an Alpha.

I know not everyone reading this is a software developer, but most people are sufficiently au fait with computer terminology to know what an Alpha is supposed to be. Much as with my recent attempt at getting Gestalt to Alpha. it's meant to be an initial working version of the software, built so that in-house testing can begin but with the express understanding that content is still subject to extensive change. Calling these releases "Alphas" is wildly distorting the meaning of the term; they are extensively tested and (usually) fully playable games in themselves. They are not released until the main showstoppers are worked out, when working out the initial main showstoppers is the entire point of having an Alpha test!

The question then becomes, why are these releases referred to as Alpha? Well, you'd have to ask those developers, but the answer is at least partially historical, and seems to mostly go back to Minecraft and Dwarf Fortress.

Both of these games began as one person projects. This carries with it a bunch of implicit limitations, some of which can be countered by a developer of sufficiently broad talents, or failing that, a game design which is intended to ameliorate the developer's limitations (for example, Toady One/Tarn Adams' inability to create art drove the ongoing roguelike "style" for DF).

Dworfe. Such Art, Many Wow

But the one thing that no quantity of talent can ameliorate is the inability of a sole developer to properly test their own work. Yeah, unit tests are a great help. But ultimately, user testing cannot be avoided, especially in games where behaviours are far more important than batch-friendly test cases, and user testing needs pairs of eyes that do not belong to the developer.

Enter the public alpha. Now you can release a sketchy, half-functioning version of your software and people not only line up to help you find the holes, they actually sing the praises of your product into the bargain! They do so because they get access to the game, and if it grabs them, they want ot keep access to the game; and every new update feels like a whole new upgrade to the product they already fell in love with. Unsurprisingly, many such games remain in alpha for a long time. And Minecraft took it one step further - taking pre-orders for the game in return for continued alpha access.
It wasn't a new idea, but it was certainly an idea whose time had come, and soon enough "alpha access" became the order of the day.

But once you have a large(ish) team and an in-house testing regimen, you're not selling alpha access any more - the entire premise that drove public alphas in the first place has gone. Now, you're selling the early access to the game content; this was, after all, what drew people. But you start to get disagreement between devs and players; players want new content and new experiences, while devs want to sell more copies; and when the sales dry up, that is when the game "goes gold" in an attempt to drum up a few more sales (which rarely works) and then it's on to the next project. Ultimately, the idea is to increase sales massively by sustaining them over a long period of time. It's long-tail marketing, only the tail is in front.

In this context, then, I don't think Alpha 16 of 7DTD or Alpha 6.0 of Empyrion etc etc can meaningfully be called "Alphas"; they are well-tested content deltas. Nor are they truly "Early Access"; what is being sold is not truly "Early".It's instant access, along with the promise of ongoing development. And there really isn't anything wrong with that! I just wish that the industry was being a bit more honest about it.

Here are more accurate terms.

"Early Access" -> "Continuous Updates"
"Alpha Releases" -> "Delta Releases".

(I'd suggest Season Passes for the first one, but the DLC mobsters already tainted that term.)

To be clear - I'm serious when I say there's nothing wrong with this model. I may even use it myself one day. But if I do, I'll be very clear about what I'm selling, and not use misleading terms like "Alpha" or "Early Access".

Sauntering Back

I've been doing that whole "real work" thing after a couple of freelance opportunities came my way, so I've not had a lot of time for blogging.

Unsurprisingly the alpha contest went nowhere. I wasn't that taken aback given Gestalt is hideously poorly optimised and if I'm honest I don't even understand half the code any more after all these years. I'd probably be best served starting again.

Over the next few weeks I'm likely to be pushing hard on my freelance work, but blogging probably serves as a good way to relax in-between heavy sessions. I have a lengthy rant post about "Early Access" as a business model that I've been wanting to write for a while, and I'm getting started on a new Adventurer Conqueror King campaign this week, so there may be some wittering on about that. Finally, since I've been spending a lot of time working with Ogre lately, I might spend some time blogging about that too.

Successfully finished an alpha in time for the dev contest. Will need a bit more clean-up still, though, I have to admit.

I took a week away from the computer after the insane crunch to help stave off burnout and I think it was successful but just to make sure, I'm gonna spend some time working on a little side-project I cooked up with Bethan. I call it "SNEK" and it's basically a rather strange Snake clone with a few odd twists - most notably, the game stored the entire set of moves, allowing me to do strange things with time.

Current plan with that one is to cook it up in HTML5 and pop it on a website. Might even embed it here just for the oft-mentioned shits and giggles :)

Furious Coding Update

I decided a little while ago to enter Gestalt into the WG Labs Dev Contest, which ends tomorrow evening. I kinda realised midway through last week that the closing date was rapidly approaching so I sat down and worked out a pathway to Alpha, and it came out as 56 bullet points.

As of this evening, there are 20 left.

Agonisingly close and yet I'm not giving up just yet. If I can get it into a state which can at least be called an Alpha then I can still enter the contest. So for now, insane crunch GOOOOO!

Wish me luck and I'll see you the other side.

Quick update because I don't post here nearly as often as I perhaps should.

Progress is still being maintained. I've decided to try to reach Alpha by the end of April in order to enter a contest, and have cleared out (nearly) all of my bug list in order to enable that. I have the outline of a plan to Alpha ready, so I just need to knuckle down and get it done.

Part of that plan is to start implementing the structures necessary to permit multiplayer, since that's something this contest requires. As can be seen from my old posts about Gestalt, multiplayer's always been on the cards, but it's not been forefront in my mind so I think I have some refactoring to do to make it work. Probably a good idea to do that now, tbh, even before I have a single line of netcode.

Finally, gonna try to get Fraps to give me some decent video from the game. Will post it up if it works.

Node connector points calculate nicely and without unnecessary overhead (my first pass on it was embarrassingly poor, so I immediately redid it). Worked first time, too - I always feel a bit suspicious when that happens :D

I also turned on Box2D's Continuous Physics mode because the change in physics scaling has led to some rather unfortunate tunnelling issues with the axons and the bucket. It has had a really crippling effect on the framerate, quite pathetically so in fact - under 30, in a game that consists of nothing but circles and lines!

So I set up Release Mode and was gratified to get a stable framerate well over 120. Well, that's something at least. Picking still doesn't work right, I need to completely remove the ScrollComponent and bake my own replacement (which should hopefully fix pinch-zooming in Android and the weird scroll wheel problem under Windows, as I think it's ScrollComponent that's causing both issues), and that's a big job, so with the school run rapidly approaching I've decided to leave that for next time.

Still, though, a hell of an afternoon's work.