After the LD release

This is a cross-post from the SGScript blog.

Before I proceed with the review, I’d just like to mention – this is the game I made. You might want to have a look at it before reading further to have some context when I talk about the specifics.

What went right: development estimates, luck and controlling chaos & unfinished code.
What went wrong: lack of a fully developed engine / editor combo, deployment process.

Development estimates and luck – there’s not much to say about those. I always had spare time on my hands to fix whatever popped up, there was no stress to get something done in time, no major feature cutting. Might be partly related to the lack of a fully developed initial plan. I just went in with my tech and hoped I could get an idea of the gameplay halfway in the process. And that did happen.

Controlling chaos & unfinished code – what I had at the beginning was a completely unfinished engine. No working physics, not even fixed-key input handling or cursor locking/relative mouse movement, no pause screen, no 3D-related entities (sprites, lights, meshes), no character physics, no cutscene system. Things so many people take for granted to be working and polished when they begin working on a Unity or Unreal Engine based project.

It was very easy to write all that, provided that there was (as in my case) some previous experience with all of those things. It was also easy to add game action hooks to the engine (like non-entity tick/input events). I also dropped the original entity system in favor of a much simpler one (each entity is defined by a creation function), fixed some bugs in the engine too.

A note regarding code simplification: Every dynamic language takes a lot of weight off your hands with dynamic (re-)binding, runtime (re-)evaluation, first-class functions. My advice: trust those systems. It will save you a lot of code generally spent on the premise that any such system could fail to be robust enough. They almost never do.

Lack of a fully developed engine / editor combo – as much as I liked to write Bullet Physics wrapper code and fix bugs in my engine, I would prefer to spend that time somewhere else. Or maybe not, but others definitely would. People would also prefer (and here I join them) to use an editor to add things to scene, not copy & paste coordinates out of Blender. It’s what I did for the position data. Writing any other non-spatial/visual data is just fine, though. I would in fact prefer writing to fancy controls. But not things that need immediate visual feedback.

Here’s a few more things that should’ve been available to me:

• Specular lighting – regardless of the type, it requires strong visual control. I have lights from far away leaking reflections through walls. I like unattenuated (by distance) specular because it’s the only kind that looks good and real. But it’s much harder to control in large scenes without shadows.
• Occlusion culling – it was actually in development but not quite finished yet. It would probably help control those lights as well as improve frame rate and allow to increase levels of detail a lot.
• Environment lighting generation – lightmaps and (blurred) environment maps would help a lot here.
• Mesh data extraction from the exported file format – I actually had to write this one while working on the game, otherwise there would’ve been no physics, and no game.
• Last but not least – support for other platforms. I really wanted to get more people to play this. Right now, it’s not happening.

Deployment process – there’s no errors like the ones you don’t get on your machine. The release started off with a “missing libgcc_s_dw2-1.dll” error. GCC was nice enough to screw with me at some point and didn’t let me know exactly when that happened. These things should be statically linked by default, though I should’ve checked all DLLs myself. It’s always too easy to forget that.

What followed was a silent failure. Most likely something simply wasn’t extracted from the archive but the engine should’ve notified the user. So that’s a bug, and it’s fixed now. Someone else couldn’t start the game without any explanation, that could’ve been the same bug. Or another one…

I received another report about a “variable of type ‘null’ cannot be called” error. Classic, means that the function doesn’t exist or the variable is not a function. Checked the file at the specified line – SS3D_CreateRenderer – SS3D addon silently wasn’t loaded. I’m going to upgrade all `include` messages to errors (SGS_ERROR) to fix that. Optional includes will be possible with either `pcall` or `@include(“…”)` (error suppression on function call). I should’ve handled such errors manually, though.

if( !@include("ss3d") )
	ERROR("Please install DirectX to run the game");

^ this is all that’s required to fix it. Yeah, a missing d3dx9_.dll triggered that obscure error. Dependency errors vs. me – 2:0.

Edit: In fact, it would be best to not link optionally available DLLs statically. When I finally get to making multiple renderers for SS3D, it should be possible to run the OpenGL renderer if the Direct3D one isn’t available or at least notify the user about the action to take automatically.

So, what we can conclude from all that? Dependency issues are generally one-off (with some recurrence) so there isn’t really any need for automated tools. As for the rest – the value of a language strongly depends on the amount and value of bindings it has.

And that’s all I need to know to determine the direction of development.