Triple Eh?

Finally. I’ve got around to some game-play programming…

My natural instinct when approaching this is to getting busy building a finite state machine, the core of which can be shared over the AI in my game, and then start building some instances to see what I like and what I don’t.

UE4, unsurprisingly, is reasonably opinionated about how you should approach this and has its own system: Behaviour Trees. I’ve seen the BT system mentioned by quite a few devs over the last couple of months, and read bits and pieces about how to use it prior to rolling up my sleeves. I was quite excited to jump-in, but over the course of the last ten days I think I’ve gone through at least half of the seven stages of grief just trying to find a way of working with it that I can live with…

One reason for this — and the thing that consistently annoys me about learning modern tools — is the absolute piss-poor state of documentation. I will never understand why people think scrubbing through hours of video is better than concise, written explanations of something, but there you go. Good technical documentation is a dying breed.

The BT system does do slightly better than expected in this regard, as there’s a relatively skinny HOWTO that walks you through the basics, but A) It’s blueprint orientated and B) AI also has to drive animation, and audio, and oh-my-god-stuff-needs-to-be-replicated-and-why-the-fuck-isn’t-this-working-what-the-fuck-simple-thing-have-I-missed-now *sob*. Etc.

Ok, I’m slightly exaggerating, but after a day of use my initial impression of the whole thing was that it was a teensy bit over engineered. Not designed for me. And I didn’t like it.

I’ve slightly changed my mind since…

—

My simple starter AI character has a few states:

Idle

Idle at attention

Patrolling

Trying to get close to the Player

Leeroy Jenkins

Looking for a player that it’s just lost sight of

Some of this information needs to be passed to the animation blueprint (being at attention, for example, or aiming at something) so the correct set of animations get played. Some of this information needs to be replicated, so clients see the correct thing.

A Behaviour Tree’s Blackboard is basically designed to support this, being a slightly decoupled place to store data that a BT uses to make decisions, and that the rest of your code can then modify & grab, as required. But that means touch-points in multiple places; the character blueprint, custom events to populate the animation blueprint, the AI Controller… in addition to the things that make the BT tick: the functions that make decisions and the services that perform checks.

I really don’t like this. Debugging this stuff is a fucking nightmare. You end up with windows and breakpoints everywhere, and the relevant data is spread too far. I like my parameters in one place and I like to be able to quickly read state at runtime, preferably in one place, so my first foray into this wonderful world (using blueprints only) gave me the heebie jeebies, and worse, didn’t end up working correctly. I have no idea why.

By this point I’ve gone through the first three stages of grief, although mostly “Anger and Frustration”. So I decided in the “Depression” stage to have a go at a pure C++ AI, and check out what else the engine had to offer. This lead me to the AI Perception system, which on paper looks great: Sight, Sound, Damage and Touch events for your AI, just by adding a simple component. Woo! And at least half of that system works! The rest, largely undocumented, doesn’t appear to, but it’s labelled WIP so this is either my fault, or there’s some arcane magic that I’m missing.

After an hour I really couldn’t be arsed stepping through the code to work out which, so I reverted back to the old Pawn Sensing stuff. This clearly isn’t as good, and it doesn’t provide anywhere near as fancy debugging output (which I’m a sucker for) but it works, and I could move on.

After a day I had my FSM, a little AI dude, a derivation of the player weapons that the AI could use to kill me, and everything was working in co-op with a connected second player. Hurrah! Except that’s only the tip of the iceberg. This stuff only looks good, or becomes convincing, when the transitions between the states have some range of probability, a bit of variation, and reactions can be deferred a little. This means adding transitional states, which means FSMs in code quickly become unwieldy. Adding time delays to state changes also makes things harder to read…

I wasn’t excited about carrying this forward and then having to debug it at some point in the future, and I do want something a tiny bit more advanced that Doom’s AI, so on reflection, straight C++ didn’t seem like the best bet either.

The upward turn (grief stage 5, apparently) was when I worked out how to use BTs with C++. Even moving the tasks — operations in a BT that do something to the character or it’s data — to C++ is a massive win. I can debug my character, my controller and individual AI tasks within Visual Studio, with a decent call-stack and inspector, and use the BT to add in all the little random waits, variations, or sub-routes, without clogging up the code. Things immediately started looking better.

Behaviour Trees also make the Environment Query System a tad easier to use and it seems like something that’s potentially cool, but I’ll be honest, I’m still on the up-hill climb with this. Have a look for yourself.

Spot the system written by a coder, for a coder.

