Note: uses UE4.2, there were some issues with split-screen in earlier versions.

Step-by-step instructions for enabling split-screen

1.

And that's it.

Mostly. As long as your player object has a camera, this will all just magically work once you add another player either by placing another player in the UI or through adding one in BluePrints using CreatePlayer().

Problem modifying the second player

I hit a snag trying to act on the second player through BluePrints.I had created a Character-derived player class called Player_BP and set up the BluePrint graph for it so that when the "change colour" key-event fires, the material of the player mesh changes.I did this by clicking on the mesh from the components tab on the left of the graph view and dragging it into the BluePrint graph as a GET operation node, then used the Change Material node to change the material, simple enough.

This works great for the first player, but if you create a new character instance in the game of type Player_BP and have it react to the 2nd-player change-colour input, it still changes the colour of the first instance.

I thought I was creating a class with member variables, and that making a new instance would run that script on the new instance.This led me to investigate when variables are considered static, the document states that a variable is static unless:

Exposed as editable

Set to something using the SET node

This doesn't work as I expected, but I understand the reasoning. However, I didn't feel like exposing it as editable (making a new variable to do so?) or setting it manually using SET, so I manually got the second player character and modified the material like that.

(the first block shows how I first assumed it would work for all instances, the second block shows how I handled it afterwards to address each instance manually, using a for loop in my game, checking if the player is equal to NONE before trying to use it)

Level layout for two

Having finally got the colours of my players changing correctly I realised that I had one tiny flaw: I'm a moron and hadn't thought that they'd be sharing the same level, so when one player changed the colour of the platforms, it would change it for the second player too.While that could be chaotic fun, I don't think it would actually work.

Dismayed and on the point of giving up, I thought that I could simply make a clone of the platforms somewhere off screen from player 1, and make it a simple race to the top, but I really wanted the players to be able to see their competition on the same set of platforms as they were on.

Then I realised: I truly am an idiot. Mirror it! Simply flip the camera around 180 degrees when creating the second player, create double-layered platforms and BAM!

The picture above shows how I really do have double platforms and players on different Z-planes, as well as enlarged collision-boxes around the players so that they can collide with each other despite not being on the same Z-plane.I have several plans for reworking this so that it looks less like two separate levels stuck together.

Dealing with collisions

Disclaimer: I still don't really know what I'm doing with this. While I understand Box2D and Chipmunk collision groups and masks, this makes little sense to me.

So, I wanted to have the two players collide when they're the same colour, and pass through each other when opposing colours.

I guessed that I needed to change the group or mask or something of one of them when the user changed colours, but I couldn't find anything like a mask or group.There are Channels however. After struggling for a while to to understand creating and using custom channels, I simply went with the following hack.

Setting up the collision presets in the details tab of my player class so that pawns collide with pawns, makes sense, right?:

Adjusting the collision channels on the second player in BluePrints to set the collision response to Ignore if the players are different colours:

What this is

This is a quick walk-through of the chaotic process I went through in recreating my 8-hour jumping game in Unreal Engine 4 using BluePrints only.I gave myself 8 hours again, seeing as I had the logic down and "simply" needed to learn a new environment (this was my first time using Unreal Engine).

NOTE: I am an idiot, and as such sometimes enjoy jumping into things without reading any documentation simply because I love trying to figure things out on my own. I did through forums and AnswerHub and through Google, but I didn't sit down and read all the documentation.So I'm sure/guessing that the things I tripped on are in the documentation. I know I'm a bad person.

Things they (probably) don't tell you about input

When Unreal first announced the release of 4.0 I watched a few of their tutorial videos to get a feel of how easy things were to convince myself that I needed to purchase it.This meant I had seen some footage of assigning keypresses and joystick axis/buttons to events which you can easily act upon in BluePrints.

Armed with this randomly-chosen video tutorial knowledge that had aged in my brain for 2 months, I was ready to go!My first goal was to get a BluePrint event firing when I pressed the "left" key, so I created a new blank project without starter content and set off on a misadventure!

I flittered joyfully to the Edit->Project Settings->Input section...

...mapped the keys and hooked up the event in BluePrint...

...annnnd: nothing.I pushed the left arrow key and the camera moved left... fine, I guess I have to override that somewhere... let me just change the key to "N", that can't be mapped internally.

Nothing.Okaaay, a quick search on the net revealed the answer! You have to enable input for the object:

De nada. Ah, vale.Más la búsqueda... "Be sure that the input isn't being consumed", de acuerdo!(open graph, select OnKeyEvent node, the details pane on the left)

Still nothing. Okay. Getting annoyed now.The forums didn't seem to have an answer, searching quickly through the documentation didn't reveal anything either, and what's worse, video tutorials were showing me how insanely easy it was!"Let's open the sample project and re-map the keys", followed by the same stuff I was doing."Create a new sample project, BluePrint ThirdPerson", followed by the same stuff I was doing.

After randomly stabbing darkness with a blunt mouse cursor I finally discovered that you need to create a new BluePrint object derived from GameMode and set your project to use it.(Edit->Project Settings->Game->Maps and modes)

TL;DR;If you're starting a blank project without starter content, you need a "Game Mode" BluePrint object to get input.

Generating a very basic and ugly random level

