Dienstag, 16. April 2019

Developer Diary 99 - UI Development Progress

These last couple of weeks I have been working on various UI Interfaces. Here are the most recent versions:




I will in all likelihood settle on the last one: gothic windows with glass mosaic paintings of dharmapalas. There's still a lot of work ahead. I need to replace each individual color segment with individual screenshots tinted with colors corresponding to each element.




Dienstag, 26. Februar 2019

Developer Diary 98 - New UI Attempt with 3d Widgets


My best attempt so far. Shapeplanes with translucent Lensflare Materials merged in a single blueprint which is itself attached to the player character.

Sonntag, 24. Februar 2019

Developer Diary 97 - UI Attempt






Another attempt .... I don't know if I like it or hate it. On the one hand it looks as if a child drew it .... on the other hand it has something innocent and human about it .....

Samstag, 23. Februar 2019

Developer Diary 96 - UI & HUD



Over the last couple of weeks I worked on keyboard and controller (XBox) functionality of the main menu and the game. After a lot of trying I finally found a way to make the main menu work with joypad controls, but a new problem came up in the process .... and it's a problem that is giving me headaches.

For testing purposes I had linked each element to the number buttons on my keyboard. 1 = Void, 2 = Wind, 3 = Fire a.s.o. So when I wanted to switch from throwing fire at an enemy to throwing a water elemental, all I had to do was press the corresponding number button and BAM - the game switched it for me.

But this doesn't work with joypad controls. So right now I'm trying to figure out a non-invasive way of incorporating a basic HUD into the game, that gives players with a joypad easy access to all the different elementals and dharmapalas. I can't expect players to learn keyboard controls while wearing the Oculus Rift. This is especially important, because I need people to test my demo levels, so I can focus on better level design. And nobody can test these levels without proper controls.



I have no idea which direction to take. All I can do is rely on my own experience as a gamer and go from there. Which kind of HUD would be the most non-invasive? How much immersion am I willing to sacrifice? In how far can I use 3d Widgets?






I have already figured out that non-transparent, non 3d Widgets look shitty. As you can see from this test screenshot I made...


So my next likely approach will be using 3d objects as part of the in-game HUD. But I need to find a system that isn't heavy on FPS either ... and currently all my elementals contain particle FX, which will reduce the overall framerate to 0 if the player is constantly staring at 10 of them. Not to mention the sheer annoyance and loss of immersion with an animated HUD.

Tough road ahead.






Donnerstag, 24. Januar 2019

Developer Diary 95 - Creation Of The Final Maze System

As a general rule: If I don't post for a while, it doesn't necessarily mean I don't work on the project. Most of the time it means, that I'm going down an alley (development-wise), of which I am not quite sure yet.

Over the last years I have been bouncing back and forth between various designs of the game world: A procedural world, that creates itself as the player progresses on the one hand, and a pre-generated world, that simply streams in and out levels as the player encounters them. At the same time I couldn't decide on how to optimize performance. That's why I had repeatedly incorporated "forest rooms", closed boxes, that aim to deliver the illusion of a deep dark wood. But every time I followed through with one of those concepts my FPS would eventually drop below a viable point. It always happened during the last stages of game world development and it crushed me quite frequently, because I knew I had wasted hours and hours of work for nothing.

Over the last month, I had the opportunity to try out many things with my new GPU. And this time there was no excuse. If the FPS drops below 90, it's bullshit. If there is overdraw, it's bullshit. If it looks shitty, it's bullshit. Because I knew performance-wise, that I was now on the high end of my previous bottleneck component - my GPU.




And then one night I returned to one of my earlier concepts: A maze-like structure, built from circular walls, with entrances on all four sides of it. About two years ago I had created a procedural maze like this, that would open it's doors to the player once he discovered a diamond hidden in the level. Back then I discarded the idea, because since the maze was procedural it quickly brought me to my limits regarding my skill in blueprint and c++ programming. But then an idea hit me: Manipura Chakra is frequently translated as "the city of jewels".... what if the gates correspond to certain types of gems, that in turn correspond to the five elements that the player encounters?