So far I’ve been able to use the EQS to generate random places to look for a player when the AI loses them, and random locations around the player, so the AI isn’t a stationary target when engaging. But I need to spend more time to actually understand how to use this system properly. Having the AI run for cover, or flank the player, would be cool and eminently doable.

So where am I now?

Well, the header image shows the BT I ended up with after all of this experimentation. One thing that’s abundantly clear is that using a BT to sense and make state decisions dynamically, each frame, isn’t the way to go. The stack of conditionals you end up with prior to running sequences and progressing down the tree is messy, and still not fun to debug. I’m going to re-do this next week, but with a stored “current state” that pulls from an enumerated list in the Blackboard. I’ll combine the pawn-sensing, via the AI controller, with the simple tests in the BT to change state at given circumstances, and write a small set of methods in the AI controller to set the animation params, replicate, and /or call multicast stuff for clients.

I think this will reduce the surface area for debugging, make the BT itself a bit cleaner, and leave me with a small collection of C++ BT Tasks that I can re-use.

What I know about animation you could happily fit on the back of a postage stamp. I purposefully dodged it when making Lumo — through a cunning lack of in-game NPC characters — but I have vivid memories of swearing in 3DS Max for a couple of weeks, while trying to learn how to rig, then skin, what characters I did have. It was horrible, and the end result looks shite.

Fortunately, you don’t get particularly close to the characters in Lumo, otherwise you’d notice lots of silly little folds and polygon creases where the skinning isn’t quite right. There’s one very obvious issue that’s visible in the close-up cut-scene, when you collect the wand, and it still annoys the shit out of me to this day.

Anyway, that’s a long way of saying that, eek, I’m skinning / rigging the first character for Next Game. This time with Modo.

As I’d not bothered adding any animation controls before, I figure it was time to do things “properly”, especially as the characters in Next Game will be much more in your face. There are some really nice tutorials on Plural Sight, which got me over the hump with this, but it’s still a long, incredibly boring process, that I’m ashamed to admit took me the better part of a week. It’s stupidly easy to get distracted when you’re just fiddling about with vert weights…

But I have something that resembles an animation rig:

Once you get there, animating things is actually a lot of fun. I do really enjoy the process and I’ve got a new found respect for the people that do this well. Modo’s whole animation process — like the rest of the software — just fits my head, so it’s actually nice to sit there and tweak things, with the added bonus that the export process into UE4 is flawless, which is more than I can say for Max into Mecanim…

One thing I love about animating in Modo is the Actions. These are short animation clips that are tucked away behind a little drop down menu. With Max I ended up with a timeline full of different animations, or multiple copies of the character, each with a different animation on. Now I have everything at my finger tips, and I can cut-and-paste bits between different animations. It’s clean, and it’s tidy, and it works. And when I export a single FBX, UE4 takes each Action and makes a single Animation Clip out of it. Each of these can be re-imported singularly, meaning iteration times are nice and short. Big thumbs up.

After another week of fiddling, I ended up with this:

I’ve never done a “proper” walk (or run) cycle before, so I’m pretty happy with those. There’re not perfect, for a start there’s not enough follow-through, or looseness, in the hands and arms. Particularly in the run cycle. I think that’s a result of me using an IK chain on those limbs, which limited my ability to control the elbow angle at certain points. It was fiddly to make sure the swing stayed in a clean arc as the body moved up and down, as well, so with hindsight, I don’t think I’ll use IK on the arms in future. Everything else, though? Not baaaaaad, 7/10.

I’ve spent the rest of this week preparing to develop the character AI. I’ve created a new Game Mode for the co-op campaign, and I’m halfway through building an open space for the AI to run around in (see the screenshot at the top of this page).

First week back on Next Game, for oooh, a few weeks, and time to tackle the networking side of things. I had an inkling that retro-fitting multiplayer into the work I’d already done would be a bit of a ball-ache, but I was wrong. It was a massive fucking pain in the hairy-tits.

The problem wasn’t so much that I didn’t understand the theory behind it all — although it does take a while to bed-in, and in all honesty Epic could really do with providing some better documentation on the C++ side of things — but that switching something simple, like the character responses to items being picked up, involves changing a lot of small bits of code in various classes. So where, sensibly, do you start?

I tried a couple of things, first the pickups, then the weapons, but half-way through each it was clear that I’d basically have to refactor a whole bunch of supporting code. Admittedly, there’re some easy wins with the default replication that’s built into the engine; things move, things spawn and you can feel good about your progress quite quickly. But the devil’s in the detail. Do things destroy themselves correctly for client and server, when either side triggers the event? Are modifications happening on the server instance and replicating correctly? Should this multi-cast or is there a better way?

And obviously, debugging this stuff isn’t fun when you have multiple copies of the same instance running, and try to breakpoint something.

