Ether One - From UDK to UE4

Community Showcase Game Development
21

Awesome! Thanks for these updates. What are you doing for the trace part? are you doing a trace from the camera to see what the player is looking at every frame or only when they click? And did you move this trace into the playercontroller C++ class or keep it in Blueprint? I’m curious because I have a little bit of a similar thing where I have a trace every trick that’s in blueprint right now that looks to see if you looking at an object you can interact with. I’m wonder if I need to move the trace into C++ though.

Thanks again, beautiful game!

22

Hey Barrett, I wanted to check with our programmer Dave Smith before answering this so this is what he said:

Trace is in C++ and most of the interactables inherit from the same class. It means you only use a single trace to check for many items. We will also have a trace when you hold the mouse that will check for item tags for our heads up display. That second trace will run every tick.

Hope that answers your question :slight_smile:

23

Hey all,

Just a quick update this week. We’re focusing on getting the first 40/50 minutes of Ether gameplay & visual complete. It should give us a good idea about how long the rest of the game will take to complete in UE4. The screenshot below is still very WiP and doesn’t represent ‘final’ lighting but it definitely demonstrates the fast progress. Visually, the first 40 minutes of the game is all there and we’re currently in the process of getting our pickup item system working. I’m going to try and get a quite video of that to post here to show you something moving in the game which would be nice! The particles and more complex shaders (water, rock etc) are all implemented in the ‘demo’ now with all the Matinees we needed hooked up.

The systems other than pickups that are needed for us to become gameplay complete are dialogue, the player ‘pull’ system along with a camera seize. Pickups seem to have been relatively smooth to get in so we have a lot of confidence we can get the other systems implemented in and playable in a short space of time (He says).

http://i.imgur.com/BfKEV3R.jpg

As some of you may have seen, Ether One was announced for PS4 on UE4 at Gamescom this week. Getting the first section of the game allows us to start thinking about demoing the game at shows so that’s another reason why it’s become a big focus for us.

It’s been really interesting starting the game from scratch because we’ve found a load of old things we left in the UE3 version which we now know to do much better now. We’ve also found lots of places we can optimise so it’s a continous process to get as much out of Ether as we can. Since we’re not just releasing the UE4 version on PS4 we’re optimising as much as possible as we go without compromising quality. That way when we can to specific platforms it will (hopefully) be a smoother process.

I think that’s all for now - I’ll try and get a video of the pickups in the game at some point next week!

24

More Ether One WIP

Hey all,

Apologies on the lack of updates over the last month. As some of you may have heard, EGX in London is coming up. We’ve been (extremely) lucky enough to be selected by the Unreal Engine team to showcase Ether One at the event in the Unreal booth which is AMAZING news for us!

This meant that we had to get the demo polished up and pretty much close to final representation of the game. There are still a few small tweaks we need to do, mostly with lighting, but we’re in a pretty good place.

The great thing about pushing yourself to get a good chunk of the game to gold standard is that you get quite a few of the game mechanics implemented which you can then start implementing across the rest of the game. Some big things are in the game now are the pickup items, doors, drawers and projectors in the game. Along with the other interactable stuff which we’ve mentioned previously like valves, levers and radios.
We decided to create the pickup system entirely through C++. We had a pretty good prototype set up through Blueprint but as the complexity increased it started to get a little complicated keeping track of everything. Blueprints are still great for handling all the customisations of the pickups such as static meshes, distance from camera & height of pickup so it’s a great workflow. Here’s a quick video of the pickups working in game:

Vine

We also nearly have the entire game lit apart from a couple of the small set piece levels. We’re firing on all departments right now just trying to get all content into the game. After I set up all the levels with the correct meshes in place, James (artist) went in a lit all the levels and whilst we were doing that Dave (Programmer) was coding all the mechanics so that when the lighting was complete I was ready to go and place all the pickups, doors, draws & other interactables. Currently whilst we’re waiting on some of the more custom scripting for the game to be done, NJ (Audio) is putting in all the reverb volumes, ambient sounds & music in the game to get the levels to a good standard. We’re trying to work as efficiently as we can and I know I say this a lot but it’s crazy how quick the workflow is inside of UE4.

