.plan for Daniel Buckmaster

It's been ages since I've written anything, so here goes. I'm afraid there won't be anything super interesting or attention-grabbing, which is why I've had to resort to the old .plan naming scheme - this is really just some rambling, meandering, and towards the end, a little bit of planning!

Safaris in T3D

One thing we all know Torque is lacking is documentation. I thought it might be a nice idea to try to solve this organically by suggesting that people write up their experiences discovering things about the engine. We go on little 'safaris' all the time when using Torque - or at least, I do. The source code is so vast that you're constantly being challenged to learn about a new part of it.

I thought people might find it helpful to see these little journeys documented, as some sort of way of easing themselves further into the engine source. I've written two of them so far, one on the engine's return code and one on the existing unit testing framework.

The jury's out on whether these will actually prove to be helpful to people. I'm well aware that the two I've done so far are incredibly rough, and probably need a bit more polish to be very useful to anyone but me. But they're a start, and maybe I'm overestimating how confusing my stream-of-thought style is.

Unit tests

Speaking of unit tests, I've been busy replacing our current test framework with Google Test, a helpful library for unit test stuff. The motivation behind this was twofold:

1. Using external libraries for things like testing increases our compatibility with other open-source codebases, and allows new developers to come aboard without having to learn Torque-specific systems.
2. T2D uses it, and more similarity between the two engines can't be a bad thing - especially if we can now share unit tests for core systems.

Once we get this reviewed and merged, we can start the long process of reviewing and porting T3D's existing unit test suite, and ading new tests to cover more cases. One cool feature is a plugin I found that adds memory leak checking to Google test. It will automatically validate the state of the heap before and after every test that is run, and fail the test if it's leaking. It already caught a 'memory leak' in the console print code that is used to output test results - but it turns out that's just how the console works, and it can be disabled :P.

Funnily enough, having dug into them a little bit, I can highly recommend unit tests as a fantastic way to learn about parts of the engine you wouldn't normally venture into. There's some interesting stuff there!

t3d-bones and Python

You may be familiar with t3d-bones, my attempt to make a simple-as starter script template for T3D, and to write make basic tutorials to build on it. I just finished an important milestone for myself - I ported the basic main.cs to Python, thanks to Frank Carney's ScriptT3D resource.


And I made a demo with a Python logo just for funsies (I didn't make the logo, though. You think I'm that artistic?). I'm fairly happy with the wrapper I wrote around Frank's code - primarily this involves the 'new' object, which allows you to create SimObjects with decent Python syntax, rather than writing inline TorqueScript everywhere. For example:

group = T3D.new.SimGroup('GameGroup')

logo = T3D.new.RenderShapeExample({
    'shapeFile': 'game/PythonLogo.dae',
    'position': '0 3 2'
})
group.add(logo)

I've also started to add decorators that export console functions in a really slick (if I do say so myself) manner:

@T3D.callback('GameConnection')
def onConnect(self):
    self.transmitDataBlocks(0)

@T3D.callback()
def onExit():
    ServerConnection.delete()
    ServerGroup.delete()
    T3D.deleteDataBlocks()

The first snippet defines a callback for GameConnection::onConnect, (notice how the 'self' object will be bound to a SimObject which you can call TS methods on, thanks to Frank's code). The second defines a namespace-less callback for the onExit function.

You can find all this code in the python branch of the repo, where I'm keeping it for now, until I decide whether I should merge it in and have __init__.py files everywhere, or keep it separate, or start a new repo. Lukas was talking about porting t3d-bones to C#, so maybe a polyglot repo would be a good idea... I haven't started tutorialising the python stuff yet, but hopefully the code is self-explanatory enough!

Monster Mash

I found out a few months ago about itch.io's jam page, which lists community-run game jams hosted on itch.io. I decided, since it's the first week of my uni break, that I'd commit to making a small game for the Monster Mash jam. Though it's only a week long, I'm hoping to get a basic idea out. The theme is to create games with 'monster' protagonists, so I'm planning on doing something a bit interesting. To make up for my complete lack of 3D modelling abilities, I plan to make a game where you play as a 'swamp thing' or lake monster that is never seen above water. You'll lurk around, snatching unfortunate tourists trying to enjoy the beach, or messing about in boats.


The plan is that you won't go completely unchallenged - park rangers will try to shoot you if you get too bold. There's a twist, of course, but I have to see if it plays any good before I reveal it!

Jams seem like a great way to hone game-dev skills, and just find good ways to improve the engine. I'm very much looking forward to getting a handle on the art pipeline by creating some very simple tourist models (think Matryoshka doll level of shape complexity here), and making some nice third-person camera behaviour. And it's also a personal thing - I've often bemoaned my inability to finish an actual game, so hopefully having a single week with a very tight focus and deadline will do me some good!

So long,

and thanks for reading! Until next time...