I spent four days poking about at this, and although I’d made pretty reasonable progress there were bugs, little fiddly fucks that I really didn’t want to carry along with me. So yesterday I started a clean project and wrote a very simple Team Deathmatch game. Even re-built the characters from the ground up, this time using the Animation Starter Kit from the UE4 Marketplace.

That’s not a particularly exciting screenshot, but it’s 8 players in a TDM game mode, with a dedicated server. Players automatically join and leave teams and you can run around and kill each other.

If you’d told me a week ago that I’d effectively be starting from scratch to get this working I’d have given you the sad panda eyes, but now I’m on the other-side I’m happy. It was a good thing to do. I’m pretty confident I’m entering and exiting the game mode properly, I’m going through the login process and I’m cleaning transferring Player States and Controllers about. None of that was working 100% properly in the previous branch. And, I still have all the “old” code lying about. The HUDs, menus etc will “just work” when I drop them back in, and under the hood it’s going to be easier to migrate things over, piece-by-piece, test, and then move forward.

So, lesson of the week — and worse, something I knew anyway — if you’re making a networked game, do it from the beginning, don’t try and bolt it on afterwards.

Easter and consultancy work have got in the way a bit, but the side project’s taken a big step forward…

Neutrino

When I last wrote Neutrino was rendering directly to the screen, which wasn’t exactly the look I was after for low resolution, pixel-based games. So last week I took a day to sit down and finish off the rendering path, with the aim being to have some control over the process and get closer to a CRT “glow”.

I’ve ended up with a fairly standard process that you’ve probably read about before.

Stage 1: The background tile-map and all the sprites collected in the VBO during the current tick are rendered to a 480x270 pixel texture. I picked this size because it’s a quarter of a 1080p screen, so scales nicely to my 4k monitor, but isn’t too chunky as to leave pixels the size of my face on-screen.

Stage2: The texture generated in Stage 1 is then rendered to a second 480x270 texture, via a high-pass “filter”. Atm this filter checks for pixel luminance, rendering any pixel above a certain brightness as normal, and any below that level at some, definable, smaller multiple of itself. I could discard these failing pixels completely, but I found the effect looks nicer when there’s a ramp.

Stage3: The texture from stage 2 is blurred in two passes, once horizontally, and once vertically. The resolution of this can be defined at run-time, but I’ve found that I get good results by blurring the low resolution texture from stage 2, and then getting the benefits of bi-linear filtering as I draw the blurred result, enlarged, as part of the final composite

Stage4: I draw a single full-screen quad to the screen, using the low resolution texture from stage 1. This is rendered with a trivially simple “scanline” shader, that checks the output position of the pixel: Every other line is rendered “dark”, for the scanlines. For “normal” lines, the shader checks the pixel, rendering the 1st biased to red, the 2nd biased to green, the 3rd biased to blue and the 4th “dark”. After this, the same quad is re-drawn, but using the blurred textured from pass 4, and again, I have controls for how much this bloomed texture contributes...

This is probably the simplest form of scanline effect. It’s not emulating PAL, or NTSC screens. There’s no phosphor persistence — although I probably will add that in, to a degree, by using the blurred “bloom” texture as an accumulator — and there is no barrel shifter to simulate the curve of an old screen.

I did look at Tim Lottes CRT pixel shader but it needs a fair amount of tweaking to run well on my X1’s Intel GPU. And there’s also Kyle Pittman’s shader from Super Win The Game, which I also discounted.

To be honest, I’m not going for either of these looks. All I actually care about is the feel of staring into an arcade, in a dark room, where those white pixels were too white, and where certain colours left a bit of a tint on your eyeball. The screenshot at the top of the page is a fairly toned down example of where I’ll end up, cos, If I crank some of the settings up, I can get to some pretty mad places.

All of this will be optional for the player. I know some people hate scanlines — why emulate broken technology? — but I’ll probably setup a few different presets to pick and choose from, so those of us of a certain vintage feel a bit more at home.

(I’d be tempted to leave all the settings available, but that’d mean that every time I saw a screenshot of the game it’d be at some crazy-bastard setting, that I hate…)

Possible todo items: Adding some saturation controls to this may be handy. And maybe a colour look-up table, so I can set curves in Affinty Photo and have them baked into the final output?

Next Game

Zelda has been pushed to the back-burner, I’ve been to the UK for a trade show, and started up a new consultancy gig. Even found some time to do some programming…

Eurogamer: Rezzed

