Unity #30DayDev – So much to learn…

With the release of Unreal Engine 4 as a free development tool and the release of Unity 5, it seemed a good time to checkout both Unity 5 and UE4 as a comparison, using the #30DayDev process.

#30DayDev is a good way of setting yourself a time limit to see what can be achieved in the timescales and it gives a good indication as to how easy/difficult these environments are to develop with.

During the last 30 days, I set a goal of creating something tangible whilst studying Unity 5. Having enrolled on a Udemy course to follow at my own speed, I was impatient to implement what I was learning. So, as it’s quite simple, I decided to write an Arkanoid type game. Using an existing game is a great way as it gives you something to compare against to see how your progress is going. #30DayDev does not necessarily mean 30 consecutive days, but in this instance that’s exactly what I set. 30 days since I started looking at Unity in anger, this is where I am. Some days I managed a few hours of dev, and some days, nothing. But nonetheless, a fixed deadline day focuses your mind.

Unity Arkanoid Test


What I wanted was something playable. I figured I wouldn’t be getting the complete article, but thought I would at least be getting something tangible. So what did I learn?

Unity development is hard. I know people talk about getting prototypes and applications up and running quickly, but from the off, Unity is hard. There are many things that don’t seem intuitive, and Unity 5 has a habit of crashing every now and then.

This is the link to the web version of my #30DayDev attempt at Unity. Lots still to do, but you can see where it’s heading…

http://www.electricpixels.co.uk/wip/arkanoidtest.html

What did I manage to do?
I got a playable level going, with a rectangular set up of blocks. The rendering of this was done in such a way that changing the layout was pretty straightforward. I suppose this could be learning about how to render game objects at runtime. The ball trajectory and deflection is all done for you by Unity so long as it has a RigidBody so there was nothing to actually learn here.

Collisions – now they’re a different matter. I know people will say they’re easy enough to do, but understanding how they work, kinematic? triggers? yadda yadda and it does hurt your head after a while.

Rather than create the enemies using sprites like the original, I decided to implement 3D objects of a cube,capsule and a compound object and assign animations around these. It looks like you can’t do a collision between a 3d object and a 2d object, so I added a 2d collision box around the enemies to allow the ball to destroy them if they collided. During the collision phase, I removed the enemy and pinged the ball off in a random direction. As there is no gravity, the things just pings around until the end of time.

Animations – there’s another thing that’s not very intuitive. Once you create one, remembering where it is attached to and how to edit the thing. That’s where I seemed to spend most of my time this month, trying to figure out where animations and collision handling went.

Nothing around the animations feels intuitive at all. It all feels such hard work trying to create animations. It should be simple. Create an animation, and attach it to a prefab or object. If I wanted to edit it, I kept struggling as to where I needed to go, to retrieve it. For example, it seemed I couldn’t just double click on an “.anim” file to view the animation. I had to locate the instance it was attached to.

MonoDevelop is a great little environment, but again, numerous crashes and issues where it tried to load the project code twice and went off on one. It’s no WebStorm/IntelliJ or Visual Studio, but for a built in C# editor it’s ok.

I also managed to fit in one of the ‘pickups’ from the original game. Catch seemed to be the easiest, so this is what I did. Randomly on destruction of a brick, if required, it renders a pickup prefab at the same location as the brick.

At this point is where I found a strange behaviour. Creating a gameController object to manage the gameState, I though I could get the brick to call back to the gameController to create the pickup. This I could do, but for whatever reason, as soon as the ball then hit another brick, regardless of whether a new pickup capsule was to be created, the original one disappeared. Considering I was up against the time, the easiest thing was for the brick destroy process to create the pickup if required. Don’t like it at all, the gameController should be responsible for managing the extra objects. One for the future I think..

Score text
Can someone tell me what I am doing wrong around the score text? The text in the scene bears no resemblance to the actual location of the text during the game. Is it down to a scale factor with the canvas, as I couldn’t figure the pattern out? I’ve not needed to yet, but I’d hazard a guess that this will cause all sorts of rendering issues if I was to build for a different platform.

So to sum up, what have I learned…
2d games and 3d games in Unity are essentially the same.
The learning curve in Unity is steep.
Creating new game objects is easy enough.
Adding components is a breeze once you understand what you need.
Too many people talk as if you know what they’re on about, especially in the Unity docs.
Animations are difficult.

Positives
It’s ubiquitous, and everywhere. Learn this and it’ll go a long way towards game dev skills.
Very OO heavy, and it uses C#

Negatives
Not very UI intuitive in certain areas (animatons, collisions)
Overkill? For the kind of games I write, I’m seeing nothing yet that will convince me to ditch Phaser and move on.

I will continue with Unity development but I think it’ll be a while before anything substantial comes from it.

This entry was posted in #30daydev, Unity. Bookmark the permalink.

Leave a Reply

Your email address will not be published. Required fields are marked *