So this week we’re pretty much just polishing up the demo ready to take down to EGX. Once the expo is out of the way we’re going to work level by level polishing each in the same way starting at the beginning of the game. On the programming side we’ve decided to push a lot of focus in VR so we should have some fun updates for that in the next few weeks. Although a lot of people loved the Rift integration in the UDK version of Ether, it was implemented quite late on into development and we feel we can do an even better job this time around. So whilst everyone else is working on polishing the rest of the game, Dave will be putting a lot of focus into VR which should be really fun.

I think that’s all for now, we’ll be sure to update after EGX and if any of you are at the expo be sure to drop by and say hey!

25

Ether One - a UDK to UE4 update

Hey all,

Apologies about the gap between updates. We had 2 pretty big shows one after the other so a lot of time was spent travelling to the shows to showcase. We were nominated as Finalists at Indiecade in California which was amazing! We were also showcasing Ether One for the first time on the Unreal Engine booth at EGX and we also had the first ever playable on the PS4 in the Sony Playstation section. So lots going on! Photos from the event can be found on our Facebook page here. It would be awesome if you could like the page for us too!

So back to Ether One - Art-wise we’re in a pretty good place as you can see from the screenshots below. Everything still very much WIP but we have most of the game lit to a base standard now in all the main areas – Harbour, Mines, Industrial and Village. We’ve not really touched the set piece story parts of the game in the middle and the end since they’re more gameplay heavy so we’ll probably tackle those when everything else is in place. We didn’t want to spend too much time focusing on refining the lighting since myself and Dave are still busy trying to get all the gameplay in so it makes sense for us to have access to all the levels when we need them. It also frees up OJ and James to work on other art things non-Ether related rather than distracting them all the time!

http://media.tumblr.com/de2b275aa963a091a99cc18a968771eb/tumblr_inline_ne011o1Z5L1qmp1cp.png

A few more of the gameplay shaders have been implemented also. We’re mainly adding them as and when we need them. For example if Dave is scripting the Ribbons in the game and needs some of the shaders finishing, James will set them up. It feels like a smooth workflow and it keeps our content nicely organised too.

http://media.tumblr.com/330711d5ffd5f1d015e117d97e0a2468/tumblr_inline_ne011wUchB1qmp1cp.png

I’m feeling pretty confident that we can get the first half the of the game to a good standard down for the end of October. Our main goal after that would be getting play testers in to start trying to break the game. I’m not sure if this will be the case but it feels like there are a lot fewer bugs in the game from first implementation in UDK. I think this is because that we have everything already fully designed and the variables don’t change. This means that Dave knows the result of how the class/blueprint is going to work and can script it accordingly. I think most bugs are created from designs changing and code being added to existing classes.

http://media.tumblr.com/81c9bcc3fbd664ea8942178a2a4fb6e8/tumblr_inline_ne0124Qkvw1qmp1cp.png

An issue which I STILL haven’t addressed is how to get all of our volumes over from UDK into UE3. I’ve tried a few tools but most of them are for BSP and not volumes. Blocking, reverb and stair volumes are a huge part of Ether One so ideally I’d like the process to be as easy as possible. And since we have the UDK build pretty watertight it would prevent a lot of collision issues we might get later on.

http://media.tumblr.com/1e1d146be036344625abbe1181c4f48d/tumblr_inline_ne012c5ges1qmp1cp.png

Most of the scripting that we needed such as the Ribbons, puzzle item interactions and core memories (Camera) are in now for the first half. A lot of what’s left is custom scripting for certain puzzle elements which we can’t use across the entire game.

The plan once all the scripting for the first half of the game is done is to move onto VR. It’s something we really want to spend a lot of focus on since we only implemented the Rift towards the last 1/3 of development and although we got lots of positive feedback from it, there are a few gameplay mechanics that still felt a little awkward with the HMD on.

