Devlog: Replication

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.

Quite pleased I managed to get through all that without making the obvious “built to last” Bladerunner/Replicant joke.


Devlog: Making Pixels Glow

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



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 probably mean that every time I saw a screenshot of the game online 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

I’m dead excited. Hoping to have more to show soon. ;)

Devlog - 08.04.17

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 ExoOne 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 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, while 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. :D

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.


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 this, 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 (none of Neurino’s editors, for example, are even compiled into the release build).

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 stats 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 refactor 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 the rest out later.

I also discovered that it was possible to have a static library of C++ functions you could provide to Blueprints, 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. Debugging them is an absolute nightmare…

51Daedalus is giving a serious of lighting lectures 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. It’s good to be able to bounce stuff off other developers now and again.

Devlog - 17.03.17

The flip-side to blogging about my progress is that you get to see the occasions where I’ve not been massively productive. So I’m going to waffle on about what’s really had its hooks in me over the last couple of weeks…

Zelda: Breath of the Wild

Of course I bought a Nintendo Switch at launch!

I’ll probably find some time to talk about the device over on my personal blog, for it is perfect in many, many ways, but Zelda? Wow, what a game. “Not much” has been done since it came out and this week I basically gave up any pretence of getting work done. It’s been time very well spent…

During the middle part of Lumo’s development I completed Link Between Worlds. That was a bit of a double-edged sword at the time, as, naturally, I started to become influenced by what I was playing. I have pages of notes about things to do in “dungeons”, but Lumo wasn’t ever that sort of game. Overlaid systems design — things that work well across multiple rooms & outer-world based travel, for example — wouldn’t be introduced to the genre until the Pickford brother’s Equinox, and I was determined to stick as closely to the confines defined by Jon Ritman’s early work as possible, and then poke out in directions from there…

(Lumo would have been “better” if the scope was wider, but, honestly, that was never really the point.)

Because of this (and with the exception of the occasionally mooted “Lost Levels”) it’s been obvious since the start that any spiritual sequel to Lumo would move more toward Zelda’s dungeons and away from the bespoke, single room designs. Not because the genre necessarily dictates it — although it is a natural progression — but because it’s the thing I want to make. It’s the direction that I’d have taken it, back in the ‘90s. It’s also exactly the design pattern that Nintendo have moved away from…

Having grown up in the ’80s I’m a student of the Arcades, and I came of age with the SNES. Systems design is important. The best game mechanics are simple systems, confined by a set of rules, that are obscured from the player by the machine. Their rules may evolve, slowly, over time, but the player is always encouraged to explore these confines, to learn the rules, through play. Great games — for me — are not about story, or narrative (although these may work well to support an overall theme) but about sets of systems that encourage and allow for the player to create their own experiences. To make “stories” in their head. Some of these stories will be to mentally explain a system’s ruleset. Others will be entirely unique to the player, based on how they interpret and apply their ‘abillities’ through play.

I was lucky enough to work with teams that understood this — Crackdown and Fable spring to mind — but I’ll never forget one meeting, where the publisher’s large and expensive writing team tried to “fix” our proposals by spending several hours arguing over the feelings and motivations of the NPCs in the world. The player wasn’t even mentioned once. I fucking hate this about modern, predominantly western, AAA games, and I could explain it succinctly with an animated gif I saw on Twitter, that I stupidly didn’t save. It showed Lara Croft climbing up a cliff as a thunder storm raged, and then cut away to the same design, done in the style of an Atari VCS. Lara dodges a rock, lightning strikes, it looks and sounds amazing, she says something to herself (the player) … and the dot on the VCS moves right one space, before slowly continuing up, along its pre-determined path.

When I play games I just see the dot.

Zelda has several easily understood systems that are very robustly engineered. This has given Nintendo license to let the player explore them deeply, and not worry about too much about unintended consequences. If anything, I think they’re fully aware of some of the exploits and are happy for you to use them (the hidden Koroks give the game away), but how these are applied in the world, and more importantly, how Nintendo nudge you toward their uses, will be studied for quite a while. At least by me.

Probably the simplest example is cooking — something I never normally like in games — a self-determined means to buff (as well as heal), whose different ingredients are distributed over every region of the map. It’s only possible to uncover all the recipes through extended play, but that 20 minute break to cook everything you’ve foraged over the last couple of hours becomes an enjoyable, repeatable ritual. I’m 50 hours in and I’m still making new things, and more importantly, I still want to see what I can do with it. The world design backs up this system’s rules: There will always be something spicy growing halfway up a mountain. Melons grow in hot regions, and their watery content will cool you. The body parts of electric Krese can be made into an elixir that provides shock protection. It’s simple, easy to break down — trivial when you look at it — but the player groks it with very little conscious thought. Only one example of how to combine these things for a given end is provided, but it’s enough to explain that experimentation is key, so off you trot, try and shoot every animal, and cook everything you see. I’m reminded of Minecraft’s crafting table.

Another easy example is Link’s stamina. You can run, climb or cling onto your para-glider for a short-period of time via a button press, and a simple UI shows the drain on your stamina. But Breath of the Wild is an enormous world that requires exertion to explore. Even the short-cuts to travel — tame animals — require a certain level of stamina in order to bring them under your control. And you’re encouraged to ignore these limitations by cooking up elixirs that will replenish your stamina whenever you need it.

