Cultural learnings of Unreal 4 for the benefit of game development, again, this week. And I think I’ve got over the first hill…
One of the things I found odd about Unity when I was starting was its complete lack of structure. Unity, from a certain angle, is basically an API and a fairly extensible editor, with a collection of half-finished bits to support you. This ‘flexibility’ is touted as its big strength, but over time I’ve grown to see this as a bit of a weakness. Some of that I attribute to the complete mess some of my students have got into, but even during Lumo, I grew to resent the amount of basic stuff that I had to roll. Why is localisation not built into the string classes? Why do I need to write my own serialisation? Why do I need to roll my own state handling? I need to write my own Audio manager?! etc. etc.
Sure, some of this stuff is write-once and then amend for every game thereafter, and of course that’s no different to writing a game in C. But for anyone used to having something as basic as an outer while loop in charge of the game’s tick, a series of very loosely coupled components, initiated in a random order on load, means you have to be very careful about how you start the game and track state as you proceed through scenes. At some point, it’s going to bite you on the arse, or worse - as happened with Lumo more than once post alpha - a bump in editor version can lead to a re-serialisation of objects and a total re-order of your init. Race conditions can be subtle and hairy dragons…
UE4 is a total contrast in this respect. It has a very clear structure that it seems to expect you to work in. There’s a GameMode, that’s, well, kinda the game globals for state, but I’m using it to handle a bit more. Actors, Pawns, etc are possessed by controllers that may or may not be players. Spawning players is done in a quite prescriptive way. Cameras come with a lot of expected functionality baked in. Basically, everything I’ve touched is ready rolled for a game, and you override and extend to mould it all into shape. The flip side of that coin is working out how you’re expected to do things.
Initially I had everything for the player in a class derived from ACharacter, but that came with a lot of stuff I didn’t need. My players aren’t going to be walking about, and a lot of stuff will just be canned Anims and some simple collision detection, so I split that into a Player Controller and custom Pawn class. Now I’m working from the bare bones and can see what I’m doing.
Because I want Oh Snow to be local multiplayer I figured I better dive-in and work out how the hell you do that. There’s a very simple way to spawn a single player - it’s basically handled for you automatically if you set the base class for your player - but the only examples I could find for handling multiplayer were Blueprints. I wanted to do things in C++ and the docs were a little, er, sparse. I ended up guessing my way through and spent the better part of a day trying things to see what happened. As expected, it’s about 2 lines of code to get going (took a while to find them though), and then to my complete surprise I got split screen for free. Yup, just having two cameras spawn in flips everything to split screen (unless you toggle a bool) and spawning 4 players gives me four screens. Nice.
I think I’ve also found more of a sweet spot between Blueprints and classes. Rather than add a bunch of pre-existing components in the C++ constructor and then the reams of code to set their params, it’s easier to just derive my class from whatever, put in the functions I want, and then derive a Blueprint from the result. I can add components - cameras, animations, etc - to the blueprint and tweak everything in the editor to my hearts content. Less typing, less compiling. Fingers crossed.
I’m also super impressed with UE4’s import stuff. It automagically picks up the materials from Modo, so no setup on my part. Adding collision is amazingly simple. Merging a set of assets into a single static mesh can be done in-engine, so no bouncing backwards and forwards to the modeller. The animation setup is sooooo much nicer than mechanim. That whole side of things looks like it’s going to be big time saver compared to Unity.
All in all, a reasonably productive couple of days at the forge. I think I’ve got a bit more of a grip as to what UE’s doing, I’m in love with all the tools I’ve played with, and I’m quite close to the point where I can just try and make some gameplay.
I’m going to need to model some characters soon though…
I’ve had my head in Unreal, off and on, since the last post and I’m slowly starting to make head-way. As mentioned in the previous post, the Blueprint system was feeling like a grind, so I spent a week biting the bullet and just trying to get stuff going from the C++ side. This immediately gave me better results, and despite the iteration time being slower, I ended up getting a lot more done.
To that end, I’ve scrapped what I’ve been working on - mainly little tests, but I got as far as a half functioning endless runner - and created a clean project and pushed it to Github on Monday.
I had an idea about half-way through the development of Lumo for a little mobile game where you dragged around the view of a downhill ski slope, and the character twisted and turned to follow where the terrain was going. I figured this would work well, as you could essentially play it one-handed, and maybe you could extend it a bit further to add jumps and the odd trick without complicated the controls too much. It’s one of those little toy ideas that’s stuck in my head ever since, so I’m going to have a crack at making something similar as my first UE4 project. I say similar, as I’m not going to do it on mobile, at least not initially. For simplicity it’s probably better to start off with a PC game, and that also means I can go a little more Tony Hawks on it. The player will likely have a joypad…
Early days but I’ve been really impressed with UE4. The animation stuff - compared to Mecanim - is like mana from heaven. The code API is big, and more verbose than what I’ve been used to (C++ vs C#, natch) but it makes sense. And it works. And there’s proper debugging channels. And. And.
Going to be a while until I’m properly productive as I’m only working about 1.5 days a week on gamedev atm, but it’s nice to be chasing down another game. Even if it’s only a small one. Screenshots soon!
So, this is exciting. Linux Voice - easily my fav tech magazine - very kindly asked if I’d be interesting in writing a quick Dev Diary about Lumo. Obviously I jumped at the chance. Having grown up reading Zzap!64’s “Diary of a Game” series, from the likes of Andy Braybrook and Jeff Minter, this was too good an opportunity to miss. The LV team did a lovely job, ending up with a 6 page feature - including some of the early prototype screenshots - in this month’s issue. Massive thanks to Graham and the lads for that!
It’s taken a couple of weeks, but I’m definitely back in full-on ‘work mode’. Which is good, as it’s going to be a really busy few months ahead. I spent a couple of weeks in Modo messing around with tutorials and getting a feel for things, and I have to say I’m really happy with it. For some reason it just clicks in my head. I didn’t get to the character or rigging, but I did spend a long time messing around with a low poly look that I want to use for a possible prototype: Oh Snow!
I’ve also spent a week in UE4, messing about with Blueprints. There’s a lot to learn here and I’m already starting to feel that the Blueprint system isn’t for me. They’re not really much of a time saving as the workflow is labourious; drag pin, type the first few letters of the command, find box, drop box, hook up inputs/outputs, rinse repeat, so I could pretty much type what I wanted into Visual Studio and compile in the same time. I may have wasted all the work I’ve done, but it was a useful process to at least start to understand some of the jargon and API.
Nothing to show from that effort, so far, and I suspect it’ll take me a few days to start everything again with C++ classes.
Unfortunately it may be a while until I get back to UE4. My teaching schedule has been sorted and there’s a lot front-loaded between now and Xmas. This means I’ll be at the Uni two days a week. I’ve also signed up to a Finnish language course, which is another 2 days a week, meaning the bulk of my dev time is going to be evenings and on the train. Because of this, I’ve started re-writing my old 2D framework, as I have a bunch of ideas for simple, small games that I might be productive on. A lot’s been done on that over the last few days - mostly under the hood prep - but I have sprites. Enjoy the mesmerising, floating head of Kevin Toms.
I’ve been on holiday! I know, that’s not exciting, but it’s the first proper feet-on-the-table, sat around playing games in my pants, do-nothing break I’ve had for, oooh, a while. And it was good, thank you for asking!
Anyway, I’m back, and I’m going to try and be a bit more open about what I’m up to here, rather than just random tweets and Tumblr posts. I can’t promise how regular these devupdates will be, but I’ll aim for at least a couple a month.
This is the first week back in front of my Dev PC since Lumo shipped. Despite having a bunch of ideas for new projects, I’m easing myself back into work by completely replacing my tool chain.
Lumo was created with Unity. For the most part Unity did what I wanted but the 10% of work to take the build from a nearly finished game to a polished, commercial release was, well, painful. Very painful. Much more painful than it had any right to be given the maturity of the middleware and the number of people using it. By the end of the project I needed 3 different patch versions of Unity, (one for each of the skus that I was handling: PC, Mac & Linux) just to get around crash and rendering bugs. Not good. Don’t get me started on the hoops the chaps at JAW had to go through on the console side. I also shipped with a lot of awful looking bugs that just weren’t present in earlier builds, all of which were completely out of my control. Wand particles would render incorrectly, or jump around the world, some of the animation blending is broken in specific circumstances, UI elements will pick up and render garbage for a couple of frames, lighting is broken in a few of the mini-games, etc. etc. Things that most of you won’t notice, but feel like a knife to the heart every time I see them. Unity 5.3.x was an absolute shit-show, so I decided to drop it and move to Unreal 4. There’s not going to be much news on the new projects until I start getting my head into UE4 and learn the ropes, which is why I mention it now.
The other big change is on the art side. As you can tell from Lumo I’m a bit of a noob on the modelling side of things, but I spent enough time learning how to rig, animate, model & texture, that toward the end of the project I was happy enough to jump in and make the things I needed rather than search the Asset Store. Unfortunately I was doing all of this with 3DS Max, which is slow, expensive, crashes all the time, and had a 50/50 chance of actually exporting to an FBX file that Unity could use. I hated it.
After asking people far more knowledgeably than me about what I should use, I bought myself a copy of Modo. This week has been all about learning the ropes and I have to say, I immediately love it. The NES Joypad at the top of this post was the first thing to fall out of my monkeying around. Nothing too complicated - and yes, I know the DPad looks wrong - but I’m still pleased with the result.
Next week I’m going to be 100% focused on Modo. I need to make a character, rig and animate it, and then I can start looking at getting assets into UE4. (Note: I reserve the right to do anything I want, contents may be hot, may contain nuts).
Other stuff this week: Setting up Backblaze B2 for offsite backups of my NAS (I made a post about this on my personal blog) and finding things to stretch the new GTX1080 GPU I’ve pushed into my Dev PC.