I think that’s over for now. I’ll be sure to get a few more videos of some cool gameplay stuff for the next post!

26

Ether one december ue4 update!

Hey all!

So, good news! We’re at the stage of polishing the main parts of the game so that we can start heavily play testing and showing it to people for demo’s and the impending release! This is definitely the hardest (and most time consuming) part of development where you can never tell how long small tweaks will take to get right. We also had the amazing opportunity to take Ether One to Las Vegas a couple of weeks ago to showcase at the Playstation Experience with a few other independent developers so we had to get our demo polished up for that which was an awesome experience!

http://media.tumblr.com/e586e73ac187573b23871091f5b294fe/tumblr_inline_nh13o9x1JP1qmp1cp.jpg

For the last 3-4 weeks we’ve been pretty much doing all the ‘under to hood’ stuff which is mostly being implemented in C++. Dave is working on the save game system currently. It’s something that we really wanted to get right this time around as we had a few issues on release with save game bugs. We got the majority of the bugs fixed pretty quickly after release however save game bugs are also hard to find & fix since we need to grab each persons save game data to repro & fix it – definitely a big learning curve in game development for us! The idea this time round is to have a bulletproof save system (isn’t everyone’s!) which takes some time to implement and get right, learning from previous mistakes as we go. Hopefully the additional invested time will also allow us to stream a lot more content in and out of the levels – pretty much all of our gameplay in UDK stayed on the persistent level to try and avoid those issues so this time around it should be much more optimised.

http://media.tumblr.com/21b6cd09d0460141c9a8f72a5dcc08bf/tumblr_inline_nh13t4HWbr1qmp1cp.png

On the editor end, OJ has been polishing the lighting in the game. Lighting is something we’ve found to be a long process. Not because of the engine but just game development in general. It took us a while to get a feel for the new lighting system and get Ether to the point where we could re-create the tone that UDK Ether had. We’re still not entirely happy with the lighting, we want to recreate that ‘sharp’ lighting UDK Ether had so we’re not quite there yet. Keeping the tone of the game is really important to us, we don’t want it to feel like a different game so that’s something that’s been quite challenging. I think it will definitely be an ongoing element that we’ll tweak right up until release.

http://media.tumblr.com/0224953e1261c7d6291175acfa3219a5/tumblr_inline_nh12yyx0bl1qmp1cp.png

Gameplay wise, not too much has changed. There are 20 puzzles in the entire game. I would say around 13 of them are fully implemented with the dialogue in. Maybe 5 are in but with small gameplay specific things missing, and the remaining haven’t been implemented because they still require certain scripted classes to be created that will be done under the hood. I’m not too worried about those at the moment since Blueprints make it speedy to implement gameplay & once I have all the classes created I can finish the remaining puzzles in a day or so. The main rush here is that we want to start fully playtesting soon so hopefully once the save game stuff is done we can get all those classes implemented.

Something we used a lot of in Ether is Scaleform. We mostly used it on the central big map board in The Case where you could play back puzzle audio in areas and also use it as a fast travel mechanic. We also have a writing mechanic in the game where you can input text with your keyboard or gamepad to solve puzzles. With the UE4 implementation, we’re looking into using UMG (Unreal Motion Graphics). Since it’s a relatively new feature, when we wanted to start working on it, UMG wasn’t in a good enough place for a shipping/console game. Now that it is in a good enough place, we’re busy with the save system. So it’s definitely challenging working in a new engine with constantly improving features but it’s also really exciting to get those features and great when things do come together so we can’t complain! Whilst we’re waiting on certain features to get implemented we’ve been working on ideas for our new game so it’s not like we’re left with nothing to do.

http://media.tumblr.com/375eabc7037569744c276ef112199acc/tumblr_inline_nh134slhvA1qmp1cp.png

Overall we’re pretty satisfied with the speed that things are coming together. If I remember correctly, this time last year, I was still building the industrial area during the Christmas break so we’re definitely further into development than a similar time last year. We’re going to keep working through Christmas and in the new year so that we can hopefully begin the conversation about releasing with the different platform distributors. Something that we’re hoping to do is give the UE4 version of Ether One away for free for people that already own Ether so that you don’t have to pay for it twice! We’ve spoken with the people in charge of licencing and distribution and it seems to be a viable thing so hopefully we can confirm that in the new year.

