This is the product part of my bachelor’s project, the painting. We set out to answer a question; is it possible to engage an audience of both young and old through procedurally animated images?
To answer this we decided to make a prototype in Unreal Engine! We wanted to make a beautiful piece of art, a landscape painting, that would appeal to mature viewers through subtle beautiful animations and stunning visual assets. We wanted to engage younger viewers though interesting mechanics, interactivity and procedural content, something slightly different each time you look at it.
We were ambitious with our goals; at the start of the project I knew nothing about UE4, and had no programming skills, we had to work on this around other courses, and through personal life challenges. In the end, we had to cut out our interactivity features, rather than slap them on half tested.
This slideshow is a bunch of screenshots from my Twitch streams, all the way back from October, when the UE4 development started.
Here’s a look at one of my blueprints! This is a piece of code that flipflops between maybe blinking one eye, then after a little delay blinking the other. Eyes in this case being point lights, on the front of the troll.
(I might add in some more blueprints and things later)
We had a stroke of luck and got in contact with Helge Dyrholm, artist and responsible for exhibitions at the public library in Kristiansand, and he agreed to arrange a short notice exhibit at the library starting Monday 23rd of May, which I’m really excited for!
(more info about that – placeholder)
All in all we’ve had a ton of good feedback about the concept and the prototype, as well as a lot of suggestions for future directions.
We also have a lot of future plans of our own: More assets, interactivity using a node server and json plugin, new scenes, seasons and weather, using real weather data, using TPE data for sunrise and sunset, general “bug” fixes, investigating sound, more animated stuff, animated AI. I could go on for a while!
For now though, we’re finishing off the document, due the 26th of May. Once that’s finished we’ll be having a small break to recuperate, and then we’re ready to dive into new adventures!
For those of you that have been following my progress on twitch, it comes as no big surprise that we’re done. Likewise if you pay attention to my twitter, or facebook posts, you should have seen me spam the link basically every day the last week or so! For those of you that follow a bit more intermittently, yaaaay ! WE MADE IT!
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.
We were presented with there two themes to chose between for Assignment 2; Out of control and Global Warming. During labs we had a brainstorming session to come up with as many ideas as we could think of. For out of control I had the idea of a game about out of control parents, drawing inspiration for a game idea I had some time ago. You would play as the child, and try to keep your parents in check. My original idea was about parents with mental health issues, where the child can end up taking on the grown up role and looking after their parents. This idea seemed a bit big for the scope of this module though, so we’d need to narrow that down somehow.
Across all the students in the class we had a lot of interesting ideas, including one about Trump out of control on Twitter, Out of control AI cats try to take over the world, a macabre storybook about global warming, a game about assassinating polluters, and a lot more.
Josh made a list of all the ideas, and we all chimed in with which ideas we might be interested in working with. There was a lot of interest for my out of control parents idea, though the original intent for the Out of Control theme had been for an out of control AI. Lars had approached me early on and expressed a desire to group up for the project, in addition Anastasia and Amber chimed in with interest for the idea. The original intent was for the groups to be 2-3 people, but Josh ok’d us as a group of 4. I feel like it might be a bit overkill with 4 people, but I also don’t wanna shun anyone from the group, nor do I want to make a group by myself. With good planning and delegating it should be fine!
Refining the idea
After labs we did a group skype call where we threw a lot of ideas around about what the game could be: Parents with substance abuse issues or mental health issues, playing to get either a happy ending with parents in recovery or a sad ending with protective custody. A slightly lighter theme with a kid that’s trying to get hold of a cookie, but has to cause a distraction to get the cookie, the idea started light at least but then escalated to the kid drugging mum to get the cookie. We went back and forth a lot, occationally straying quite far from the original idea. We kept circling back to the idea of substance abuse, it fit the best with the Out of Control theme. Between lectures, labs and skypecalls, each of us researched the theme and came up with ideas for how the game might work, and what our narrative would be. When we skyped on the 23rd of jan, we agreed that Anastasias ideas for a narrative was the best, and started discussing how to implement it. At this point the general idea was to have a type of flashback to the childhood of a person with alcoholic parents, using childrens drawings and some sort of interactive storybook.
Storyboarding and Twine
With our idea nailed down, we started developing the narratives and how the story might play out. I took snippet from our current narrative ideas and made a draft of it in Twine . Working with Twine was quite interesting. I struggled a bit at first to understand how the linking and stuff worked, but I ended up changing the basic code type to one that had better documentation, and in the end I was surprised by how quick and versatile it was as a tool. In future I can see myself using it for some pretty basic, but entertaining little stories. We used the Twine prototype to show Josh what our plan was for the application. While I was working on the Twine prototype, Anastasia was writing out more stories that we could use in the app. Amber and I took inspiration from Anastasia’s ideas and added potential twist and choices to them, I also wrote down some stories of my own that we could use to mix and match with. We decided that we would have two sets of drawings, one from a boy, one from a girl, ending the game with a revelation about the relationship between the two. We tasked Lars with storyboarding the narratives as we finished them.
Choices about interactivity and story branches
The assignment obviously called for some interactivity as well as a story that had at least two different outcomes. As the idea for our story was based around an adult looking back on their childhood, it would be awkward to have two different outcomes, and we were in stread able to convince Filipe and Josh that our thoughts for outcomes made sense. Each choice presented in the story is only an illusion. We wanted to do this to highlight some things about life for children in troubled homes, and the issues these children might be faced with as adults. With hindsight as an adult, it’s easy to assume that you could have changed your fate, that you could have fixed everything with one different choice. As an adult looking back on a troubled childhood, it’s likely to notice all the things that were completely wrong, the ways the parents were clearly out of control. These things were never as obvious from a child’s point of view. A child in a troubled home doesn’t know a different life, they don’t know how out of control their parents are, or that they shouldn’t have to worry about their parents abuse.
Our narrative presents the viewer with a choice, and each choice will have a narrative to go with it, but the final outcome will be the same in each story. We’ve chosen to do this so that the viewer is presented with some hope, the feeling of being able to change the dire situation of the child in the story. We believe though that most choices that children make in situations like this will not have a long term impact unless the adults in the situation step in and chose to change also. As our story is also a flashback of sorts, it wouldn’t make sense to be able to completely change the future. At least in this instance, it does not match with the message we want to tell.
Tweaking the narratives for interactivity
Amber, Anastasia and I spent a lot of time writing, rewriting and adapting the storylines. Several of the original narratives were based on true events, and therefore only had one outcome. Several of the narratives didn’t lend themselves well to being a series of small animations, or couldn’t be easily adapted to have a choice that would branch back on itself. We ended up with 5 polished stories with the titles; Summer Camp, Lost in the Park, Wet the Bed, The Puppy, Piggybank Robber. From those 5 we decided that the first 2 would be created for the prototype. Amber and I set about making a script with narrations and interaction. We discussed what type of interactions we would have, how we would get between stories and through each story.
Together we discussed some ideas for what interactions we would make to supplement the main story arch choices. We didn’t want to add anything that would impact the story, but instead agreed on adding small animations within each drawing for the viewer to discover. Lars would be drawing and animating Lost in the Park, while Anastasia covered Summer Camp. In the end each of them provided most of the ideas for interaction within their story, and created corresponding assets, while I took the task of implementing them in the prototype.
Well, it’s a weird word, which of course meant I had to google it. Admittedly this didn’t really help at first, and I had to read quite a bit before I started really understanding the concept. In the end I THINK it boils down to being an approach to problem solving. There are various sets of heuristics that we’ve been asked to look at, they are focused around usability and interface design: Error prevention, aesthetics, learnability. The list is long! It seems to me that these are just different angles to scrutinise an interface in search of flaws. To get a complete list of flaws with an interface using heuristics, I would need many hours to systematically go through and try every feature, specifically considering every different heuristic. Even then, I’ve only discovered any flaws that arise from my style of usage, based on my habits and biases. There may be a plethora of different styles and biases that I don’t know that I don’t know!
Exercise 1 – Usability of stuff I Use
The exercise asked for us to pick 3 interfaces, a mix between physical and digital ones, and to write up what works and what does not, including some suggestions for improvement. When initially tackling the exercise I think I over-complicated the scope, which was why I started researching heuristics, in stead of just diving into analysing the interfaces with my prior knowledge. I spent too much time researching beforehand, and writing a quite in depth analysis of my blue keyfob. As a result I only finished writing about that one interface, though I also started writing about the Steam Storefront.
Assignment 1 – Interface Analysis and Evaluation
A look at the usability of selected aspects of the Steam storefront
I did a lot of reading for the assignment, and spent even more time choosing which heuristics and which parts of the interface to include in the analysis. Between lectures and labs I started making notes on what I thought might be relevant issues. I had to cut down my scope several times as I realised how much I could write on just one small part of the interface. I had to eliminate from my assessment anything that would fall under a marketing strategy rather than interface design. I realised that my initial interest in the steam discovery update was something that crossed several other disciplines. This realisation made me a little demotivated, as I realised I wouldn’t be reaching the full conclusion I initially hoped for with the assignment. I also had to eliminate any feature that was too deeply entangled in other steam features, direct links to game pages, the search box and the hundreds of various buttons on the storefront were axed from the analysis. Eventually I narrowed down the features I wanted to analyse down to three sections that work on a similar basis, and are the three major screen space elements of the storefront. Featured and Recommended, Special Offers, and Trending Among Friends.
I was expecting to find a lot of good elements on the steam storefront, especially with recent updates and improvements. To my surprise, I found a lot of issues. The sotrefront uses at least 7 different shades of blue, with greens, black, white and greys mixed in. There’s at least 3 different fonts, and several more different font sizes. If there were design guidelines internally in Steam’s design team, they weren’t followed. Despite this being glaringly obvious once I started looking for it, I had never really noticed it before. I discussed this some with Amber, when we had both finished assignment 1. She agreed that several of the issues we found, had not bothered us before analysing our respective interfaces (she analysed Trello), but now we’re both noticing them more easily and being annoyed by such now obvious flaws.
There are undoubtedly a lot of good things about the steam storefront, it’s certainly improved in recent years too. The recommendations are much more relevant to my preferences, and I’m far more likely to discover, and thus buy, things I would not have found otherwise. But man, it could really do with a bit more polish here and there!
If you’re interested in reading the whole 11 pages, you’ve clearly got too much time on your hands or you’re a Valve employee, but I’ve made it available here.
The new year begins with a bit of turmoil, as we’ve come to expect with new modules, there are a few surprises to take into account with managing our time. Design for Interactivity is supposed to be a lighter course, over 7 weeks, but there’s a lot of interesting stuff on the agenda, and Eirik and I both seem to end up sinking a lot of time into it. Studio feels a little neglected, something I feel quite guilty about. There’s lots to do still, and it’s a lot of fun weh I do have time to work on the Painting!
Progress through January
Firstly, have a slideshow with some pictures!
What’s in these pictures is a combination of thumbnails made by Eirik for the landscape design, and the corresponding test scenes I made in UE4. There’s a lot of green in the scene right now, which makes the impact of the designs a bit less than desired, but I think the designs are all very interesting. I only made 2 of the designs in the end, as I felt Thumbnail 7 worked really well, and was very nice to use for testing!
Slowly but surely we’re adding on more and more assets and mechanics. Most notable developments recently has been the implementation of troll assets. They’ve got their own blueprint, and follow their own version of the day-night cycle. The plan is for them to spawn upside down, so they look like any other rock in the scene, and from there have a chance of rotating up to an upright position, blink their eyes a little bit, and maybe shed some stones before rotating away again.
The year begins with a brand new module: Design for Interactivity! This is a subject I have been curious about since I first read the description in August, and we had several talks with the teachers before Christmas about what the course would entail. We even had some meetings where we suggested things that would be valuable to us, in terms of learning material. Still, there’s always some anxiety with new courses, will it be well structured, will it be interesting, will I learn something that’s valuable at this point in our education?
In addition to being a new course, it’s being held by two teachers that we’ve had little to do with before now, Joshua Griffin and Filipe Pais. From our meeting before Christmas, Josh seems like a sensible fellow, and I’m looking forward to seeing what he’s like in lectures. Filipe we’ve only been introduced to briefly before as he is mainly based abroad, but I remember being quite inspired by some of the projects he showed us in a studio presentation.
Reading from the description of the course, we’ll be learning about a lot of new concepts, or at least there are words that I’m not familiar with from before. Heuristic being one of them. I could have started googling the stuff mention in the descriptor, but I thought I’d rather wait for our first few lectures, so I can pick out the bits that seem most relevant. Instead I sat down and thought a bit about what I would like to learn from this, and what I might apply knowledge from this course to in my near future:
Investigating the Steam Discovery 2.0 update
Although I have nothing to gain directly from investigating this, I’m not working for Steam and I’m not going to be making interfaces any time soon, I’ve been quite curious about it since I read an article on the update. I’d quite like to find out more about the thoughts behind the way Valve promote content, in the future I will hopefully be selling stuff on Steam, so knowing more about how to reach a broader audience will be useful at that point. The article I read looked at the discovery updates from the point of view of a smaller indie game, they noticed a huge change in their views and sales between discovery updates and various promotions.
Interaction Design for Twitch streamers
Twitch is a relatively new medium, and there’s already been a lot of developments to promote more interactivity. In the start, streamers had limited interaction with their audience. The delay between stream and viewer was substantial and from the streamer reading a comment and answering to viewers hearing that answer and replying again meant it was more a live performance where the audience could chat with one another. That’s drastically changed with much shorter delays in streams, down as low as 3-4 seconds. New interactions are also popping up in the market in the form of Bits that appear on the screen, donation alerts that let viewers put their messages directly on the stream screen, and even games that viewers can join in on. One of the first major audience participation games was the party game; Jackbox Party Pack, which allows for 8 players, and up to 90k audience, who can vote on their favourite contributions. The latest innovation in this genra though is probably Streamline, a game specifically designed for Twitch streamers. The game is something like a third person shooter, but viewers can buy upgrades and modifiers as they watch the game; directly influencing gameplay. It reminds me a lot of the Hunger Games, where audience can send packages to individual participants. I’ve not tested the gameplay in detail, and thus don’t know how balanced the view influence is, but I’m very curious to see what other games we might see like this. I’m also very curious to see if Twitch will follow Youtube’s example and allow clickable overlays for streams eventually, or otherwise make the streaming / stream-viewing experience more interactive.
Interactions in physical objects
By happy coincidence I was linked to an interesting gadget just as I was reading about this module, an audio interface designed to be played with, covered in buttons, sliders, knobs, wires and dials. It can output a huge array of different sounds, but it’s such an interesting thing to look at and I suspect the interface would be fun to play with all even without the myriad of sound. I’m sure there’s a bunch of rules and concepts behind the design, and I’m quite curious to find out why I/we feel attracted to things with so many buttons and “things” to manipulate.
Really I’m quite interested in interactivity, it’s a core mechanic of living beings. We do stuff with other stuff; rock shaped like triangle on stick is a spear, preacher stands on podium and addresses congregation, swipe right to dismiss. These are all designs with a particular interaction in mind, and it’s going to be interesting to see where it goes from here.
In the final run up to Christmas break there was a lot going on with IRL. Between Eirik and I there was little time for collaboration, and studio work in general. Despite this we got a lot done, and in the nick of time, made a pretty good presentation.
The presentation was this years major grade, and a big deal all around. We had a full 30 min to talk about what we had done so far, which was daunting. All my previous uni presentations have been around 10 minutes, with a group, and through screen-sharing over Skype. This time, I did it solo, in person, at campus, in front of people. Anxiety kicked in pretty hard beforehand, and I had a few moments during the presentation where I thought I might pas out and/or vomit. BUT! Everything went fine, I got through the presentation, pretty much on time, answered some questions. Then we all headed off for Christmas break!
Much has happened during this semester, both in NUC and in my everyday life situation. There has been a lot of work to do as a student rep; complaints and meetings. There’s been a lot to do as an adult and a wife; the usual household upkeep and a wife whose health has been suffering this year. Courses have moved around, and schedules have been re-planned. Despite all this I’m very pleased with the progress Eirik and I have made with our project: The Interactive Painting.
The planning, re-planning and Trello
We started the year with an idea I’d been digesting over summer, a painting that interacts with its environment through sensors. Initially I had foreseen making it by myself, but it was great news when Eirik turned out to be interested in doing the visuals! We started planning it in more detail over several sessions, and narrowing down a visual style. We made a Trello board with tasks, inspiration and a work log. The Trello board has gradually evolved from a inspiration and research board, towards a task management platform. We made a master list of features we were interested in putting into the painting, and over several sessions assessed their difficulty and impact value. We assigned the impact values according to how interesting the specific feature would be to a viewer, trying to cover as many different types of feature that we thought we could manage. By doing this we’ve managed to create what I think is a quite varied prototype that shows what we’re capable of doing. With the features we currently have in place we’ll be able to adapt them to fit with similar assets, and apply the finalised visuals as those are finished up.
Initial Prototyping was mainly to determine whether we should use 2d or 3d assets to build the painting, as such Eirik made some 2d mountains for me to test in Unreal Engine(UE4), and I used the Landscape tool in UE4 to test 3d features. I’d already familiarised myself with the landscaping tool some during Procedural Animation, and it seemed a very convenient tool to sculpt our landscape. In the end we decided that neither 2d sprites nor the landscape tool would be the ideal route. 2d sprites are harder to light well, and we would rely on very very many frames to make all the little animations look good. The landscape tool is an extremely fast way of building a landscape, but it has a few shortcomings that rule it out as an option, it simply doesn’t allow for a lot of creative liberty. Our current prototype uses a modular 3d asset approach to build the landscape, giving us huge creative freedom to re-arrange the landscape design until we’re happy with it. We’re also incorporating some 2d animated elements, most notably the sprites we’re using in particle systems.
The current state of the project
The 2 weeks building up to WIP 1 presentation have of course been busy, we have a final few days to get our documentation and presentation ready, which would be easier if I wasn’t away from home at the moment. Sometimes life throws you a curve-ball and family commitments coincide with big deadlines, such as now. The fact I’m away has made communication between Eirik and I a challenge, but we did plan for this and set up a plan in advance for what we would do these 2 weeks. Allowing me to work when I can, and occasionally seeing that Eirik is busy at work when I’ve been able to get online.
We’ve got a whole lot done so far in December, and I’m really proud of our progress. On my end I’ve modeled some grass to test in the foliage tool (in UE4), built up tests for layered materials that can be applied to our mountains, and implemented Eirik’s beautiful sprites into the firefly particle system.
I’ve also taken the time to write as much as I could think of in the Layout Document that will be part of our final delivery. What remains now is this blog post, and getting our presentation ready and practised. I need to export some clips of features, and try to export a version of the project that can run on the mac’s at campus. Still plenty left to do, but certainly also a lot already done.
As a final note, and something of personal pride, I’ve been streaming my development work on Twitch. There’s a growing community of Gamedevs that stream on Twitch Creative, and it’s great to be part of the creative community. Much to my surprise and a thoroughly positive experience, I’ve lately been hosted by UnrealEngine’s own twitch channel, giving me another audience of great people who are happy to help and come with suggestions. I’m really enjoying interacting with the community, and trying to contribute with something positive.
In this video you can see the current features I’ve worked on so far, in brief summary;
Day/Night cycle, timeline in the level BP that drives the sun to orbit the scene
Bats, Particle system that has a chance to emit bats at night
Fog, Fog with DoF blur that washes in with it and blurrs stuff out
Spooky Rocks, Just rocks in daylight, during night have a chance of spawning eyes.
Fireflies, particle system that has a chance of emitting fireflies at night (with lights on them)
Ocean, with various adjustable variables like wave height and wind direction.
Sparrows, Particle system, 3 possible variants. Uses spritesheet and SubUV to animate particles
Butterflies, Particle system, Uses spritesheet and SubUV to animate particles
Have also done some testing on a Northern lights system, but not very happy with that yet, so that’s gonna need some more work!
Some of you may have come from Twitch, where I’ve been streaming my progress: https://www.twitch.tv/gladpus I’ve had some brilliant interactions on the stream lately, also had some great tips through to make the whole thing run more smoothly! Feel free to drop by when I’m live and ask me questions!