Why I ended up on Unity after all

/0 Comments/in /by

So, I have this blog post saying I decided on Unreal Engine. Now I get to say I ended up going with Unity after all. Here are some of the reasons:

First, from my limited exposure to Unreal, I found the code-compile-test cycle to be frustratingly slow. Because of the nature of the game I’m building, there is a lot of code. Unreal has some great stuff going with blueprints, but that isn’t going to work for what I need. Maybe there is some trick to making it really quick and easy to go back and forth between code and test, but I didn’t see it.

Second, one of the first things I was trying to do was create the equivalent of a point cloud for the rendering of the items in the game. The few Unreal people I spoke with it about it seemed to indicate that there was no built in way to do that in Unreal and it would require customized rendering code. Maybe that’s just normal fare in Unreal. In the hands of an expert, maybe it would be an easy thing to do. But that brings me to the third point.

Third, it’s much easier to find Unity developers. There are so many Unity developers out there. I’m not building this all by myself, so getting the right kind of help is important to the overall project. With so many people available, there are many that are still not well qualified to go through, but I’ve been able to find the people to get the job done.

And maybe as a fourth item, I didn’t really want to deal with the percentage licensing scheme for Unreal. It seemed like it would be a nuisance.

So, that’s a summary of why we’re using Unity at the moment. We’ve made some great progress, and I’m really looking forward to making some game play videos in a week or two (I hope).

Choosing a Game Engine

/0 Comments/in /by

Last year, I posted in this blog last year that we would be building our game from scratch without using a game engine. For the situation I was in, it made sense. But sometimes life happens, and priorities change, and so part of the decision to refocus to Limbo also included the decision to use an existing game engine. Also, between then and now, there has been some big changes in the cost of the most popular game engines.

There are many options for game engines. When searching I found lists of 100 game engines. Based on googling around, there are 2 that seem to be the most discussed: Unity and Unreal Engine.

There have been some exciting things happening in the world of game engines over the past year. That’s very good for indie games in general, but it actually made it much more difficult to choose for me. When reading comparisons between the platforms, you have to be very careful about the date when it was written. Many things changed at different times last year and so statements could quickly become out of date.

I’m confident Quip Escape from Limbo could be built using either Unity or Unreal. The decision came down to some technical considerations similar to those that led me decide to build it from scratch earlier. We’re doing something different for the physics and control, so we’re still going to write all that directly in code. It made sense to me to do it in C++ rather than C#. Also, according to some people (it’s hard to judge for sure), Unreal would scale better than Unity. I have some very ambitious goals for future projects that will expand on what we’re doing now. Given these, I decided on going forward with Unreal.

The royalties model means more work handling the royalty payments. However, I am a very big fan of results-based rewards for any situation where it can make sense. If their software enables me to create a product that can have a lot more sales, they deserve more money. They have it set up that projects with little sales pay nothing at all. So, although a little nuisance, it’s quite in line with my principles.

When using a well known game engine, getting expert help with the development is more straightforward. That along with having detailed specs that are the result of a long year of thinking and rethinking, we’re more able to manage scope and timeline.

Physics and Control: Rotation

/0 Comments/in /by

Early on while working on this game (and the general platform concept) I had figured out a detailed set of keyboard shortcuts for camera management. It took about 30 seconds after implementing some of it to realize that for what I was trying to do, manual camera management had to go. I had to come up with an effective way of automating the camera so the user wouldn’t have to.

There’s the high level and low level of it. The high level is what algorithm to use to position and direct the camera. The general goal is “keep useful things in view and filling as much of the view as possible”. We’ve already been through two ideas for that and I expect we’ll be iterating further for it.

At the low level, I wanted even the camera to simulate proper physics. The position of the camera is straightforward. We can use the same position control we use for all the other items. Orientation was much more complicated. I wasn’t planning on implementing rotational control for items in the world (though, that could change), but for the camera, it’s required of course.

Representation of rotations is typically done using quaternions, which is what we’re using. Angular velocity and acceleration can be represented by vectors. We searched around trying to find control algorithms for rotations and couldn’t find anything. There’s SLERP and SQUAD but those are interpolations that by themselves don’t simulate physics.

In the end, I realized that the rotational case could be modeled just like the positional case. That one could decompose the angular velocity vector just like I had done with the translational velocity vector. Such that we can even reuse the exact same code that handles the 1D case. We’re running into the inaccuracy of floating point arithmetic, but we have this mostly working.

Physics and Control: Position

/0 Comments/in /by

One of the fun math challenges we have run into during development is for controlling items in space. I wanted all the items to use real physics modeling to move from place to place. Physical simulation is pretty standard, but control systems are more complex as they don’t just simulate, they have to generate/calculate a solution to a problem. Given an item with position and velocity, I need it to move over time to a new position and have a resulting velocity relative to some other item. I couldn’t find an existing algorithm to do that. There were some related things like docking spaceships, but that was much more complex than I needed. After some dead ends, I realized that modeling it with separate acceleration/deceleration phases, I could create an overall system of equations to solve. With some old school algebra and some extra trickiness to deal with the fact that we use discrete timesteps… and after a good bit of testing and tweaking, we got it to work very well.

One of the fun things I did in that “good bit of testing” was create a random tester. It would iterate through thousands of tests. Each iteration would generate random values for position, relative velocity, target position, maximum acceleration, and timestep. Then it would run through the control calculation and update the physics for each step. Within a maximum number of iterations, it would confirm that it arrived at the target position and velocity. Trying to come up with a representative set of tests for this manually would have taken a great deal more effort. We did start with some basic manual tests to make sure the very basics were working first, but this random tester gave us the confidence that the control algorithm would work correctly. And since all the more complex control algorithms such as formations will use this one, it was very important to make sure it was right when we’re troubleshooting the other ones.

Life is Better in Game Development

/0 Comments/in /by

This post is in response to the question: “Has developing video games made your life better?” I’ve been programming since I was too young to remember how old I was. I’ve been doing it professionally for a long time as well. A lot of that professional development has been in “corporate” settings including all the silly buzz words like SOA, middleware, n-tier, cloud, ajax, blah blah… But from a technical standpoint, it’s all pretty boring. Generally, these aren’t hard problems. In fact, in most cases, they come down to people problems. But… that’s a different topic. In short, the typical work of “corporate” developers is the intellectual equivalent of ditch digging. Game development, on the other hand, is amazing in the breadth and depth of challenges one can pursue. I don’t think there are many other projects that can involve: graph theory, control theory, physics, science, artificial intelligence, purpose built data structures, special effects rendering, parallelization, etc. and those are just the technical challenges. There’s also story telling, universe building, character development, philosophy, marketing… the list goes on and on. All this in one single project! It’s wonderful. Obviously not all game projects involve all those things, but they can. And mine does. The contrast is stark. It’s like going from black and white to vibrant color. So, yeah, life’s better here.