As always, let us know if you have any questions! A few people have already approached us about making the transition from UDK to UE4. We’re always happy to share any information or tips we have that you might find valuable!

27

Hi Pete,
It’s a gorgeous game you and your team made.
I have some questions : Is your level one big map or do you use some streaming ? Did you use some specific optimisations on visiblity, meshes or textures ?

28

Hey Galeon, thanks!

We have 6 main areas in the game, and in each of those we have between 10-12 level streaming volumes which we’re loading in and put on touch. In terms of optimisation, we’re still playing around with what works best, but stationary lights definitely take up quite a bit of performance (especially on console for some reason) so use static where possible - which sounds pretty obvious but even in a section where you have 2-3 close by it can cause dramatic slow down.

Visibility wise, all the usual tricks work pretty well out of the box - cull distance & precomputed visibility seem to do the trick (but add on build times so only add precomputed volume when you’re doing test builds). We used LODs quite heavily in the UDK release but at this moment in time, there seems to be a bug in the UE4 LOD system so we need to get that sorted out before we do LODing in the UE4 version. Textures we haven’t changed at all. Since we want to give PC gamers the option of full resolution settings, we just put it in the options menu to turn down the texture detail if they wish.

Hope that answers your questions?

29

Thanks for the insight Pete, this is usefull advices about streaming and static lightening.

30

It is looking interesting, Goodluck guys :slight_smile:

31

Thanks for the update, Pete! Glad Ether One is getting so much attention :slight_smile: Keep being awesome

32

Ether One PS4/UE4 Feb update!

Progress. Progress. Progress!

So some good and bad news! This morning we had the strongestbuild of the game yet! The bad news is that it crashed just before the end ofthe game (we were very sad). So we’re nearly at the stage where you can play Ether from start to finish with a few things missing here and there. There are still some big systems left to go in butmoment to moment, the game is playable and it’s just missing those smallerdetails – this door doesn’t rotate enough, or that lighting is a little off, those kinds of things.
We’re looking to be in a pretty good place which means we’ll be opening up the game to heavier play testing. We’ll be getting a bunch of people to come into the studio to play and break every aspect of the game which is fun but also worrying. The good and less stressful thing this time round though is that we don’t have to ‘focus’ test which means testing whether the game is good or not – nothing in the design of the game is changing so even if you thought Ether One sucked first time round, well, I guess it will suck again for you! :wink:

A lot of the work we’re doing now is focusing on optimisation; things like combining assets we use multiple times into single meshes and trying to bring material calls down along with level streaming and culling. We’ve not done hardware specific performance tests yet but we’ll start that once all the core gameplay stuff is out of the way.

The main systems we have left are mostly the save game (which is already halfway coded) and also our writing mechanic in the game which will be powered by Unreal’s UMG (you can see an example of this on our trailer at 1:00). We’re having a few issues with it at the moment since UMG is such a new feature of the engine but you would expect that with any new feature – it’s mostly about working around those kinks and being as efficient as we can.

http://i.imgur.com/tCgKTta.png

It’s been fun to deconstruct the game from UDK and build it back up in UE4 too. The team on multiple occasions have been thinking ‘what the heck was I doing when I put that into the game’. We’ve found a whole bunch of mistakes and badly optimised things so it’s been a good process to iron out all the gameplay bugs – Some of them are super awful that I hope to never repeat again! I feel a lot more confident with implementing major gameplay elements into Blueprints than I did when using Kismet also. Blueprints feel more robust and it feels as though you’re actually affecting the code of the game whereas with Kismet it always felt a little janky – maybe that’s a physiological thing but implementing the gameplay has been a smooth and quick process nonetheless.

http://i.imgur.com/U8NvUoq.png

LEARNING EXPERIENCE