I’ve not been to Rezzed in four or five years, but I can safely say that it’s my favourite “trade” show. It’s far more chill than the Expo, and there are plenty of opportunities to catch up with Developers, ask them techie questions, and get the shizz on who’s getting published by whom, and where the funding’s at. Eurogamer also do a good range of panel discussions, which are great to watch, and what with it being in central London, getting ruinously drunk in the evening is entirely possible.

It’s hard to pick stand-outs at shows like these, but Exo One and Tokyo 42 were the two that got me, and were by far the best looking Unity developed games at the show. I know it doesn’t matter what engine a game is written in, but having spent 2 days walking around it was incredibly obvious — for the most part — who was using what. Unity on the Nintendo Switch was looking rough as balls (Overcooked was running at 15–20fps at points) and there were many many tales of people having the same problems as I had, when shipping Lumo. So I did leave the show thinking that I’d made the right choice moving to UE4, and Epic having a large presence at the venue definitely didn’t hurt that.

And if Snake Pass really was ported to Switch in a week, well, I’m looking forward to begging Nintendo for some Devkits toward the end of the year… :D

I didn’t show anything, or talk to publishers this time around. It was just nice to go to a show with no pressure and mooch around.

(My Zub t-shirt had its first public airing…)

New Gig

I’ve picked up some consultancy work with a start-up in Helsinki. Can’t say much about it atm, but that’s one or two days a week helping them get going with their project. It’s time away from doing my own stuff, but extra cash in the bank is never a bad thing, and I’m working in an area I’ve not really touched before, so a few things to learn.

Neutrino

You’d think with all the planes and trains I’ve been on this month I’d have done more, but it turns out that in my excitement at getting exit row seats on the plane, I forgot that no bags are allowed to be stashed and the table barely holds a cup, let alone my laptop. But I did manage to do a few things.

I’ve put in the various game states so Neutrino moves through the splash-screen, “main menu”, and into a test level, and finished off the saving of tilemaps to a binary file. I can load these, and I can create a static VBO that holds the tile-data. But I’ve not quite got it all hooked up so the level is being displayed. That’s the next job.

Most games have several versions, Debug and Release being the most common. Normally these will do slightly different things: Debug will have more integrity checks, print-out more logging information, and may even contain different “modes”.

Release, as the name suggests, is normally what gets shipped to the players. ‘

To date I’ve only ever been working in Debug builds, so I thought it was about time that I checked out how the release build was getting on… And the good news is, excellently! I’d made a couple of mistakes with some #ifdef wrapping, but once fixed, Release was up and running in a couple of minutes.

I’m mildly surprised about that.

Next Game

Work’s been a bit stop/start, but quite a lot’s been done. The bulk of the effort has been working on the game-flow: at launch the game presents a little splash-screen with the company logo on, which nicely fades into the main menu. From there, you can jump into the first level, or quit out to the desktop. In-game it’s now possible to pause (in single player) and the level’s exit teleporters will take control away from the player and present an end-of-level statistics screen, showing score, items collected, time taken and any bonuses earned, etc.

This was a good exercise and I uncovered a few things: for a start, I’m still not using the various game and player state classes correctly. Things like the inventory are currently in my Player Controller, and should be in the Player State class. Level pick-ups and secrets aren’t being tracked in the Game State class, but by the player or individually. All of this comes back to UE4 being opinionated about how to structure the game, and I’m still learning that stuff. What I have “works”, but will be completely broken in a networked game.

I’m at the point now — having basically got my head around how to do the single player stuff — that I’m going to re-factor the bits I’ve got wrong and then make a start on the network replication. I’ve no idea how to handle the lobby system, or picking game-modes, but if I can get the players, weapons, projectiles and pick-ups replicating, that puts me in a good position to then start on the AI. I can work out the rest later.

I also discovered that it was possible to have a static library of C++ functions that you could provide to Blueprints as a kind of library, but despite this working well for a few days it eventually started to give me build errors, complaining that things were compiled with out-of-date outers (or something). I’ve no idea what this meant, and I’m starting to become more and more distrustful of Blueprints in general. They’re ok for little throw-away things, but even doing the UI flow in them was tedious, especially when you’re waiting for things to animate. Debugging them is an absolute nightmare…

—

51Daedalus is giving a serious of UE4 lighting walk-throughs, over on his You Tube channel. I can highly recommend these as I’ve learned a lot from the few hours he’s already done, including a lovely little trick for faking volumetric light areas (which I’ve nicked and slapped all over my test level).

I think lit particles and these sorts of faked volumetric tricks are going to be really important in Next Game. Some of the best looking stuff at Rezzed was doing of a lot of this for atmosphere, so it’s something I’m really keen to try and learn.

