Assignment 2 is delivered, and Design for Interactivity is finished!
In the end, as we were not required to deliver work files or an executable, our prototype is only partially assembled. Amber developed all menus and the transition / choice parts, while I focused on the interactions within drawings. I’m glad we split the workload the way we did, but am a bit sad that we didn’t assemble the workfiles for a working prototype. I’m sure with a bit of time, I’ll be able to assemble all our remaining files into a playable prototype, but it just wasn’t worth prioritising over actually implementing all the assets and interactions we had planned for and made. Here is a peek at what happened with regards to development of the prototype and my thoughts now it’s done.
Prototyping and Designing the Environment
As soon as we had our idea roughly outlined I started up UnrealEngine, and started making some rough prototypes. Initially we were thinking of having a 3d environment that would be intractable to some degree; a room containing a box of stuff, a table to put the scrapbook and drawings on, some furniture to set the stage, a few items foreshadowing the final reveal. We investigated lighting styles that would make the atmosphere fit the story. In the end we decided that modelling this environment and related interactions would take too much time, and wouldn’t really add to our message.
Development in Unreal Engine (4.15)
Delegating the work between Amber and I
Amber would take the task of making the scrapbook, menus and choices, using the UE4 UMG features to do so. This would theoretically allow us to merge our files more easily. Amber’s parts would be easily exported, and I would be able to call them from my levels when needed. This left me with 4 levels to make, Episode 1 Start, Episode 1 End, Episode 2 Start and Episode 2 End. Although I could probably have made them in two, or maybe even one level, I’m glad I decided to make them as 4 separate levels. Each set of drawings had a slightly different scale, and thus i could make minor tweaks to each level accordingly.
From placeholders and quick prototypes to final assets and levels
I started out with the initial sketch of Episode 1 Start, and our script, picking out one feature at a time and making a blueprint for that feature. Although this allowed me to prototype effectively, and saved me some time later, I ended up scraping those initial blueprint in favour of adding every feature into one big blueprint. This meant I didn’t need to worry about blueprint to blueprint interaction, and I could instead spend the majority of my time actually making interaction features. Anastasia was efficient and structured in her asset-making, giving me detailed plans and sketches. From her sketches and plans I developed my own placeholders that I layered inside the episode blueprint. She had been developing her own placeholders parallel to mine, and saved them in a layered photoshop file for me. In a document alongside it she made an interaction plan with a merged version of the scene for reference. She later updated the assets, with finalised look, which was then easy to implement, as all the functionality was already in place with the placeholder assets. I then used this first episode as a template for the other 3 episodes.
Pipeline with two artists working simultaneously and parallelly on two episodes
While Amber and I delegated the development work into Levels and Widgets, our two animators Lars and Anastasia worked on an episode each. The choice was made to delegate this way so that the visual style stayed consistent within each episode. This gave me the challenge of two slightly different workflows, and working on several levels in parallel, as and when I got assets from either artist. While Anastasia exported her animations as spritesheets in 62.5 FPS, Lars exported his as individual layers in around 12 FPS. Anastasia used a 1080p base resolution, where Lars exported a full 4k resolution. For the interaction reference, Anastasia had a document that described the animations and interactions of each element and Lars instead went with a simple labelled reference picture.
Hurdles in Episode 1
Along the way I discovered that it took a bit longer than anticipated to export the layers, as I couldn’t find a function to batch export the layers, I initially did each layer manually. For the next batch of assets I requested that Anastasia export them on her end, but forgot to mention my naming structure, so I ended up with a bit more chaos in my files than anticipated. Another unanticipated complication was the use of spritesheets, even though I had previously used spritesheets in UE4 there were some additional steps when using them in this context. Using spritesheets in particle systems, they do not need to be converted from textures, nor extracted from the sheet. I merely needed to know how many rows and columns were in the sheet.When using a spritesheet for a flipbook however. it turns out there is a slightly tedious process of converting and extracting, before assembling all the now individual sprites into a flipbook. It also turns out that flipbooks don’t respond consistently to click events. Once I figured out the work-flow though it was fine, for the click events I just left in a single invisible frame from the flipbook as a trigger for the click events.
Hurdles with Episode 2
While working on Episode 1, I had been discussing with Lars what I needed from him. Wise from the experience with Anastasia’s layers, I requested naming structures and exported layers from Lars. This allowed him to develop his assets with this in mind, and when I received his assets I didn’t stumble over any of the issues I’d had with Anastasia’s. HOWEVER, I did encounter a whole new surprise. Firstly, the 4k resolution assets took longer to load, and made iterating on designs slower, I also didn’t have any low res placeholders from Lars, so I was working with finalised assets from the start. It meant I didn’t have to spend any time replacing assets, but I’m not sure if any time was gained, as the loading times for the assets might have balanced it out. The other issue was one I didn’t notice initially, the assets from Lars had really washed out colours for some reason. I never figured out why this was, but instead implemented a workaround. After a bit of trial and error I settled on altering the gamma in the level camera , to get the colours as similar to the reference as possible.
Finalising the project and exporting a prototype
We were all quite engaged in completing this project, and we all wanted to strive for a portfolio worthy piece. While I think we did really well towards that goal, there are several things I would have liked to work more on .
Narration and other audio
We got some assistance on the narration front from one of my online friends, Bavon. He did a stellar job as Sally’s brother, leaving a voice message that functions as an intro to our story. The rest of the narration ended up being me, as we didn’t have time to get another collaborator for the rest of the parts. I’d really like to get the rest of the narration smooth’d out, and implement any other sounds and music in the actual prototype. Although we had several of the assets, and the implementation would have been quite straight forward, we didn’t make time for implementing the sounds. This will take a bit of time, mostly to get volumes and timings correct.
Linking up menus and levels
Baring major errors, this should be a simple affair, merging Amber’s files with mine, and linking up widgets with their relevant levels. Since we didn’t use source control for the project though, there could be all sorts of unforeseen issues with this. Should it go smoothly though, I would also like to attempt to export it as a HTML5 app, and uploading it to itch.io . In addition to uploading it somewhere people can try it out and give us feedback, it would be fun to develop it further. Adding touch events for tablet, and adding more complex interactions generally with collisions, click and drag, or mouse over events.
Ironing out interactions
Some of the interactions I implemented had to be simplified from the initial plan, and I would really like to fix that. The fishes in episode 1 start being the most notable example. They were supposed to idle until spooked either by click event, or apples falling near them. Instead of implementing either of these, I opted for a looped flipbook. This was in part because of complications with making the apples trigger the fishes, but mostly because the level already had a lot of interactions in it, so my time would be better spent implementing things in the other levels.
In episode 2 start I had the opposite problem initially, with not enough interactions. I decided to make the treesprite spin when clicked. When I got additional animations from Lars however, the number of interactions was fine, but I kept the tree spin anyway. Later during my attempts to fix the colours, I slightly broke the tree-spin, and it had some quite obvious visual flaws when it spins. I’d like to fix that.
Thoughts about heuristics, affordance and emotional design
In the end I feel like we could have spent even more time thinking about affordance in our app, it felt to me like we got tunnel vision a little and focused a lot on our narrative and the prototype. For future portfolio use this is great, but for learning outcomes in Design for Interactivity we could probably have spent more time thinking about the heuristics and affordance. I do think we managed to think a lot about the emotional design though, and whether or not we achieved it, we certainly designed to appeal to all three levels of emotional design.
Reflections about Unreal Engine 4 for 2D
I remain an avid UE4 fangirl, I think the engine is extremely versatile, and I’m becoming more confident with it for every project I do. That said, it really isn’t very intuitive to use for 2d applications. The flipbook system is awkward, and sprite collisions only seems to work sometimes. There are a lot of less obvious options that need to be ticked, or un-ticked, the names of which seem to be only occasionally logical. Combining UMG and the Paper 2d system works, but it’s got some room for improvement. Ok, a lot of room for improvement. I should definitively take the time at some stage to look up future changes, and maybe make some suggestions based on the hurdles we ran into on this project.
Template for future animations?
Can I use this project in the future? Well, appart from adding it to my portfolio, I will probably make a few custom variants of this project for fun. One discussion that took place after showing off the project, was to make some small custom projects for a friends granddaughter. The possibilities are many now that the features are in place, it’s reasonably easy to just swap out the assets for something completely different.