I few things I’ve thought about whilst developing in UE4 are how we could have been even more efficient with the port from UDK to UE4.

Instead of hitting the ground running, I wish we had done a few more tests to see what was possible in UE4 and laid a ground work before developing a full game. We’re starting to find new workflows as we used the engine more which is obviously inevitable. It has meant the implementation of new systems has been quicker from code to blueprint and therefore communication between coder to audio, art and design has become a smoother process. Things like creating a sceneroot in code within a blueprint, then adding a mesh on top and exposing the mesh into the editor is a big time saver – it means a lot of the ‘F4’ properties we had in UDK can be added through construction script (or the code equivalent). Things as simple on a door blueprint like creating a variable called ‘TestDoorEndRotation’ and when clicked shows you where the door will end on its rotation saves seconds per door but in a game with over 200 doors those seconds soon amount.

Also implementing level streaming earlier on would have helped. If you have your game type and player set up, tackling streaming levels before gameplay would help a lot. As it happens, I did 90% of the puzzle things that didn’t require custom code in the first quarter (2/3 months) of development on the persistent level. This meant that when I went to start streaming levels I had the choice between deleting the BP’s and adding them again on a sub-level or leaving the actors behind on the persistent. It’s not a huge issue, but if you had all the sub-levels set up to begin with, I could have made that process a lot easier for myself.

Definitely the biggest learning curve has been re-establishing the communication between designer & programmer. UE4 has made things even quicker to throw out gameplay actors and we’re constantly finding nice little features that help us focus on the design of the game rather than spending time figuring out how to do a certain technical thing which is great. Although it’s still quite fun playing with new toys in upgrades to the engine!

http://i.imgur.com/49PjOWB.png

AWKWARD ISSUES

There was a slight learning curve when trying to use material instances through PP and also Matinees. Since it feels as though Epic are trying to transition out the use of Matinee for a more robust tool in future releases they left Matinee pretty much the same from UDK. However changes to how we trigger things are different in UE4. Previously we used Matinee to trigger our restoration effect in the world (you can see the effect on our trailer at point 1:15). The image below shows how it’s a slightly different set-up now, it’s not that it’s more time consuming … it just feels more long winded and as a result has slowed down some of the progress on the visual side.

http://media.tumblr.com/4320e9315243ff3e7285a2ec01f90725/tumblr_inline_nk2ndtbAuN1qmp1cp.png

We also have a big issue with the notes and localisation in the game as our previous formatting of notes in UDK now doesn’t work and there doesn’t seem to be a solution at present. As some of you will know, we have A LOT of notes in the game so this is a worrying issue for us. Epic, however, have been great with their dev support and hopefully we can get those issues ironed out pretty quickly.

WHAT’S NEXT?

Once we get those big systems in place that we need to start heavily play testing the game we’ll be moving onto PS4 specific things and making sure that the console release is as solid as it can be! This is the most exciting part about the whole process - being able to release our game onto the Playstation will be a huge dream come true - we’re all hugely excited to get it out to you all that aren’t able to play Ether on PC! This is the reason we spent the last year working on a game we already spend 2 and a half years creating to make sure you all have the best possible experience - we wanted to do it ourselves and not hand it off to and outsourcing studio. We’ve put a lot of thought attention to detail will be there so it should be very cool! We don’t currently have a release date for a Playstation release but we’ll be sure to post as soon as we do.

Another huge bit of news is that we’ve been invited by Unreal Engine to attend this years GDC in San Francisco! We’re really grateful to Epic & the Unreal Engine team for inviting us along. It’s an amazing opportunity and we really can’t thank them enough - If you’re reading - you guys are awesome!

http://media.tumblr.com/efdbaf4dfbdec42f0965c5bf396f690c/tumblr_inline_nk2oroEXGb1qmp1cp.png

Pete will be there with the UE team on the stands at GDC to help out with any questions people may have and to just generally chat about all things game dev! So if you’re at the event be sure to stop by and say hi! We’ll be sure to post lots of pictures from the event. We should also have a nice little surprise for you in the next couple of weeks so stay tuned for that!