Also, a shout out to the Unofficial Unreal Discord Community: Unreal Slackers. I’ve been able to get a few questions answered, and people seem nice and friendly.

Early update, this time, as I’m off to the UK for a wedding. Because of that – and because I’m meeting up with a friend who’s helping me with some concept art – it’s been a race-to-make-a-face since my last post.

Next Game

The second iteration of the test level is basically done. As I said, it’s super chunky and super low-poly, but it looks a lot better than my first iteration. And I can get very dark areas, as well as very light areas. Pretty important for a Quake-a-like.

Although this scene is essentially outdoor, I don’t actually think I’ll do that in many of the levels. My plan for most of it is to do something darker and not as well lit, but for the purposes of a test I just wanted to see if I could do both. So I’ve aped a bit of the Quake 1 start thing, and done an imaginary “intro” level.

There’s a lot wrong with it; the scale is on the, er, large side – but the minute you start rocket jumping that’s less of a problem – there’s a lack of secondary motion – wibbly grass, lights swaying, stuff like that – and hardly any props to dress the scene. Although the colours work for me, a bit more detail would definitely help.

I’m not too bothered about all this atm, the main function of the test was to find a workflow that’s quick enough to let me bang out [reasonably] good looking geometry, and the lack of texturing definitely helps that. I’ve gone from zero to a level I can run around, in 8 days. And half that time’s been trying to understand lighting. Nearly all the missing things will happen over time and I can dress the scenes with more props as and when I make them. It’s how I worked the environment in Lumo.

I’m still toying with the idea of bevelling the larger geometry pieces as the extra edges would play in the light. Nintendo do this all the time in Mario and Zelda, so it might be worth a test…

Anyway. After the mild depression at going down the wrong path and throwing out a couple of week’s work, this whole exercise turned out to be super useful. The untextured “matte” look forced me to work out how the baked lighting is applied, especially when the various shadow schemes are thrown into the mix. There’s no where to hide so setting this up was a lot of trial and error, not helped by the fact that my lighting build-quality was set to “preview” for God knows how long. That flushed out lots of stupid things, but derp. Fucking idiot, etc.

The Modo side of things has been great, although it took me a long time to uvunwrap for clean bakes. Initially I was just ignoring it, letting the UE importer generate the lightmaps and then wondering why I had dirty big splotches everywhere. Then I started adding a second UV channel in the model to mitigate, which gives some control over how the model parts are split. But the real-trick, which it took me a couple of days to clock-on to, is making sure edges/verts are clamped to texel boundaries. In Modo this is trivial, you can set the UVGrid to 1/64, and then use the snapping tool to make sure that edges/verts are all nice and clean. It’s a bit handraulic, but if done right, a one shot deal. I think.

I still have some light-bleeding in parts of the level, but this is either where I’ve not added an edge to the wall (one model) where it meets the floors (a different model), or have a polygon that extrudes through the wall, so catches the light and the dark. The second issue is just me not knowing what I was doing at the start and then being too lazy to go back in and fix it. You can see it on the window frames.

I’ve also had a good play around with Cascade, and although I don’t feel as confident with it as Unity’s particle system, I’m able to do the basics. The same can be pretty much said for the material editor. I’m hoping to pick stuff up via osmosis and concentrate on the big things for the foreseeable.

Code-wise, I don’t think I’ve had any problems. I’ve even started doing a few things – the on screen messages for example – in Blueprints. Quick and dirty is, as Quick and Dirty does, and all that.

I’ve stuck a little video of all this up on You Tube. It should go without saying that the Quake 1 sound effects won’t be there for long, and everything is liable to change. 

It’s heading in the right direction, though.

