We released Ether One in March through UDK on PC. We’re now looking to release on PS4 (and hopefully a few other platforms) so it made sense to make the switch to UE4 because it’s so much more affordable for a small studio like ours to do. I thought it might be cool to document our progress throughout the transition for anyone interested. We’ll highlight any mistakes we’ve made and any things to look out for if you’re transitioning. We’ll also post about our workflow so that people can shout at us for doing things wrong! Hopefully it will also help people new to the engine like us!!
I’ve been using Unreal for around 2 weeks so the process is still pretty fresh but we managed to get quite a lot of content from UDK into UE4 in that time. So here’s how we started:
The tool allows you to copy and paste actors’ exact locations from your UDK map to your UE4 map. UE4 works on a folder structure similar what you’d find in Windows. The main thing to keep in mind with this tool is that if you have a package in UDK called ‘Modular_Assets’ then you’d create a folder called ‘Modular Assets’ in UE4 in the exact same way. It’s kind of hard to explain but something like this:
Once you have all the folder directories set up you need to import ALL of the content back into UE4 going folder by folder. I mainly just created one sub-folder for ‘Meshes’ and another for ‘Textures’ since I could add the other ones at a later date (I didn’t bother with the ‘Material’s’ folder until later). Once you have all of your static meshes and textures back into Unreal it’s just a case of copying and pasting your actors into the tool from UDK. Then converting the data. Then copying into your UE4 map. As long as you have imported all of your assets into the right folders, it will pick up the reference and paste the actors into your map.
It sounds long winded but it’s actually pretty simple and It only took me about 3-4 days to get all the folders set up with content imported. Most of the time was spent pasting large numbers of actors which froze up my computer since I don’t have the most powerful PC. You can use that time to go through all the awesome Unreal Engine videos that are out there on the YouTube channel though!
Oh hey! I may have met you and some of your team briefly when you were exhibiting your game at Rezzed. Ether One is a cool game :). Best of luck with the transfer to UE4.
Love the art style to Ether One. Best of luck in UE4, I’ve been using it for a few weeks and not having to touch unrealscript again is the best! I loved kismet but blueprints is just incredible
I’m guessing you will have to redo the kismet stuff in blueprints?
@Lazy Games - Yeap! In Manchester - Are you close by also? I would say sadly yes, we do have to re-do everything in Blueprints but it’s just so much fun that it’s not a drag at all! Our programmer is working on other things right now so I’m trying to get as much of the core gameplay implemented through Blueprints as I can (I have strong kismet knowledge but basic programming knowledge). I was worried there might be a bit of overhead implementing it that way instead of through code but from doing a little research it seems like a totally viable option for a full game.
@markb - Cheers Mark!
@TJ Ballard - We definitely think getting our game over to UE4 will be worthwhile. So many more platform options including Linux which people seem to be keen for with these types of games. It’s also killing two birds with one stone by allowing us to learn the engine since all the design is 100% concrete. I think starting a brand new game in parallel with trying to learn the engine would be quite a challenge!
@alvarofer0020 - You played our game? Thank you so much for checking it out! Hopefully you’ll be able to compare the two!
I’m in Liverpool. Only down the road really
Yeah blueprints are pretty powerful. The game I’m currently working on is solidly through blueprints, even our last game Generic Jack in UDK was 90% kismet as we had no programmer.
TBH not requiring a programmer is possibly the best thing about UE4
So another big step this week to getting Ether One playable in UE4! I decided to make this week more of a ‘vertical slice’ for want of a better phrase.
I began with setting up a really basic PlayerController, HUD, Pawn and GameInfo Blueprint so that I could get basic movement and interaction in. Nothing too complex apart from implementing the first pass of the pickup system which I needed to play in the level.
I used a basic OnInteract trace for my different interaction Blueprints. The best tutorial I found for this was on the Unreal Engine YouTube page: https://www.youtube.com/watch?v=WwfsWr4A894
When starting to think about the complexity of our pickup system I found Hourences tutorials EXTREMELY helpful to get my head into the mindset of working within Blueprints. Some of them cost a little money but I’d definitely recommend the investment and they’re not much at all for what you get.
This checks the items name and prints it to the screen for now. I’ll add the world display at a later date.
I then added a trace check to see if you’re trying to pickup an item or to put one down. This required me to create a PlaceItemZone blueprint which pretty much has a tag that says ‘I’m an item zone’. These zones in the game are where you can place items for later (Think Case shelves for anyone that has played the game) so they don’t need much functionality. The main thing I implemented here was a check to see the pickups height from the centre of the rotation. This is set in the Pickup item Blueprint explained a little later. The reason we do this is so that we can’t place items through a surface and also so that when you rotation the item in front of you it rotates around the centre of the object.
To get the functionality I just got the Item zones location, split the vector, got Z and then added the HeightOffset of the item (Z) to the Itemzone’s height then combined them back to tell the item where to be placed.
I also added a few basic blueprints for interaction which trigger switches, levers, valves and radios in the game. These are really easy to setup and the Construction Script is AWESOME for allowing you to change things such as the desired mesh, rotation, speed or pretty much any custom variable applied to each Blueprint that you might want to change per object. I actually couldn’t believe how quick it was to implement all the different interactions. I’ll go back and add more complexity to them at a later date but the main thing I wanted to achieve here was a basic play through of Ether.
The prologue are of the game which I’m working in doesn’t have much gameplay. It’s designed to just teach the player basic interactions so in this example I need to pickup a Key card to open the doors and progress. In the level blueprint I check between the trace of the switch to see what the item name is that I’m currently holding. If it matches the desired item, then the door opens.
The main thing as a designer coming from Kismet that I had to get my head around not being able to fire Remote Events around everywhere to connect events up. Communicating from Blueprint to Blueprint via the Level Blueprint is easy enough when you know how but it’s surprising how long it took me to figure it out. This is probably obvious information but I’ll list below the communication JUST IN CASE anyone is feeling as stupid as me:
I then started to apply all the materials to the meshes I needed to make the Prologue look playable adding collision anywhere I walked/fell through. Although the lighting system is different in UE4, I added all of the same lights that we used in the UDK build so that we have a point of reference when someone goes into do a proper lighting pass. We want to try to keep things as consistent as we can with the released version.
I added all of the Dialogue through PlaySoundatLocation in the Level Blueprint. There is quite a bit of complexity to the Dialogue system in Ether so for now I just wanted a quick prototype to get a feel. We’ll add stacks and priorities at a later date to replace the PlaySounds. I also added all the ambient sounds for the level with the same values we used from UDK too.
I’ve also set up the chair sequence that is at the end of the level which probably took the longest time since there is so much going on - mainly due to timings and delays. The only thing missing from this sequence are a few Anims from the SKMeshes which I couldn’t export from UDK for some reason and also a camera seize from the player whilst keeping control of camera movement (I might need some programming help with that one!).
So the milestone for the week is pretty much complete. Right now you can play the game from the start (including the phone call with camera fade) until the chair sequence at the end of the level. I think the next step will be to go back over all the interactions and make sure everything is airtight before continuing. I know there will be a lot of things that have been missed along with making sure all the interaction and movement is consistent with Ether.
Thanks for reading! Feel free to share any useful advice or thoughts on the process and if anyone see’s anything we’re doing massively wrong be sure to pull us up on it
Just a quick update for this week. After chatting with some of the guys from Epic at this weeks Develop Conf in the UK we’ve begun the transition of moving a lot of the trace interaction stuff over into code from Blueprints. We’re going to try and keep as much of that stuff under the hood as possible so that it speeds things up a little and so that we don’t have to worry about it in the editor. It’s also probably a good workflow move!
Whilst we’re doing that we’re going to get the game,player,controller,hud stuff get set up in code at the same time. Once we’ve got that set up we’re going to do a full interaction sweep of the game. This will include all the combination dials,levers,valves,doors, drawers etc so that we can flesh it out and start working on the puzzles.
Whilst I’m waiting for the script stuff to be done I’m going to get working on the more cinematic (matinee’d) parts of the games. I had a quick chat with James Golding from Epic at the event about this and it appears there’s no copy and paste solution for Matinee’s from UDK into UE4. If anyone knows of a good way to transfer the data be sure to let us know. In the mean, I’ll begin deconstructing and rebuilding all of the Matinee data in UE4 (using Timelines where I can).
Wish us luck! (Promise to include pictures next time!)
Still very WiP but we’re starting to get some of the more complex shaders built in the engine at the moment.
Our main focus right now is getting the first section of Ether fully lit so we have some type of idea about how the final game will look! We’re also fleshing out some more of the game mechanics in code but that’s not too interesting to look at atm
Pete - Either One is a stellar looking game, and I’m glad to see it make the jump to UE4 . Thanks for documenting and making public this transition, I’m sure many others will find a lot of value in this information! The game is looking beautiful. Keep up the awesome work
Appreciate your kind words Chance - I honestly thought it would be a harder process than it is. The Matinee transitions are the only killers everything else is pretty straight forward at the moment (I hope I don’t jinx that!).
So this week we’ve been mostly focusing on getting ALL the content in the game. I think I pretty much have every level in Ether fully built with all materials assigned too. I’ve added the majority of gameplay assets as well but a few are still missing here and there. My intention wasn’t to focus on the smaller details but rather try to blanket the entire game and get everything in place ready for lighting.
We finished lighting the Institute (start of the game) and have now moved into lighting Devlin mine. We’ve got a good 40/50 minutes of the game in place now. I can’t believe how quick the process is going. It’s quite an easy process to get content into UE4 and Blueprint along with the details windows are such time savers. You don’t realise how quick the workflow is until you move back into UDK to do something. There are 3/4 less clicks in each action you need to do in UE4 so you can imagine how much time it saves in the long run.
Optimsations
One thing that we really want to nail this time around is the game optimisation. We worked really hard to get the game optimised in UDK but I think we could have done a lot more. With the assets that we place to together frequently we’re in the process of exporting and combing them into 1 mesh. Our goal is to half the mesh count in each level since it was mostly the draw calls that were the biggest killer for performance. We’ll also cut polys that you’ll never see on the backs of rocks and large groups to make things smoother. By mid-sept we want a polished ‘Demo’ of the game which we’ll use for performance testing both on PC and Mac to check the frame rates we’re getting which we’ll use as a standard for the rest of the game.
I also bit the bullet and started re-creating all of our Matinees in the game. As you can imagine, there are quite a lot of them and that’s the most time consuming parts because all the keys, locations and sounds are timed to each other so you have to approach it key by key. Right now I have all the Matinees in place from the Chair sequence at the start, the middle of the game (I won’t be too specific there) and also the end of the game. The big Matinees left to do are the Restorations but I think I might just be lazy and leave that for someone else to do
Code side
I don’t pretend to understand what’s going on under the hood of UE4. Right now we’ve moved our ‘Trigger Items’ over into code. When we were working in UDK we set up a ‘TriggerItem’ class which acted like a use trigger. Since UDK wasn’t great for Use triggers by default, we created a custom class that you could assign a mesh to and when you clicked on it, that would be your use trigger in Kismet. This worked really well so we’re using the same approach in UE4 and this time we’re extending pretty much everything from it. In UDK we had different classes for levers, valves and audio items but this time we’re flowing everything from the TriggerItem class which should improve things a lot. It’s interesting to approach a game that’s already designed because when you’re designing a game things get implemented on the fly and are less efficient. Starting from fresh in UE4 allows us to know the outcome so that we can design everything as optimised as we can.
We’ve now begun the process of getting the 2 big systems in the game implemented - Dialogue and Pickups. They’re the main things we need to get the start of the game (Institute/Devlin Mine) gameplay complete. It also means that we’ll have a solid foundation for fleshing out the rest of the game. We’re prioritising the things that the art and design can spend time placing around the game so that code can keep busy with other things. We’re expecting these two systems to take a few weeks at the least so in the mean time we can be lighting the entire game which leaves us in a good place for Mid-Sept (Or that’s the plan at least :)).
Think that’s all for now. I’ll try to update another nice screenshot for next week so that you can see some more of the outdoor environments which I’m pretty excited to see lit too.
Hopefully it will also help people new to the engine like us!!
. Thanks for documenting and making public this transition, I’m sure many others will find a lot of value in this information! The game is looking beautiful. Keep up the awesome work