My first few hours were all about cheating this “artificial limitation”. Pockets full of potions, I was desperate to run to the horizon and climb everything I could see, which is entirely possible as soon as you leave the starting plateau. Can you imagine how much better World of Warcraft, or Guildwars 2 would be if you could climb ANY mountain you could see? And when you got to the top there’d be a hidden Korok, or a mini-boss, or even just a breakable rock containing a diamond, waiting for you? Vista after vista unfolds, reinforcing a sense of place, and by the end-game, when you’ve powered this system up, you’re no longer taking your time, mapping out a safe route up the mountain, but leaping and bounding to the top with barely a care in the world. It feels a bit Crackdown-y, and makes a compete fucking mockery of Assassin’s Creed. Stamina moves from a game-y limitation to something empowering in the space of a few hours. And you should see the horses I have now…

Combat stays closest to the old Zelda way of doing things (from an interaction point of view) but even that has been completely over-turned. The traditional Z-Lock, jumps and doges are there, but now with weapons that are breakable.

On the face of it, breakable weapons should be a design faux pas best left to the F2P market, but the way it’s been applied is entirely logical within the context of the rest of the world. Each region’s NPCs have different weapons, some many times stronger than others, and if you’re like me and you’ve Leeroy’d off into the distance, one hit kills will be rife. Disarmed NPCs will run to whatever is lying on the ground and use it to attack you (even their fallen comrades, in some cases), but this is exactly Nintendo’s expectation for the player: Pick up the weapons that you see lying around. You’re a scavenger, as well. Save your best ones for the larger foes, and use a branch for the pests. You can even sneak into a camp to steal enemy weapons before they see you, meaning any resulting fight will be comically one-sided. Simple, easily understood, but with the benefit of giving real meaning to some of the items you discover. (And if you have a favourite, keep hold of it, as you can repair it by letting an Octorock eat it!)

There’s example after example of how the rules for the player are applied — designed — with thought to the other interactive elements in the world. Even the mechanic for taming a horse can be used with other animals you find in the wild. Want to rock-up riding a glowing Stag, or a Bear? Well, you can. Experiment. Explore.

The areas I love most though, and the thing I’d steal in a heart-beat, are the Shrines. (Oddly enough, the closest thing to what I wanted to do, but couldn’t, with the rooms in Lumo…)

Shrines in BotW serve multiple purposes. They act as fast-travel waypoints. The Spirit Orbs you collect from them are the means to more hearts and stamina. They act as bespoke puzzle and combat arenas, replacing the monolithic dungeon designs of Zeldas-past. And for me, they became the biggest driver to explore the world, safe in the knowledge that if I could just get to that orange glow, I’d be able to return at some later point.

The shrines are often just one or two puzzle ideas, beautifully crafted, but on a grander scale than you’d get in previous Zelda dungeons. A 20–30 minute diversion, often toying with the physics engine, that serve to distil the sort of inventiveness we only see when the Nintendo’s design-team is firing on all cylinders. I absolutely fucking love them, and the way you can dip in-and-out of them as a break from whatever you’re doing, makes them a constant, compelling, distraction.

And perhaps that is Breath of the Wild’s greatest strength. Open world games have always tried to distract you, but at their core has been the constant nagging of NPCs, and the gentle redirection back onto the “Golden Path”. Fable 2 — OK, not an “open world” game in the sense of GTA — took it so far as to manifest the Golden Path in the world itself (!) but BotW just does not care. At no point do I feel the need to “do” the “game”. I’m allowed the freedom to explore anywhere, at any point, to make of my avatar what I want. And even when I do sit down with the express desire to get back onto the main-quest, I invariably end up doing something entirely different. Nearly every NPC in the game is intent on sending you off, away, from the Golden Path. The number of half finished sub-quests I have is insane and I justkeep uncovering more.

On one of these diversions I saw Farosh…

I spend the first few weeks of my design lectures trying to explain what a game mechanic is by breaking down “systems”. Why systems design and implementation is the real meat-and-potatoes of a great development team, not story or “ideas”. About how to communicate things in-world, without text, and why that’s more important than the things we explain to a player verbally. How you can reward styles of play through the simple placement of “secrets”, how the player’s experimentation and mastery of things provides them ownership over the experience. I’m constantly pulling from Nintendo’s back catalogue for examples of all this, but now I could pretty much re-write the entire course and just use Breath of the Wild. I’ve not even spoken here about the camera, the slate’s powers and how these manifest differently across the “world” and the “dungeons”. It all makes me a little breathless at times. :D

Personally, I think it takes monumental brass-balls to be as confident in what you’ve made as this, to let go, to let the player just be. Many, many aspects of BotW will be copied in the future (I’ll be nicking stuff), but this is a game I’m worried could only be made in Japan, and now Kojima is off, probably only by Nintendo. I cannot see any Western publisher funding the level of experimentation and iteration that’s required to design and implement these mechanics, this world, so robustly. To eschew business model (for the most part, DLC and Amiibos cough) and trust in quality. Certainly not on a scale as grand and as beautiful as this.

That’s a fucking shame, really, isn’t it?

Anyway, I’ve got that Friday feeling, and I’ve only one Divine Beast left to do.

Maybe a quick go before I get back to doing some real work. Next week…

Devlog - 08.03.17

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.


Click screenies to enbiggen.