Sword of the Sorcerer

We finally reached the end. Our game is finally done for the semester at least. Seeing as how we were accepted to Steam and are a company technically. This was such a great experience learning about VR, Unreal, and just this team created an unbelievable experience. At the end I was jumping from sounds, to debugging, to menus and other UI elements. We had a lot of fun and this experience with UI was unbelievable.

At the end of the project we decided we had to fix the menus first. Although they all worked, there was an issue with the orientation. As I worked on fixing that I managed to make some menus stop appearing completely destroying the game. After a bit I realized, why not save the orientation of the original menu used to begin the game and apply that. Once that started our menus were consistently usable and appeared easy for the player to find.

While solving our orientation issue I was working on fixing the menu only showing up in front of the player once and the remaining wherever it spawned otherwise. I decided to fix it easily and just save the original position and apply it, after a silly mistake that worked perfectly.

The shield UI was updated a lot toward the end. At the end we had the letters all animated and the crystals animated while damage is taken it was hard work but worth it. Overall the application of everything has been interesting, but difficult and fun.shield

shieldDead

Sound Begins

Finally I move from just the UI to implementing sound. We had music and some effects until now, but nothing totally substantial. So far thanks to another programmer on the team the sound menu is all set up to work for the player. Some edits have been made for better usability, but other than that I moved on to adding sound to each aspect of our current UI.

It was pretty easy with the changes, except the hover over effects. We need those to stop so we need a component, which widgets don’t have. Luckily we were already getting a reference to the menu so adding sound components to the 3D object wasn’t too rough.

Having started the next step is to actually add them all as well as add in all the polish we need to the UI. We are being hit a little hard with feature lock so soon, but our team is solid. We all know our jobs and are willing to jump around if need be for each thing.

End Screen Pop Ups and UI Fixes

This time around there wasn’t much to do. We had a sudden even thrown onto us to in order to display our game, so we threw together some better end screens for faster restarts. They were simple, but posed some trouble to make them something the player could interact with. After a few hours of work putting that together I changed our next wave menu around as well. This time the menu had to act like the pause menu, it doesn’t draw all on top, but it still helps.

 

Our team is hitting crunch time now and things are kind of all over. We are prioritizing a lot and choosing things to change and cut. We would like to add everything we hoped, but the current things that weren’t too risky we did. Alongside the crystal UI previously and the pop ups here, we added a spell cool down to the game. We decided this would work best for the game to allow the players to use spells more strategically. As of now the plan is to change the spells and to possibly switch to a more mana like cast requirement.

Then we had the general menu polish we have been adding including the pause menu and testing score. A temporary UI element was made and added to the shield to try and get a better test result at the end.

Our team has sort of started jumping around, but we know what our goals are and moving toward them. Once crunch time is over it will be great to look back at all the iterations each part of our game went through.

Alert To Attacks ???

This week the focus was on a UI element to alert to player to a crystal being attacked. The general idea was easy, but implementing the design not so much.

The plan was there would be something to kind of mimic the map on the shield. The design was for it to look almost identical, but purple circles. This would be for when they were all safe.CrystalAttackedUI_OFF

Then when one was under attack only it would flash, but if all were under attack it would look like this.CrystalAttackedUI_ON

The overall implementation wound up being more challenging than expected. The current code had no way set up to display any kind of check when the crystal was under attack, but that wasn’t the hard part.

First I needed the images straight from my designer, Unreal doesn’t really like circles. So once I was given the image I realized that it doesn’t tint as well as I hoped so I took the image and made it red. Once all that was set up it came down to actually binding the image. At first it was going to be based on enemies near the crystal, but that was an old variable that no longer worked. After some discussion with another team member I decided during any damage it would let the alert activate which would flash assuming damage is taken in proper intervals.

At the end the shield wound up having the design added in to sort of replace the default spell menu appearance. Now it has become the focus for any information that the player will need to know. As more elements get added we have decided the shield has the best option for alerting the player in most cases.

 

Current Shield:

Shield31817.PNG

Pause The Game Already

After a lot of trial and error the pause menu finally works. It is a little weird, but we needed one up and running so I found a way to do it. Instead of using set game paused in Unreal I wound up with changing the time dilation. It freezes everything and with updates frozen and check on the player we were finally able to get things moving, or well freezing.

The menu itself is simple, but for the player it was important to have it. After a lot of trial and error to get the code up and running it became clear that we’d face less issues if we changed the time dilation rather than the pause state. This was a solid learning experience for VR and what can and can’t be done in the ways expected.

Now that the game pauses and the main menu is up and running we have a new beast to tackle. Making them more thematic. After attending GDC and talking with others about their VR UI one idea I was offered was scaleform. Although Unreal has removed the support in UE4 plugins exist and from the research I’ve done it seems better suited. I was warned about potential performance issues, but according to Stefan we should be safe.