(Cross posted from https://triple.aye.net) 

Oops, I missed a week and the devlog is late. Sorry! Game Dev and all that. Shipping late’s what we do…

I put off posting as I was hopeful that I’d have something nice to show, but things haven’t quite worked out as planned:

Next Game

I added a damage effect – the “damage beans” – on the screen edges to indicate that the player’s been hurt. It’s a simple post-process overlay, but with a normal map added you get a nice distortion of the screen as it fades in and out. Standard stuff for the most part. Except I have two versions, one that’s a blood-splat, and one that’s a nice high-res picture of actual baked beans. :D

I’ve also had a quick play with the audio system in UE4. My natural inclination is to integrate FMOD, but I’m hearing from fellow developers on Mastodon that UE4’s system is pretty good, and from the quick tests it might well be. Audio attenuation and geometry occlusion definite seem to work, which could be enough for what I need.

But for the last 10 days or so I’ve been playing around with look and feel tests.

This skybox got me into a lot of trouble.

My intention with Next Game is to do everything quite low-poly and avoid as much texturing as possible. One reason for that is to look different, but texturing and modelling take time, and time/money aren’t something that I have a lot of. If I have to get into texturing then I’d probably go for something old-school, like Gibhard or Strafe, but for obvious reasons I’d like to avoid that. I think every man and his dog will be doing that style in a year or two…

Unfortunately having a super realistic skybox lead me down a path where geometry got a bit too complex, and things rapidly looked incongruous when flat-shaded with high quality lighting. Basically, I couldn’t get it to look good unless it was extremely high-contrast. Which was unplayable. Although, I did spend a day flirting with an entirely black-and-white grading that I might go back to for some levels.

Anyway, I’ve thrown away all that work. All the geometry modelled so far, the test level, the greybox, all the materials and all the textures. That stung a bit.

This week I started again, but from a better footing: I chose a nice, harmonious, palette, and put a simple gradient in the sky-box. The palette is very limited: four base colours, four shades of each colour, and a gradient from top to bottom of each colour. I will most likely add to that over time, but for now this is working well.

UV-unwrapping can be done extremely quickly. Anything single colour can just be atlas unwrapped and pushed over the appropriate shade in the texture, while things with gradients just need a little more attention to align them properly over the gradient. Because the palette is fixed, everything sits in the scene, and with some lightmass settings tweaked I’m getting really rich colour gradients, colour bounces being picked up and deep shadows. It looks better, basically. It’s also super colourful, to the point of being cartoony – far too much for this game – but I find it easier to turn everything up to 11 and then slowly dial it in over time. (Early screenshots of Lumo are practically black because I was shooting for a Scooby-Doo vibe. The final game looks nothing like it…)

What needs sorting out now is the correct scale for things. My character moves extremely quickly, and rocket jumps go for miles. This will take a bit of two-and-fro, but that’s next week’s mission. At the minute everything’s a little too big but I find it quite endearing. 

Iterate, iterate.

Neutrino

Still train-coding my way through this and the big news is, the tile map editor that I said I’d never write is basically done. It’s missing the ability to create re-usable brushes from placed tiles, so I might go back and add that at some point, but bar some tidying up and deciding on the save format it’s doing what I’ll need. This throw up a couple of interesting things.

I was about to delve into the murk of C’s directory and file-handling, which is annoyingly different depending on the platform, but decided to have a quick search through Github to see what was already out there, and came across this little gem: Tinydir, works brilliantly.

While testing the tilemap editor I thought I’d throw in some massive numbers to see how it performed. Turns out things started crawling pretty quickly, which was er, a shock. After pushing it through Richard Mitton’s Very Sleepy the hot spot seemed to be in how I’m populating the VBOs, which again, was a bit of a surprise. This was supposed to be an optimised version of what I’d written a few years back on iOS…

For some reason I was only getting ~8k sprites per frame. I was expecting quite a few more. The culprit was this line:

mTransform = mTranslate * mRotation * mScale;

Pretty standard stuff, this is just creating the translation matrix which I’m pushing all my vertices through before copying the result into the VBO. (Yes, at some point I should just do all that into the shader…) I’ve done this before and had much better performance, except then I was using my own math class, and this time I’m using OpenGL Math. I figured it’d be better to pass off the optimisation and maintenance of my maths stuff to, well, people that know some maths.

So I dug into the operator * overload:

GLM_FUNC_QUALIFIER tmat4x4<T, P> operator*(tmat4x4<T, P> const & m1, tmat4x4<T, P> const & m2) { typename tmat4x4<T, P>::col_type const SrcA0 = m1[0]; typename tmat4x4<T, P>::col_type const SrcA1 = m1[1]; typename tmat4x4<T, P>::col_type const SrcA2 = m1[2]; typename tmat4x4<T, P>::col_type const SrcA3 = m1[3]; typename tmat4x4<T, P>::col_type const SrcB0 = m2[0]; typename tmat4x4<T, P>::col_type const SrcB1 = m2[1]; typename tmat4x4<T, P>::col_type const SrcB2 = m2[2]; typename tmat4x4<T, P>::col_type const SrcB3 = m2[3]; tmat4x4<T, P> Result(uninitialize); Result[0] = SrcA0 * SrcB0[0] + SrcA1 * SrcB0[1] + SrcA2 * SrcB0[2] + SrcA3 * SrcB0[3]; Result[1] = SrcA0 * SrcB1[0] + SrcA1 * SrcB1[1] + SrcA2 * SrcB1[2] + SrcA3 * SrcB1[3]; Result[2] = SrcA0 * SrcB2[0] + SrcA1 * SrcB2[1] + SrcA2 * SrcB2[2] + SrcA3 * SrcB2[3]; Result[3] = SrcA0 * SrcB3[0] + SrcA1 * SrcB3[1] + SrcA2 * SrcB3[2] + SrcA3 * SrcB3[3]; return Result; }

Ow. That’s creating a lot of vec4 variables over the course of a few thousand sprites.

I admit, I’m learning GLM as I go, and maybe there’re some functions to do mat4 multiplications in place but the docs make my nose bleed, and to be honest I couldn’t be arsed to trawl through it all.

So instead of using a glm::mat4, my matrix is now a simple array, allocated at the start of the function, that only contains the scale and rotation. I can push the sprite corners through this and add the translation, and remove a lot of obviously zero multiplications from the process.

vBL.x = (vBL_Pos->x * s_mTransMat[0]) + (vBL_Pos->y * s_mTransMat[1]) + vPos->x; vBL.y = (vBL_Pos->y * s_mTransMat[3]) + (vBL_Pos->y * s_mTransMat[4]) + vPos->y; vBL.z = vPos->z; etc. etc.

This is fine for 2D stuff, which is all I intend to use this engine for.

And the result? About a 15x speed-up. In fact, I get exactly the same number of sprites out of a single thread on my X1 laptop, as I do on my big fat devrig: ~150k @ 60fps.

I’ll probably look to multi-thread this once the physics engine and fmod have been integrated, but for now it’s more than good enough for a little shoot-em-up.

(Cross post from https://triple-aye.net)

It’s been a mad-cap couple of weeks. Here’s what I’ve been up to:

Lumo

Yesterday I pushed out version 1.17.2, to fix issues found with wireless Xbone pads running on Windows 7. Thanks go out to Patrick Hogan — the developer of InControl, a nice cross platform input library for Unity that I can recommend, available here — for sparing the time to test around the issue and provide a fix.

In addition to taking on the new version of InControl, I’ve also moved over to XInput, so — in theory — joypad support should be a little more robust on Windows going forward. (Crosses Fingers)

This build also fixes a possible bug with joypad “submit” actions not being registered by the pause screen UI, as well as turning off Unity’s bullshit “automatic” navigation option on some of the button layouts. Honestly, fuck that UI system.

Neutrino

I’ve been doing a bit of train / weekend coding, so this has moved forward:

Finished off the Input system. You can now poll mouse and up to four joypads. Previously it only handled attach/dettach events.

Added some keystate handling for specific inputs in editor modes (keyboard shortcuts, basically)

Added a bunch of helper functions to quickly get sprites from texture pages

Got the Tile Map editor to the point where you can select and place tiles, freely, or snapped to a grid

Next job is to store that in something I can spit out and reload that’ll be the basis of the level data. I’ll probably do a very thin Command pattern wrapper over this so I can support unlimited Undo/Redo as well.

Next Game

I’ve been all over the shop with this the last couple of weeks:

Finished off the weapon-types code and added weapon pickups

Player can now be killed, either through damage or falling out of the world

Player respawns properly

Added Ammo to the HUD

Added decals, and spent a morning drawing swears on walls

Added a new “Pain Room” to the test room, for traps and damage/stat tweaking

Dipped my toe into Cascade, UE4’s particle system, and made some effects for pickups

Started on a shotgun model for the first person view

Added some new models for the ammunition pickpus

The last item in that list has been my main diversion since the last post.

I know that I’m going to be doing a fair amount of modelling on this project so I’m still slowly schooling myself on workflows. For this, I decided to do some fairly high poly models of the pickup items and then bake them down to a low poly cage. Like everything, once I worked out how to do it, it’s reasonably straight forward, but it took a day or so to really get it working.

Building low poly cages seems to be a bit of an art, depending on the sorts of shapes you want, but after a lot of attempts I was able to bake AO and normals in Modo that looked pretty clean on the low poly asset, and came out clearly in-engine. I’m far from an expert at this, but it’s something I wanted to have in the toolbox even if I don’t use it very often.

I also spent a day or two messing about with Substance Painter. The “rent to own” model really appeals to me, as well as fitting in my budget, so I jumped on that. It’s a little unstable on my rig — I’ve had 4 or 5 really messy crashes — but when it’s working, it’s great. I doubt I’ll delve too deeply into the materials for this game, but anything that speeds up texturing is going to be worth the effort learning.

Now that Vine is dead I’ve started posting screenshots and little vids onto my Instagram account. You can keep an eye-out, here.

Bar teaching, the last two weeks have been entirely focused on Next Game, so I’ve managed to get quite a lot done.

Character movement is essentially ‘finished’. It’s pretty nippy - Quake 1 fast, in fact - but it feels nice and responsive, at least to me... Rocket Jumps will be featuring heavily, so spending the time to play around with this in order to get height and distance nailed, was essential. Changes from here-on will most likely be tiny number tweaks, so I’m at the point now where I feel safe to begin white-boxing levels.

The player’s inventory management is also working. You can cycle through weapons, pick up armour and health, as well as take damage. Armour modifiers still need to be added, but I know exactly how these will operate.

UE’s weapon and projectile systems took me a while to figure out, but I do now have 3 basic types that should cover most things:

Projectile based: rocket launcher / nail gun, stuff like that.

Instant shot: Pistols

Instant multi-shot: Shotguns.

Weapons have individual fire rates, can spawn splash damage areas and their damage can attenuate over distance. The only thing missing that you might expect - especially if you play something like COD - is projectile penetration. I’m toying with the idea of adding this, but right now my guess is that it’ll be pretty useless within the sort of levels that I intend to create.

None of the weapons have been properly setup atm, as that’s something I’ll do once some NPCs are in. I need moving targets to shoot at!

I’ve also had a crash course in the localisation system, configuring animation blueprints, playing audio and have dipped my toe into Cascade again.

For the most part the last two weeks have been really productive, but I’ve been badly burned by a couple of things. One of the worst was discovering that UE4 types get garbage-collected quite aggressively. If, say, you have a TArray of elements but don’t add the UPROPERTY() macro above their definition, then at some point they’ll disappear from under you. It took me a few hours to work out exactly what was causing the crash and why, as it was appearing fairly randomly - and taking the editor out with it - but like everything, it’s completely obvious once you spot it.

I’ve also learned the hard way that Play In Editor - PIE - masks a certain type of class initialisation bug. Stupidly, I had a set of FText variables defined outside the class (they were static char arrays at first) which compiled perfectly fine, and even ran in the editor, but cooked builds would immediately crash. It took me a couple of hours to realise that it wasn’t my Anti Virus, or some auto-build failure, but UE4 barfing when trying to initialise the variable before the engine had started up. This was happening before the splash screen was appearing, so I wasn’t even getting a log to help… Again, totally obvious once you spot it.

I probably lost a day bug hunting this stuff, so I’m a little behind where I wanted to be this week - ammo pickups are half done, and weapon pickups haven’t been started - but I’m basically at the point where I can play around with some look and feel tests, and maybe start white-boxing some spaces to run around in. I’m also growing in confidence with the engine and my ability to at least fix my own fuck-ups, so it’s probably a net win…

I’ve added a little video to my You Tube channel, for those who want a quick  peek. It should go without saying that none of the assets in this are final, or even likely to appear in-game. It’s made up of bits and bobs from Lumo and UE4’s example assets, that I’ve thrown together to get the code working. 

Although I did lose a good chunk of time over Xmas playing with the lighting and post, just to see how it worked ;D

Originally posted here: https://triple-aye.net

Happy New Year!

Apologies. The blog was on a temporary hiatus through December, as I had to prepare for a programming course that I’m due to give at TAMK University. That meant getting up-to-speed with the latest Unity version, and writing a simple game that’ll form the basis of the course. As well as having a Xmas Holiday.

But I did do some work and make some decisions. The first of which: Oh Snow! is canned. Probably forever. Why? Short answer; it was meant to be my toy project, not something that took a year to make, and due to teaching and signing up for a Finnish language course, I basically did nothing on it. But I did learn some Unreal, so it wasn’t a complete waste.

That means Next Game has officially been started. Here’s a little WIP screenie:

Yes, it’s an FPS. No, I’ve not done any graphics or modelling yet. And yes, that’s the default UE4 character model.

More info on Next Game in a later update.

Aside from that, Unity 5.5.x, and eating mince pies(+), I’ve done some more on Neutrino. The choice of using cmake for the build process turned out to be an excellent one. I thought I’d have a pop at getting the game running on windows, and although the cmake gui is a bit weird, once I worked out the intricacies it spat out a Visual Studio 2015 solution and Neutrino built and ran first time. And yeah, that surprised the hell out of me.

I’ve been continuing my love-in with ImGui, and decided that the effort to parse TileD tilemaps and integrate them into everything else I want to do was becoming a monumental pain in the arse. And I quite fancy rendering the tilemap through a pixel shader a little like this. So I’ve started writing a simple tilemap editor in-engine. Exactly what I said I wouldn’t do. Ahem.

Early doors. I’m at the point where I can click a tile and move it about.

Reposted from here. 

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.

Last part. For the full walkthrough check out the playlist: