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! 😉
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.
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.
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!
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.
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!
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!