A Closer Look at Craftstudio

Games. Games never change.

Last time on DisCONNECT (in the dim and distant past) I talked about Craftstudio, a game development tool which has been in development for a little while and only recently reached beta. It’s an interesting little package which acts like an “all in one” for game development in a way. You can create all your graphical assets in the program, simplifying the pipeline significantly. It’s based almost entirely on cubes, giving it that Minecraft look which is pretty popular today. It also proudly proclaims visual scripting as a major feature, which might lead you to believe that CS is easy to use. I’ve been playing with it for the last month or so, and I’m willing to share a few more thoughts about it. For my part, I come from a Unity and Game Maker Studio background, not as a total newbie to some of the concepts in game development.

What’s good?

The content pipeline and creation tools. Yes, they’re simple. That’s kind of the point for the most part – this isn’t about making Half Life 2 with a bunch of 14 year old kids. It’s aimed at something more achievable. No doubt some will still find it far too limiting but there’s definitely something to be said for the ease of use offered by the package. One of the most frustrating things with Unity for example is having problems with importing assets, and Unity is far and away one of the best when it comes to supporting different formats. Even then, sometimes when you import something it just breaks – materials break, animations break, the mesh deforms in some weird way, the list goes on. With Craftstudio you don’t have that problem, though it also means that besides textures and sounds you can’t really import anything else. Make that desk model and drop it in the level – it works flawlessly, as you’d expect.

Also level design is absurdly easy with Craftstudio: it’s identical to building a map in Minecraft, except it’s a bit glitchy at times. You might be thinking “Oh but Soldant I remember making maps in Build back in the 90s and that was really easy!” to which I reply “Yeah so do I, but look at Hammer!” and remind you that 3D level design can be pretty complex. But that’s not the real issue – the real issue is that making a level in Unity for example pretty much mandates that you make it in a 3D modelling app, which are even worse than Hammer for level design. No, sorry guys, they’re simply not as good as the BSP map editors. This also means getting creative with texture atlases and UV mapping unless you want an absurd number of draw calls for even simple level meshes, which itself is a challenging task to tackle. While the level geometry is a lot simpler in Craftstudio, it’s also a lot easier to create without having to worry too much about performance issues. It just works.

Speaking of performance, Craftstudio is also really snappy. Granted it doesn’t appear to have much to do in terms of graphical demand, but it seems remarkably fast with things like raycasting. I’ve seen solutions where people fire off a raycast extending from each bullet to detect for collisions, and then checking the distance between the bullet and the hit object to see if it’ll actually ‘hit’ or not. In something like Unity you’d be slowing the system to a crawl, but not in Craftstudio. The more savvy of you will be saying “Wait, why the hell would you even want to do that?” which brings me to my next concern…

What’s bad?

It’s not even close to finished. Really, this should not be a beta. For all the promise it shows, there are still some significant issues when it comes to actually making a game, which is sadly what the product is supposed to be designed for. Up until beta, there was no physics engine. And I don’t mean “Look at all the pretty boxes!” but rather “Code your own collision system with raycasts and distance checks”. Some people are still doing things that way because the physics engine can glitch out, and in some cases there simply isn’t another way to do it. For example there’s no generic collision event: there’s no function or behaviour to detect if a physics object has collided with another physics object. So in the above bullet example there’s no built-in event that triggers when the bullet hits another object. This means using a complicated system of raycasts or distance checks to make your own collision system. Some people have all of their enemies (for example) as children of a single object, and each bullet will check the distance from itself to every other enemy and check to see if it’s close enough to be considered a hit. If you think that’s a bit absurd, then you’re right – most authorware packages include simple events to detect collisions.

Of course this is still a beta product, so it’s not finished, but again when such fundamental things are missing, how could this be considered a beta? What concerns me is that the developer is already looking at implementing netplay code. We don’t have proper collision detection yet, why are you looking at that? The fact that you can make your own out of raycasts and distance checks for every object doesn’t mean it’s a good method. If this is a sign of things to come, then it makes me pretty concerned about the future of Craftstudio. It seems like things that should be basic, priority features are being pushed down the line for something like netplay which really doesn’t matter at this stage.

There’s another annoying part of the physics engine where objects with physical properties can’t easily be rotated. For a player controller in Unity, you have one object with a collision model (usually a capsule) which you can move around. In Craftstudio, you need one object that actually rotates and contains the player’s direction, and another which contains the physics collider and fetches its rotation data from the rotator object and actually does the movement. Why? Why does it have to be that complex?

Visual scripting is also a bit of a joke. While it supports most of the useful features of the API, there’s still a lot of things missing. But that’s not really the problem – the problem is that it’s just a more restrictive method of representing code as bricks. By that I mean it’s just a block that more or less follows the code version and requires you to plug in all these extra variables with far more effort than it’s worth. You’ll still be referring to the scripting guide constantly. It’s nowhere near as slick as something like Playmaker for Unity, or really any other visual scripting environment I’ve seen. There’s literally no reason to use it because it’s so remarkably close to just coding that you may as well just code. Not only do you get access to more features, but it’s far faster too. Yes, I know, not feature complete, it’s a beta, etc. I get that. But this is a more fundamental design issue – there’s no real benefit to visual scripting. It’s not easier, it’s not more intuitive, it’s just a pain to use.

With all that said, I think Craftstudio missed an opportunity to make things easier for people though when it comes to game development. A lot of the code looks and behaves remarkably similar to Unity.  Which sounds great for standardisation, but it begs the question of “Why not just use Unity?” You’d not only have a more powerful engine, but it also makes things much easier from a logic perspective, and it’s free (to a point, while Craftstudio won’t even let you test your own project without purchasing it). You’d already have events to detect collisions, and if you’re learning about transform and quaternion rotations and so on then you might as well just go with Unity anyway. Craftstudio doesn’t make any of this easier for you to accomplish. About all it does is make it easier to create and use content.

But again, it’s a beta…

That’s the truth. For all the complaining, it ignores the fact that this is a beta. It’s not complete. Even if it reaches 1.0 it probably won’t be complete. I recognise that, and that’s fine. New features are good. But what concerns me is that Craftstudio’s greatest claim is that it makes creating content easy. Which is fine, but that doesn’t make it particularly good as a game engine. The important parts – the logic, the scripting language, everything that goes into making actual gameplay – has some significant flaws and missing features which really should have stopped it from receiving a beta tag. You can make a game with this, but it’s a lot more effort than using Unity when it comes to actually making the game. It’ll be interesting to see how it develops until its “final” release, but for now if you’re going to invest the effort you might as well just pick up Unity.


Broadcast on this frequency...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s