33

Pre-launch update!

HELLO!

March and April kind of feel like a blur. We’ve been deep in development focusing on getting Ether shipped on the PS4 so apologies about the lack of updates in April. It’s being released in a few days so I’ve I thought this would be a good chance to update you all about how the last couple of months have been.

We went out to GDC in March with the UE team and had a great time! I can’t thank them enough for the amazing experience. They really do treat the community great and everyone on the team is incredibly open and nice and treat you as part of the family. I’d especially like to thank Chance Ivey for organising for us all to attend. It must have been a hectic time for him sorting out all of the awesome UE content at GDC and on top of all that he arranged for a group of devs from the community to hang out with them. It must have taken a huge amount of planning and preparation and it goes to show just how much the UE team care about their community. I didn’t manage to write an update of the trip but Tom Looman over on his blog did a pretty good post for anyone interested. I have to say, I met some awesome (and incredibly talented) guys from the community (see image below) and it was inspiring to see so many awesome things being done in the engine - it gave me a good recharge of energy to get home and get the game finished.

But anyway … back to development!

So the last couple of months have been focused on shipping our game on UE4 and we’ve come into some interesting hurdles along the way which I wanted to talk to you about.

Shipping in UE4 on console over PC.

I’ve always heard horror stories about cross platform releases and how you’d have to optimise in different areas to get the game to even run. Thankfully we’ve found that this isn’t the case with UE4 and they’ve clearly put a lot of thought into small teams shipping games on multiple platforms. We went to the PSX last year with Sony and creating the demo to show at the event was just a case of telling the engine which platform to deploy to. This is great because it means you’re not taking time out of development to focus on a single platform. That said though, I would recommend any development teams wanting to release on multiple platforms to focus on one platform at a time. We’ve ran into a lot of platform specific issues which has slowed down progress and so rather than worrying about all the issues on each platform at once, we decided to focus on just the PS4 and then release PC a few weeks. We decided to do this because we already knew the process of releasing a game on PC from last year and the PS4 is our first console game, so we wanted to focus on the unknown first. If you’ve never shipped on console before, I would highly recommend you focus on that first.

Custom Actor Classes

Using custom actor classes helps massively when shipping a game. As I may have mentioned in a previous post, we use something called an ‘EtherTriggerItem’. This is a pretty basic class that detects when the player clicks on it and then it will send off a ‘Triggered’ event inside of Blueprint. It also has a few other properties built into it such as ToggleHidden, Screentag (this is for when you press and hold LMB on the object it tells you what it’s called), StaticMeshComp, etc. So this is basically just a Static Mesh with a bunch of additional properties. The great thing about this is if I set something to hidden or toggle hidden through blueprint at any point of the game, our programmer has already saved the property ‘ToggleHidden’ which means that’s one less thing to worry about when it comes to implementing a save game system. It also means I can have a folder in my content browser full of different trigger items extended from ‘EtherTriggerItem’ so they inherit the same properties and I don’t have to worry about setting them up each time. This has been a massive time saver in terms of getting the puzzle design implemented because we re-use a lot of mechanics throughout the map and it’s a case of dragging and droping into the world then editing any custom functionality.

In Ether UDK we also had a custom particle system & custom InterpActor however we didn’t feel as though we needed the particles this time around because and I used EtherTriggerItems whenever I needed to make something move as they’re dynamic by nature. I may not have needed all of the other properties such as a screentag for a basic mover however it allowed me the flexibility to implement things quickly and if I then decided I wanted a screentag later on then it was already there to access.

Through Blueprint we had a PostSave and PostLoad function, this mean that I could save a variable, timeline or whatever had changed in the level and then on post load I could get a saved bool and fire off an event into Blueprint on True/False which gave me (as a designer) a lot of power – It also means that if anything isn’t saving properly it’s all my fault instead of passing the blame onto our programmer!

Save game through Blueprints

