My toy engine was put on hold as I geared up for work in the real world, and I've learned a lot since then. A lot of is common sense, like "going to work hung over is infinitely worse than working from home hungover" while the rest of it is just more of how the world works, and how some people in the industry work.

Imagine how I, basically a newly annointed knight of C++11, reacted when faced with a code base that was written in what appeared to be a "C with classes" style than even a C++03 style. While not unexpected given what I had heard about game programmers, it was nonetheless uncomfortable.

But after working with that style for a while I realized why they like it so much: it's damn simple to understand. Everything is transparent. If you want to see how something works, you just peek at it and with a few pokes, you're done.

It took a while longer to realize that this wasn't because it was "C with classes", it was just that the original programmers wanted things to be simple! In the toy engine I was working on in July, things were just complicated. I thought that this was because, well, engines are complicated, but really it was because I had made it way more complicated than it needed to be. I was trying to serve edge cases that most likely would never be encountered, and even if they were, probably would be better suited to specially adapted code than extraordinarily complex general code.

At first I wasn't allowed to use C++11 features anyway, since we weren't sure about how they would be supported. It's a good thing too -- it took even longer for me to realize that my understanding of these new features had yet to really crystalize, and I was overagressively using them. It's like the old adage "if all you have is a hammer, everything looks like a nail." I was so blinded by how much my new hammer shined that I forgot how good my old tools were, and why they were there in the first place.

Let's take smart pointers as an example. I espoused strict usage of smart pointers over raw pointers, without actually thinking about what they were for. Thankfully, smarter and more experienced programmers have given several talks on smart pointers since then, and have pounded into my thick skull that once again, not everything is a nail.

The thing is, you only need a smart pointer if you care about the pointer's lifetime, and generally, you only care about the lifetime of an object if you're going to store a pointer to it. If all some function does with its Bar pointer parameter some simple operation without copying the pointer, then there's no reason to even pass a smart pointer. In fact, there's no reason to pass a pointer at all! Just use a Bar& and pass the onus of nullptr checking onto the caller (unless of course nullptr is a valid input--then use a raw pointer). There's no reason to incur any of the cost of a smart pointer in such a case.

There are also cases where even if you're storing the pointer, there's no reason to use a smart pointer. An example often used by Herb Sutter when talking about smart pointers is when you have a parent->child relationship, and the child needs a pointer to its parent. In my old engine, I was trying to do things like use weak_ptrs and thus I had to ensure that the parent was actually kept somewhere in a smart pointer and oh crap it was such a mess. In my zeal I had ignored the obvious conclusion that a deleted parent should also delete it's children, and thus a smart pointer was the wrong tool for the job.

Now that I have far more knowledge of the code base under my purview at work, I've started slowly adding in C++11. Mostly just auto, and some unique_ptrs and here and there. I'm slowly phasing out the "C with classes" style into a more C++ style, but I'm still trying to keep things as straightforward as they were. This is proving difficult however, as number of cases that the code needs to handle now has grown over an order of magnitude.

I've also started my engine again from scratch. It took me a long time to get settled in enough that I didn't feel totally lethargic after returning home from work, but I'm kind of glad it did. At first, I wanted to just apply what I had learned from work, but now I'm also trying more exotic things as well, to see where they fit and what they're useful for. Fun things like SFINAE, but it's going to be a long long time before I ever suggest SFINAE for anything in production code. I've written a bunch of SFINAE templates only to rip them back out because, in the end, the same end result could be accomplished in a more straightforward and easily understood method.

Learning how D3D works has helped a lot too. I don't like COM pointers much, but the API itself is an interesting contrast to OpenGL. Seeing some of the Sony console APIs helps a lot too in understanding what exactly OpenGL/D3D abstract away from you in order to work for different systems. For my toy engine, I've decided to go with a more D3D style adapter layer, except using actual smart pointers instead of COM pointers (of course, the D3D implementation has custom smart pointers to wrap the COM pointers, which seems to be working so far). I think it's way easier to implement this kind of adapter layer for OpenGL than it is to adapt an OpenGL style layer to D3D.

That's probably enough for now. I'll write about some of the sillier stuff (that works surprisingly well) I'm doing in the engine later.

Since then, however, plans have changed. Instead of building from the ground up in C#, I've gone back to C++. I'm still sticking with DirectX and I've found that it really isn't very different from OpenGL. All the ideas are the same. It's just that D3D organizes things more in-line with how the pipeline works, and takes a more object-oriented approach.

But I haven't even gotten to DirectX yet, really. Instead, I've been working on the innards of the engine, such as the event system or the input system or job system or resource management. All the little things that you need in order to build yourself a nice, usable game. The basics are mostly working, I just need to finish up the base logic layer and implement a simple scene graph before I can draw myself a picture. I think it's better this way really -- I don't have much trouble in the drawing pictures area, but I don't have much practice mucking about in the other game engine subsystems.

Also C++11 is nice. Really nice. I really like lambdas and the new smart pointers. How did I used to live without shared_ptr and unique_ptr? Of course, shared_ptr and unique_ptr have their own set of problems, but it's certainly better than trying to keep track of everything on your own.

I've gotten to about 5,000 lines of code since May. That's pretty good I think, considering the fact that I only really get to work on this at night. I'm getting really close to where I can draw a picture and have some controlled model waltz about. But I'm still trying to decide which LUA/C++ binder to use, and how to best incorporate it into my engine. I definitely want scripting, but I'm not sure exactly where it should fit in. Also I need to re-evaluate my components system. I'd like it to be flexible without being a PITA to use, but right now it's neither flexible nor easy to use.

Also the idea of Tactical RPG has been shelved. I've decided it's just not a realistic goal for a first game. Instead, my goal is now....MARBLE MADNESS! I had completely forgotten about that game until I saw a speed-run linked on reddit. I remember trying for ages to beat that game as a kid, but apparently the game is only like 5 minutes long if you play correctly. I don't even know for sure if I beat it back then.

Anyway, Marble Madness would make a great showcase game. It's one of those games where you can make everything pretty for the hell of it. Marbles? Show off reflections, refractions, maybe even caustics. I can go crazy with the environments if I want, the original Marble Madness sure was. Marble Madness also has components that I would not really need to implement for a Tactical RPG, such as a physics system. All-in-all I think it's just a better choice for an initial goal.

Afterwards I can get back to trying to make a Tactical RPG. Until next time.

I started with the SlimDX tutorials (which are kind of oddly written, but easy enough to follow) and was happy to see my very first DirectX triangle in years. The last time I had played with DirectX was when DirectX 9 was shiny and new, and that was long before I understood the math that mapped that triangle to the screen. But now I do, and thus the next logical step was writting some camera class to manage that math for me.

In visualization, the most common tool for this is an arcball camera. Everyone uses an arcball camera, and conceptually it's pretty damn easy. Perfect first 'project' in C# and DirectX. Took about an hour (where in the DirectX docs can you find info on how constant buffers expect matrices to be laid out?) but after a lot of swearing and futzing, I had a nice, smooth arcball.

Of course, my cube (upgraded from the initial triangle) wasn't particularly interesting. Rather than do the most familiar thing and write a simple raycaster, I decided to try to do something more game related.and I wanted to draw a moel, but then I found out that Microsoft dropped model loading code in DirectX 10, and since I was targetting 11 for my tools, I was going to need to write my own.

But before that I would need some models to load. Thankfully, the DirectX 11 SDK comes with some, even if they're in the not-for-production-use SDKMesh format. I decided to write a loader for SDKMesh files anyway -- it'd be good C# practice.

First off, let me just say that the MSDN description of a SDKMesh file is useless. If they had listed the types and byte offsets of the members of their structures then it would have been easy, but alas I spent most of my time poking around SDK example projects and hitting F12. I also got a healty refresher on C/C++ struct layout guarentees -- the one where the compiler will lay them out as it pleases.

All in all, it took much longer than I had thought it would, but I did finally get it working. Granted, I did waste a bit of time by porting the DDS without D3DX example because I couldn't find where SlimDX had put the stuff, but hey, now I've got a separate DDS loader just in case. Next up is a crash course on HLSL I guess, then some ironing out of the actual Tactical RPG game design and data formats.

While I think my previous layout and design was all well and good, it was still contained an undeniable amount of suck. The design was a (failed) attempt at being clever. This time, rather than spend an inordinate amount of time and its layout and looks, I'll let those who've done it better show me the way so I can focus on actually filling it.

Plans! Man do I have plans. I'm really going to work on that tactical RPG this time. Last try with Qt and C++, I got a dog to move across an ugly heightmap. It was rather poorly designed and thought out. Afterall, why start from scracth when an apparently new era has dawned: the era of game frameworks. I considered three: Unity, UDK, and XNA, and ended up choosing XNA. Why?

Mainly because XNA was the most barebones of the three. Unity and UDK are both full featured customizable engines that really only need some scripting and content before you've got a full-fledged game. They come with tools, their own pre-defined pipelines, and rendering systems. Granted, these can all be customized to your liking through their scripting interfaces, but the whole point of this exercise was to learn the inner workings of a game engine! With Unity and UDK, the engine is already there. You're just building a game around it.

XNA is a little different. It's a framework for building game engines, rather than being a framework for building games. All it really provides is a barebones game loop and a bunch of boilerplate utility classes. It's exactly what I'm looking for, really. Also it has the additional benefit that I get to learn some C#, which I've oooed and ahhed at in the past but never really gotten a chance to actually use. However, this also means I'll have to write my own toolset for my game, and that's a daunting task in its own right. But I've been toying with SlimDX, and so I get to do more C#! Ooos and Ahhs all around.

Of course, aside from that I still have to finish the rest of this site. And apply for more jobs. Weee.