A unifying concept, that would give room to the entire gameplay I had already set up ... each segment could be optimized and separately streamed, and each part of the maze could be individually prepared as a separate level. There would be no overdraw, as all the other segments would not be streamed at the same time, and the player's line of view would be blocked by these circular walls. There would be no FPS drop, as I would be able to optimize each segment individually. If split into separate segments, I would even be able to use transformable landscape components, lakes, mountains, canyons, as long as they were limited to a single level segment. And the player would still be able to make his own decisions and his own way through the maze, since only one of those four gates needs to correspond with the gem contained in each segment. If one of the remaining three gates by chance corresponds with the gem he encounters, he can move forward in various completely unforeseen directions.









I would be able to use my previously created transition-gates, my destructible blueprints, my dharmapala palace meshes ... all the work was done, it just needed to be put into context and optimized in a way, so that the game was ready for VR.



And so I worked on it. And I created my gems, from public domain images of diamonds. And I recreated my transition gates, so they would respond to the color of the gems. And I set up 8x8 landscape segments and another 36 ocean segments, placed all gates inside the maze and connected them to their corresponding jewels. On top of that I built a randomization system, that places each gem in one of six random locations. So players will never be able to tell in advance where each gem is hidden.



And now all of this preparatory work is done and with a fresh pack of forest assets by the amazing MAWI company, I am ready to start detailed level design of each segment. And the best part? I don't need any outside help. It's all on me, and I love it.








Dienstag, 11. Dezember 2018

Developer Diary 94 - Menu Screen & New GPU

It's been a while since I've updated this developer diary.

Over the last three months I spent a lot of time with external mixing jobs and non project related work. But I earned a decent amount of money and even managed to get a raise at the licensing company I work at, after putting in tons and tons of extra hours.




During the second half of November I returned to Lakini's Woods, but still had tremendous problems getting my head back into the game. I struggled with my previous level design and finally decided to upgrade my GTX 970 to a Geforce 1080 Ti. The difference is noticeable, but it took me a while to find the best deal and even after the card arrived I had some trouble integrating it into my MacPro Setup (Drivers, Updates, Oculus Firmware a.s.o.). Just getting the card to work with Unreal and Oculus took me a good week of forum searches and troubleshooting.




I then divided my previous level setup into smaller areas and started creating a main menu, with basic button functionality. At the moment I am working on the overall button design and tomorrow I will do my best, to get them to work correctly, including SFX.







I have a lot of trouble with my motivation these days. I live close to the alps and "winter's coming" sort of .... I don't sleep much, but I find little motivation in moving the project further ahead. I wish I could just nail my windows shut and stay inside my house for the rest of the year. But every time I stop working on Lakini's Woods for more than a couple of weeks, a horrible feeling starts to creep up inside of my chest. As if I am neglecting a good friend, or a loved one. I feel some sort of responsibility in connection with this project. So I will do whatever I can to move this ahead before the end of the year.






Montag, 3. September 2018

Developer Diary 93 - Forest Walls

I finally found a solution that limits each deep forest segment, yet doesn't destroy game immersion when hiding the exterior world - forest walls.

They are arranged like walls in a maze and thus determine the players path through the forest segment. This is an example screenshot - Top View in Player Collision Visualization:


From the side they look like tree trunks (cylinders and pyramids with a high Z value):


And in game with lighting and foliage they work incredibly well and blend into the atmosphere while limiting the players path and hiding enough masked foliage in order to protect from overdraw:



I'm happy. They are however quite expensive polycount-wise .... each wall has upwards of 8000 polygons due to the minimum necessary complexity of each cylinder to create the illusion of a tree trunk. But with some decent LOD settings I should be able to tone that down as well.


This may seem like a small thing, but it is a huge step on the way to an effective and stable game performance.