What an invention! The save game property on all variables in Blueprint. I can’t say enough how helpful this has been. It has sped up our workflow massively. Instead of finding something that isn’t saving then waiting on our programmer to fix things I can now jump in and fix everything that doesn’t save by clicking the save game property on a variable. I sometimes question if this is too much power for a designer to have but hey, it works! I would recommend creating a new category called ‘SaveGame’ when saving variables so that you can quickly go into each blueprint, select the category and flick through all the variables to make sure the property is ticked. If you have a lot to do at once or if you’re just completely worn out from development when clicking the savegame it’s possible that you might forget to tick one or two so this process ensures that you can quickly locate the ones that haven’t been ticked.

Level Streaming on console

I wanted to make sure the game ran smoothly on the PS4 and I knew that it would require a lot of optimisation. The good thing about releasing on the PS4 means that we focused a lot on optimisation at the beginning and therefore when it comes to releasing on PC we’ll also be well optimised.

One thing that I have found though is that you can go too far with level streaming. In one of the bigger levels in the game (Pinwheel Village) we had about 40 streaming volumes in place making sure that whenever you couldn’t see something it was streamed out. We also had pretty aggressive culling in place and had secondary culling for longer view distances. This worked out really well on PC however when we loaded onto the PS4 we were getting crashes. This was partly due to a SceneRenderCapture not working how it was supposed to but it was also to do with the streaming volumes and trying to calculate multiple volumes at a time. It turns out that when the console is constantly thinking about which level is loaded in is just as bad as having everything loaded in (if not worse). To get the game running we had to do multiple tests, I ended up deselecting all streaming volume information from each streamed level and it seemed to still run fine. It turns out with just a culling volume in place and all levels streamed as AlwaysLoaded we only get slightly less FPS (maybe 2-3) however everything else runs fine. Sometimes you have to be conscious about over-optimisation and whether you’re actually improving the game at that point. One of the biggest flaws of UDK Ether was that we didn’t have enough time to optimise at the end. Once you get to the end of a project it’s almost too late to start streaming levels (especially levels with a lot of gameplay/kismet/blueprint on them) because you don’t want to break everything. I’ve found doing this process early on definitely helped however it’s also possible to go too far so know your limitations!

The ‘Promoted’ branch

Somewhere towards the end of March it was decided we had to move over to the 4.8 promoted branch. Obviously this was a massive step because it isn’t recommended you move a game onto an unreleased engine as they can sometimes be unstable however the pros well outweighed the cons in this instance. This helped our programmer out massively as he had access to a lot of things he needed to ship our game on console. However it also broke a lot of art & design things in the game. When it starts getting to the end of a project, the programmers time is more valuable than art and design because of the amount of systems that can break or the platform specific code that needs implementing. So anything that you can offload from the programmers workload the better. It also meant the rest of the team had a lot of bug fixing on their hands. Things like particles not working, and SSAO breaking were common issues. The AO seemed to get fixed then break again multiple times which was quite stressful because we thought we might have to ship with broken AO but thankful the UE devs on the forum helped us out very quickly with those issues so that was a massive help.

The biggest issue we had was with blocking volumes not translating over onto PS4. If I created blocking volume in the editor and duplicated it around to different parts of the level it would work perfectly on PC however when you built for PS4 all the blocking volumes wouldn’t be detected. It took me multiple packaged builds of identifying the issue but it turned out it was if a blocking volume was duplicated and then moved onto a streamed level. Obviously this is a very Ether specific bug but I guess I’m trying to say that random issues can arise towards the end of devel and they take time to identify and fix. Knowing that these things can happen unexpectedly will allow you to leave plenty of time before shipping which is another reason why tackling one platform at a time would make your life a lot easier and allow you to ship on time.

Closing thoughts

The main development of Ether One has pretty much wound to a close now. We’re launching on Playstation 4 through the PS+ instant game collection this week and then it will be a case of identifying bugs and getting it patched as quickly as we can and then moving onto PC in a few weeks. The interesting thing about shipping a game is that no matter how much playtesting you do it will never be as much as day one release when 1000’s of people are simultaneously playing your game. Hopefully there won’t be any major issues but you can never tell – the important thing is that your active in responding to the community and get the issues resolved as quickly as you can. Once the bugs are fixed we’ll then move onto the PC re-release which will be free for people that already own the game and then we’ll be moving onto new things!

