Devupdate - 13th October

UV Islands

I thought I’d do a quick update before I head out to the UK this weekend.

I’ve had a bit of fun this week. Neutrino moved forward for the first time in a long while. I’ve integrated ImGUI, a lovely header based widget library for games and other multi-media. This is one of those “where have you been all my life” bits of code, that slotted straight in and opened up a really simple, clean way to do debug output, windows, memory inspection and the like. So far I’ve only added some simple performance counters, but the plan is to use this to build up the internal editors for things like splines, particle effects and bullet patterns. I’m having a bit of a man crush on it…

Oh Snow’s also moving forward. The base character is done, skinned and rigged. I had to make a few tweaks since the last update, and today I sat down to try and get the UVing into shape. I’ve not used any of the UV tools in Modo before (can you spot a pattern here?) and to be perfectly honest, for Lumo I got away with everything being basically box mapped, so don’t really profess to even know the terminology. Every day’s a school day.

As ever, Modo’s been good to me. I made a lot of mistakes, and had to kinda stumble my way through the various options to work out what does what, but I finished today with a pretty clean set of UV islands, and what appears to be - to me at least - reasonable texel density.

All this highlighted some problems in my modelling workflow. As a lot of the geometry is mirrored, I could have saved myself a lot of time if I’d done a quick UV map on the model before I mirrored it. I’m wasting UV space for things that could be overlapping. I’m not sure if there’s a quick way to do this after the fact, other than manually line up the appropriate islands. I might need to ask around on that.

For this game it’s not really going to be a problem…

Also, I should have done the UVing before the skinning, as I noticed a few problems with a couple of quads that meant going back in to make some tweaks. Fortunately this is simple in Modo, but something to bear in mind in the future.

The paint tools in Modo turned out to be really useful for finding where my UV seams were causing problems, and really drove home how quickly things can look shit if there’s too much distortion in the quads. Today I found all this out after I thought I was ‘done’, so I scrapped everything (basically the whole day’s work) and started again. Once I vaguely knew what I was doing the whole process took less than an hour.

I’m having to stop myself from getting too stressed over the slow progress I’m making atm, and keep reminding myself that taking the hit now will pay off down the road. Learning Modo - and pretty much the entire art pipeline - is a pretty big task. Learning UE4 is also going to take a good long while. The fact is, I need these skills if I’m going to continue making games on my own, so it’s nice when I do finally crack something. Even if it takes all day… :)

So, next up: a quick pass on the texture, then some simple poses for test anims.

After I’ve recovered from a week in the UK! :D

This is scary...

Quick aside: I’ve been doing a bit of work on the side project this week - mainly on the train to and from my teaching classes - and I noticed something a bit worrying. For a while I’ve been wondering why my 2D framework for Neutrino appears to be pixel-fill limited on my laptop. Much more so than I expected. Jumping to 1080p in a window is enough to really hit the performance, so after integrating ImGUI I dug a little deeper and added some profilng.

It turns out that the engine isn’t as slow as I thought. Internally it was vsync’d to 60, but unbound could potentially hit ~1400fps. Visually, however, it was blatantly dropping frames. If anything, it looked sub Dirty Hz (30fps). Not good. So I tried glmark2 and it was showing the same problem, it’d report fps in the hundreds, but visually appear dog slow.

My laptop runs Ubuntu 16.04, and for the desktop environment I’ve been using the latest version of Cinnamon. I like it, it’s incredibly clean, good looking and does what I need. The other big plus is Nemo - the file manager - which is by far my favourite thing about it. Default split-pane views ftw! But, for whatever reason, I didn’t consider that my performance problems could be related to this.

On a whim I tested the game under Unity, and lo. A silky smooth, 60fps.

So yeah, even though Cinnamon claimed that it wasn’t running in SW rendering mode, for whatever reason, the window update wasn’t actually matching what I was outputting. Quite a big “Whoah” moment, and something I thought was worth sharing. Not all desktop environments are equal, and some aren’t good for games.

Real shame, as I can’t use Cinnamon while it’s exhibiting this kinda problem. Also doesn’t bode well for when I release something, but I’ll cross that bridge when I come to it.

Devupdate - 6th October

Character 1 WIP

After my last post I started work on a character model for the game. This is the first time I’ve ever modelled a character, and also the first time I’ve tried to do anything complicated that had any sort of predefined ‘style’ (low poly in this case, so nothing too strenuous).

As expected, even simple character modelling is non-trivial and I’ve discovered I have an amazing ability to be completely OCD on vert placements, so probably wasted hours just tweaking stuff when I shouldn’t have bothered.

The results aren’t amazing, but it was a good learning experience and it’ll do for now. It’s kinda close to what I had in my head, and hopefully the super deformed look will parse well enough on-screen. Fingers crossed!

I’m intending to make a bunch of different hairstyles, hats, goggles and other bits, that you’ll be able to pick and choose from. Probably as some sort of unlock/upgrade tree. None of that should be too tricky, but I’ll need to look into how attachments work out in UE4, or find a simple way to output the variants from Modo. With a few base models I’ll be able to do most of the variations with material swaps, so it shouldn’t be too bad, either way.

Character 1 WIP2

I had to rig and skin four characters for Lumo, all in Max, and each of them ended up taking one or two days to get right. I hated doing it and still live in fear of ever going back in there to fix something. That’s probably why I’ve been putting off doing any character work on this for the last few weeks, but today I dragged myself away from tweaking vert placements and sat down in front of some tutorial videos to get to grips with how the process works in Modo. And - so far - it’s been a really pleasant experience.

The rigging is nice and simple, taking less than 20 minutes, and the base vertex bindings the software produced is surprisingly close to what I need. I’ve probably got a few hours work left just to tweak the weights around the fingers and waist, but I’m pretty confident that this’ll be good to go before I leave for the UK next week.

Then it’ll be UV unwrapping, and producing some simple test animations to get him skiing.

Yet again, big props to Modo. It definitely fits with my head.

Devupdate - 23rd September


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…

Dev Update – 14th September

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!