Over this next week I will be spending some time looking into scaleform and hopefully finding ways we can use it for a menu that suits the feeling the player should have when jumping into a game where you get to fight a bunch of skeletons and send the flying.

There is also the matter of newer requests, most commonly the idea of a tower under attack alert. This will take some solid time to piece together and get running. The hope is to have it within a week, but factoring in other requirements and classes it will take closer to two. The sooner that’s in the sooner we can move on to even more important things.

The Fox and The Dragon

So far this semester and technically for 2017, I have only had one game focused on for this blog. After a lot of work I am happy to discuss my other project. Right now a few of us are working on a small game targeted toward a younger audience. The idea is that the players will pick a fox or dragon at the start and begin their journey to save, rule, or ruin a kingdom. Choices have consequences and puzzles will pop up throughout as missions to give the player more involvement.

This game is one we discussed the previous semester and the idea of working together even earlier in efforts to have a nice game we’re proud of. Right now the idea is simple, a puzzle where the dragon will fend off enemies in order to keep others safe. The code behind it all is rather simple, first was the enemy.

Starting the enemies

So I have worked in Unity before, but the last time I had a few people around me who knew enough to help when I got stuck so I revisited it for this 2D adventure. Now the enemies were a little troubling to start since I hadn’t worked on AI to seek in quite a while. following the idea that the player would be stationary and the enemies would be coming it started out with a simple move to, or rather move towards. It worked and was enough I could test, but after a while I realized that this wasn’t enough. I needed to have the result of reaching the player and the enemy destroying itself when it happens for a fair attempt.

After these realizations my update went from one single line to enough to reach what we need. searchupdate

After that I moved on, but now with this puzzle or mini-game just about finished I realized one more aspect could improve this. Making each enemy a random color. This would keep the player in a clear mind that they were an enemy while waiting on the art and give some more variance to what a player sees each time an enemy appears.color-change

The only real struggle here was remembering the random for Unity colors was between 0 and 1.

Spawner Time

So the last time I used Unity we moved away from spawners since I had some issue with the logic of Unity spawning items. After the experience in Unreal and some more general knowledge the whole plan went by much faster. The spawner didn’t take much time and I was able to add in loading from a file. That part has been trickier just due to it not loading properly, but I have finally gotten it to a way it works well and will soon automate better than a switch for however many puzzles we have in one full game. The enemies spawn with a speed in a random range and this is going to be used to add even more to the puzzle experience.

Player

The player was by far the simplest thing although most likely the least efficient right now. I have thought of ways to improve efficency and will be implementing them as soon as time allows. Right now it locates any enemy on screen and will test how far they are. The time is minimal now, but more enemies means more time means this will be fixed at some point soon.

 

Up Next

We have a lot of plans for this game and hope to maybe even market it. The next step is the second puzzle type for the dragon and then starting on the fox options. For now This is what we have but it is running and we can officially demo it like we need to tomorrow.

Pausing Nightmare

Now that we have a mostly working main menu and spell menu I moved on to the options menu. The main menu has the options all hooked up and we are making headway with sound adjustments. The sliders posed an issue of size rather than implementation. It had to be clear where it was so a player could interact with it. The size fix was extremely obvious and something I had missed at first. After a little testing we got a slider size that was a good fit for a thing controlled by the player’s actual hand. Although some testing is needed for whether a snap to value is better or not is yet to be figured out.

The main menu completed made for an easy move to the pause menu. It was set up and can be implemented soon, at least if we could pause the game. Right now we face the trouble of Unreal Engine’s built in pause feature not working properly. Setting the pause value to true leads to the game pausing and the menu never rendering. A similar method in a normal game has worked in the past which is leading to some trouble in understanding. After talking with the other programmers we decided we may use a pseudo-pause and stop updating the enemies, the only thing really needed to be paused, and remove access to spells and teleportation. I am spending time now trying to find a similar issue in order to solve the problem.

A current plan to fix this is to use a tickable on pause option that exists as well. If that works we can make use of it for the main menu, weapon room, and a few other things as well. Acting under the assumption it works we can move on to making them look nicer, fit more with the theme and tying it all in to the game. At this point using the built in pause state will be helpful in working with the steam VR option of leaving a game running while returning to the menu. Once this menu is finalized we can work on the next parts, but this could take anywhere from a few minutes to a day to solve and implement. My hope is to finish it by the end of next week, but I will not let a goal rush a proper set up.

Menus Work