Having spent more time on looking how to resolve input than I have dedicated to exercise this year I was finally on to getting something on the screen.I needed to generate platforms of random width that are randomly placed in an upwards direction. This part was easy!

Simply create a mesh that is 1x1 in size, create a BluePrint actor/pawn that uses it, then spawn new instances of it using a for-loop in BluePrint.

Adding the player

I added a new BluePrint and based it on the... Actor... Pawn, no... Character class... not sure.My jumping block is hardly a character, but I want it to react to player input which the tooltip hints is a PlayerController...I'll start with actor and work my way up...

First things first (oddly enough), I want a little cube that platforms throw into the air and that moves to the appropriate side when I hit an arrow key.It must also stop moving sideways instantly once I release the key.To do so, I'm going to need to set the velocity or add a force to the player, right.

Actor and Pawn both appear to have a function you can call to GetVelocity(), but there isn't a SetVelocity().Strange, but I generate several random conspiracies as to why that could be.

In the past when I've worked with physics engines, I've done something like "add force" or "add impulse".Searching for these did reveal that there is an "Add Impulse" you can apply to an actor, but BluePrints wasn't having any of it (later I would discover that you can cast the actor to a Primitive Component and do this).

I also didn't want to have to take their old position, work out where the should be with the new velocity, and then call SetActorLocation(), because then I may as well not even use the physics engine.

Through some lucky distraction in looking through answers online, I saw that there is a function called LaunchCharacter() to throw a character into the air, awesome!I made a new player BluePrint based on Character and made the platforms LaunchCharacter() when an OnOverlap physics collision occurred.

Finally, my stupid cube could see its house from there. Time to make it move sideways.Fortunately LaunchCharacter() takes a vector when launching something, so in order to not change the vertical velocity, I could simply GetVelocity() for it, change the sideways value and pump that into LaunchCharacter()!Except not.Then I realised that LaunchCharacter() has an option to only affect the axis I was bothered about, so I added another LaunchCharacter to make it move sideways only, hurray!

Sadly, my character kept moving sideways even when I let go of the key.Fortunately I'm not stupid, I could simply GetVelocity() for it, negate the sideways value and pump that into LaunchCharacter()!Predictably, this didn't work either, *sigh*.

Finally my brain clicked and upon releasing a movement key the BluePrint simply calls LaunchCharacter() with zero values and the override option enabled for the sideways value.

Changing colours

This was easy enough, I had thought about changing the materials dynamically, so that when the "change colour" key was pressed I would simply invert the brightness of the two coloured materials, but in the end I decided to just create 4 materials and swap between them:

Bright orange

Dim orange

Bright blue

Dim blue

But this meant keeping track of all the platforms throughout the lifetime of the level so that I could change the material assigned to them.In my level BluePrint I added two array variables, one each for the orange and blue platforms.OnChangeColourEvent I iterate through both arrays and assign either the dim or bright materials to them depending on the colour of the player.

To prevent the player from being able to rebound off platforms that are not their current colour, in the OnCollisionOverlap() event I check to see if the player and platform materials match, if not I don't do anything.

Setting resolution of the game

Searching for a way to set the runtime resolution of my game lead me to the documentation page describing the "Quick Settings->Scalability" menu on the main editor toolbar, but this made no sense in that I couldn't see a single thing on how to set the resolution specifically.

As it turns out the only way I could find how to do it was to add a node at the start of my level graph to issue a Console command of e.g., r.SetRes 1280x720

Adding the juice

Seeing as the basic stuff had been done and I was running out of time to complete new things (like proper level creation), I decided to justify my choice in doing this in UE4 by juicing things up.And this is where UE4 started to shine, adding particle-systems on platform collisions was trivial, adding funky overdone lighting effects was too...Honestly, to be able to just spawn a particle system at a collision point and have those particles bounce off platforms while lighting their surrounding areas up is mind-blowing for my mode 13 brain.

Summary

I thought that using something like Unreal Engine would take the fun out of creating a game, leaving me with putting the "ass" in "art assets".But the fun of learning how to use the engine and joy of debugging BluePrint code visually, combined with being able to add insane lighting and particle effects in a whimsical folly of sugar-fueled insanity is... well, it still feels like making a game and like I achieved something, which is all I can ask for at the end of a day.

What it is

This is (the prototype of) an Unreal Engine 4 remake of my tiny 8-hour jumping game, featuring random level generation and so much lighting that it makes blind people wince.

I set aside 8 hours to finally get started on Unreal Engine and while there's no proper objective beyond getting to the top right now, the basic gameplay mechanics of only being able to jump on the platform matching your current colour is working.It's naturally also a delight to be able to visually edit a particle system... and replacing the sparks with an explosive particle system to enable Michael Bay mode is AWESOME!

Sane and pretty level generation comes next, as well as a few billion other "tiny" things (prettier materials, scoring, etc.)...

Capturing footage

I'm (definitely) probably just being stupid, but I thought that ShadowPlay from Nvidia was the solution to all my game-footage capturing problems.

Well, first I had to update my video driver, fair enough.Then it simply wouldn't "switch on".Fine.You have to re-install the GeForce Experience application.Fine.Then I couldn't seem to capture footage of a windowed-game, only full screen...FINE.Oh look, it's randomly scaling things to fit something somewhere.