On last week’s episode of our Game Development Show, we played around with GameMaker’s D3D functionality to test the potential of the engine for handling 3D because Project Skyring would be a much stronger game if we could pull off a proper sense of height/altitude as opposed to going with a more retro solution. We continued to experiment with the engine after the show and got things working to some extent, but our final decision is: GameMaker’s D3D is not going to work for us.
There are a couple of reasons we came to that conclusion:
No Visual Editing System
All of GameMaker’s D3D functionality is in script, which means that if something goes wrong, there’s no way to visually check what the problem is. Although time would help us get used to the quirks of the D3D system, we don’t want to run into a situation similar to what we had when we first started experimenting with D3D, where we had no idea why certain objects weren’t showing up, or certain textures were on the wrong side of objects, etc. In Unity or Unreal, these problems are trivial to fix because there’s a visual 3D editor that shows the camera pointing in the wrong direction, textures on the wrong side of polygon surfaces, etc. But to hope that every time we run into a 3D problem, we’ll be able to properly dissect the script, even after the project has grown more complex is a bit too much of a risk for us. We could get into a situation where we spend months trying to fix a problem rather than adding game content, and that’s no good.
We don’t want to paint ourselves into a corner with technology where we can’t finish the game, or worse, can’t debug the game if something pops up later. Despite a few hiccups, we were satisfied with how easy it was to fix problems in GameMaker when it came to 2D, but we can tell already that 3D wouldn’t be the same experience. GameMaker wasn’t really designed for 3D, and trying to hammer a square peg into a round hole is guaranteed to be a source of headaches (and broken hammers) for us.
A Limited Model Importing System
By default, object models are a hassle to load into GameMaker because they have to be converted to GameMaker’s proprietary script format. There are ways to get OBJ files from Blender into GameMaker using Python, etc. but that just adds one more step to an already tenuous process. That being said, if you’re interested in importing models from Blender into GameMaker, this is where you should start.
So where does that leave us with Project Skyring? With four options:
1) Work in 2D
The easy option, of course, would be to just give up on the concept of 3D altitude altogether and make a top-down game or put a little more work into making a “use-your-imagination” Blue Max style game, where altitude is expressed purely through UI. (for those of you who never had a Commodore 64 and Blue Max, you can see a video of the game here, but it used a color bar to indicate your altitude; the concept worked, and the game was great, but the system wasn’t that intuitive, and having to keep track of the bar pulled your eyes away from the action).
2) Try a Fake 3D Solution
We really would like to keep using GameMaker because we’ve had success using it to create a fun game in a reasonable amount of time with just one game designer, and switching to a new engine entails risks (time spent learning, not knowing whether it will be possible to produce a game in a short amount of time, getting around a different pipeline, licensing costs, tool costs, etc.), but if we don’t go with a 2D solution, the only other choice is to jury rig our own fake 2D solution.
A jury-rigged solution contains its own risks: whether it can be done, what kind of bugs it’ll introduce, the difficulty of implementing things with a forced solution, a big delay before getting started making content, etc.
However, it’s not all negative; if we used a completely new approach to simulate a 3D space in 2D, it would give the game a very unique feel. Limitations are often the best source of new ideas, so the limitations of GameMaker could work to our advantage.
3) Switch to Unity
Our Unity skills are rusty, but we have made prototypes in the engine in the past, know it’s easy to use, and know it has a huge amount of support (the most support if you think of market share). That support translates into the best 3rd party tools, plenty of answers to questions on forums (the lack thereof is one of the things that turned us off of GameMaker D3D – so few people are using it, there isn’t a lot of information out there about how to work with it at anything higher than a prototype, look-what-I-made level).
The disadvantages to switching to Unity would be: the time it would take to scrape the rust off of our skills, setting up a new pipeline, the risk of not being able to complete a polished-looking game in a reasonable amount of time with just one game designer. And, one other risk with Unity is that, because so many people use it, making a game that feels different from everything else out there takes that much more work and a high degree of technical skill that we might not be able to pull off with a solo designer. Unity games have a definite “feel” to them that takes a load of work to polish away. We love how easy it is to get things working in Unity, but we’re not sure whether we can make a game we feel has the level of polish necessary to put it on the market with so little manpower.
Whether we go with Unity or not is going to come down to further testing. If we can use the 3D to prepare a solution to the altitude issue, while allowing us to stick to 2D asset creation and our original artistic vision, it could be the best fit for the project.
4) Switch to Unreal Engine 4
Unreal Engine has Paper 2D and is of course powerful. Best of all, it’s now free (well, until you make a lot of money with a game, which would be a happy problem to face).
While we have experience working in the engine, we have less experience in it than Unity, and there are several drawbacks we can spot from our limited experience: Blueprints make setting new features up very quick and the engine makes getting things working and looking good fast, but Blueprints also make debugging a nightmare. As debugging is where most of the time is spent and is arguably the most mission critical part of game development, this is a hefty drawback. The best solution to avoiding this drawback is to use Blueprints only to test new concepts, and then move the logic over to C/C++ when it doesn’t need to be fiddled with as much. Although we have enough experience programming in C/C++ to handle that chore if we needed to, any time spent converting Blueprints to code would be time not spent making the game. With a dedicated programmer on the team, we could move the things we don’t need to play with over to C/C++, but without one, we’d be stuck working with Blueprints right to the end.
That sums our choices up. Our past experience warns us away from 4), and we don’t want to give up on altitude by going with 1) unless we have no other choice, or the gameplay demands it, so at the moment, we’re waffling between options 2) and 3). Which one we end up going with really does come down to how far we can get with the two options, but whichever method we choose to go with, we don’t want to pour a lot of effort into 3D asset creation, because that would be a huge time sink that wouldn’t benefit the gameplay. The concept of altitude is important, but the actual gameplay doesn’t require 3D. So, if we go with Unity or Unreal, we would still be going for a 2D sprite aesthetic, even if we end up “pasting” those onto simpler/abstract 3D objects. We have a definite art style in our head, so now it’s just a matter of trying to bring that to life with prototypes.
As long as we’re undecided, we can’t really push the game forward, so we’d like to make our engine decision by the end of the month. Until then, we hope you stick with us as we go back and forth between the two options! Our first step on the next show is going to be testing the controls in 2D because it’ll help us wrap our minds around what actually feels good for the game.
Pingback: Game Development Show - Season 2, Episode 3 | Blue Tengu