I’ll still post a few more updates on post-release and any other advice I can think of about shipping a game and the process of moving from UDK to UE4 however please do post any questions you may have about the process as we’d like to help people out in any way we can.

Thanks for reading!

34

Thanks so much for this thread Pete! I’m about to start the UDK -> UE4 process myself so this is a great reference! I also love you game, I bought it for PC when it came out but I was working on a slightly similar game myself at the time and because of that I found it very hard to feel like playing something similar so it just sat there. But I recently got it again through PS+ and I’m really looking forward to it. I think it’s a super great idea you guys had.

How long did it take you? I know the thread is about 10 months long but how many man-months did it take you? was it several people full time that whole time? What stuff took the most time? and if you could break it down - 20% asset converting 80% blueprints etc. that would be really helpful. I’m trying to gauge how long it may take myself.

I’m curious to see how your going to handle the PC UE4 version release as well - just have the current Ether One update to the UE4 branch or are you going to keep the UDK version available? are the min specs going to go up for the UE4 version?

Also did you ever find any better tools than those you mentioned at the start of the thread? Ever find a tool to convert volumes?

Thanks so much!

35

Hey BarrettMeeker,

Soooo sorry about the late reply on this one :slight_smile: THANK YOU for wanting to read it all - really awesome to see your enthusiasm and any way we can help out we definitely will do!

When you ask about how long it took I presume you mean from UDK to UE4 right? Yes, you’re correct roughly 10 months but to be honest, a lot of people were tired from shipping Ether on PC so we shipped in March and we probably only started full production around September time I think. I was working on it from April but then our programmer started maybe around August. Audio, tech and art maybe properly in September I think. So I’ll try to break down man months in an accessible way:
April 1 person =1 month
May 1 person = 1 month
June 1 person = 1 month
July (I think I took a holiday)
August 2 people = 2 months
September 5 people = 5 months
October 5 people = 5 months
November 5 people = 5 months
December - not too much got done around Christmas and into January.
January - Art & audio weren’t as active here = 3 months
February = 3 months
March - Everyone back on to fully focus and polish = 5 months
April = 5 months
Total man months = 36 (If my math is correct).

I’m not sure if that helps but yeah. it seems like it would relate to a dev team of 3 working all year solidly on the game and not taking into account any breaks.

The stuff that took most time was definitely the C++ stuff - save game systems, getting things working nicely on console, the UMG map board stuff (in the case) and then the actual submission to Sony took a while. In terms of % I would say:
Lighting: 10%
Audio 10%
Tech (particles, shaders etc): 10%
Gameplay (puzzle blueprints):30%
Importing assets from UDK: <5%
C++: 30%

(I realise we don’t have 100% here :wink: )But this is also hard to break down as this is based on the time it took in months/days etc. So for example if someone wasn’t working as efficiently as another or their hours weren’t as much then their % would be bigger.

Tackling the UE4 on PC will be challenging I think but not too complicated. We’re giving the game away for free to anyone that already owns it. There’s no issue with the licences or anything similar from Epic’s end so they’ve been awesome about that. The way I imagine it going is when you click ‘buy’ on Steam or whatever you get an option to say ‘Play SD edition’ or ‘Play HD edition’ - We won’t be using those words specifically but something along those lines probably. Both will definitely be available though. We’ve not got min-specs for UE4 version yet so I can update once we do if you like (they will be on the Steam page also).

I found a good tool to convert the BSP which I could then use to put all my blocking volumes back in. I found a bug in 4.8 (promoted branch) where if you duplicate a blocking volume from importing then it stopped working but I think that’s been fixed now but here’s a link to that tool:

Apologies again for the late reply and I hope that all helps - if you have any other questions feel free to shoot me another message and I’ll try and help out in any way I can :slight_smile: Good luck with your project!