This week the main menu is finally working. We have a proper interaction up and running and options are ready to be put together and implemented. There was quite a lot of fun with Unreal Engine’s 3D widgets. At first I was hoping to set up the menu as I have done a lot of times, hiding the other menu items in order to have a single menu for everything until polishing it. So now we have a main menu that just needs to be implemented to the full game. We need to fix the options sliders, the current view makes the sliders far too small to actually interact with but it does work.

Now the spell menu was a little trickier. I continuously ran into an issue of input not registering as was needed. This caused some problems with testing early on. I did manage to get it working with help from the other programmers debugging and having run into similar issues previously. Once that was settled it came down to setting the whole system up. Due to poor planning, we have some improvements to make overall, but the system and menu is up. As far as current set up we have set up the spells to be a menu which you select from. After the spell is selected a symbol to display what it is appears on the shield and it will later change once used.

 

As of now base menus are ready and we can start to try and improve them. The next menu to put together is the pause menu. There is a lot of potential bugs following that one do to the nature of pausing a game like this. In reality we just need to freeze the skeleton’s updates which shouldn’t be too much of a change. The struggle comes in with keeping the menu in, or spawning it in, by the player but not so close they can’t use it. The next week will most likely fall to that menu since the others are functioning for the most part. The difficulty of what has been set is just the volume sliders. We should continue forward at a good pace and the majority of things should be ready within a few weeks. After that the current plan is I move on to polishing what I can, but there are things that could change a lot isn’t set in stone. I do look forward to following the path laid out for our team currently, we’re making progress at least and that’s what matters.

Spells…

This week I improved the spells and made some actual progress. The menu is in early stages but by the end of the next week I hope to have it properly set up.  The main menu and pause menu are finally being considered seriously as well.

The issue I face is really the 3D widgets, they limit and improve things all at once. It’s hard to work through bugs that don’t have a logical solution. The plan for now is binding spells to buttons and hoping for the best. After some consideration I realized an easy fix for binding one to be used under a universal button. I’ll be making tests on these for this week then switching to the main menu. I will most likely start it with a test on what set game paused does in VR, meaning if the player can move or not. Once that is learned we can make significant progress in the necessities and fast.

3D UI Adventures Truly Begin

This week was more UI and adjusting to 3D widgets in Unreal Engine 4. I did some research to find out how safe they were to use and although some features don’t work as intended, right now the job gets done. I spent most of my time working on an enemy alert system. There are some flaws but it is set to work properly for the most part. The enemy alert system isn’t very sophisticated, but should get the job done.

Enemy Alert

After setting up the exact position, which took quite a few tries, I got to work on making it work as an alert. The first step for that was binding the colors of the borders used to fill the edge of the player’s view. This became a little difficult when certain things weren’t running properly. After some experimentation where i managed to completely block our view I got something up and running kind of well. The issue became it didn’t fade out of view. The plan for our initial test of this system was a color based appear and fade. This could be the perfect way, or it could be edited later, but the borders on the edge were meant to fade. Instead thanks to some strange 3D widget bug I suppose they shrink out of view.

The system is working, when the color is changed they appear and shrink back out. The shrink is either a little too fast, or just the wrong thing. I spent a few hours debugging, changing when and where the alpha is changed, the rate it changes as well. Nothing seems to fix it yet, but at least it is solid. After some testing in the vive, I realized this doesn’t seem to be as big an issue as it could. For now it is testable, and we can work off of it. If we have to, we have positions and sizes to build cubes into the camera instead of the widget and change those colors to fade out. The error is minimal and can be taken care of later, once we have more elements settled.

Revisiting the Health Bar

I decided to take another look at our terrible health bar. At first, it seemed impossible to fix and I couldn’t find any bug. I hooked up a key press to cause myself damage in order to test it, and saw a proper health bar going from one end to the other. I ran the game on the vive and learned it was still broken, but now we knew it wasn’t because of the widget. I started to look around and our lead had me look at his code for the original one again, and there was the issue. The easiest way to position the health bar was to make it a child of the original in the editor, that was my mistake. Having forgotten to disconnect the scaling done on the original, the health bar was scaling down as damage was taken due to the parent. We disconnected the proper nodes and to no surprise it finally worked properly. This definitely makes it clear we need to double check things that were there previously are gone.

Next Goal

I could spend time trying to fix the enemy alert, but we have a bigger can of worms to open. We have spells and those have to have a proper menu. The current idea is a radial menu. This will definitely be quite the adventure, this menu will have to be changeable most likely during game-play, creating a slight challenge. From this week on that becomes the priority so spells can be given a proper consideration. Right now the plan is the player selects the spell they want ready to cast from the menu, but presses another button to cast it. I hope to complete this quickly in order to get us testing our game as fast as possible and give us the most options when it comes to improving game play.