My next project for the Unreal engine will not be a game. It will be a special set of tools which artists can use to set up an interactive viewing environment to display their art in-engine. Users will setup various camera vantage points in their scene and link them together. The project will then use this to make a UI for end-users to be able to navigate and view the environment without having to use the complex control schemes you typically see in video games. The idea is that this UI will be ideal for both PC and touch device usage.
I’ll also be working on a new environment because doing environment art is relaxing for me
After completing my previous unreal engine project for the Tower Jam game jam I’m very comfortable with the game systems in the engine I hadn’t previously worked with such as AI, animation, UI and setting up a custom character. I decided for the next step I should pick a project that digs a lot deeper into the internals of the Unreal engine.
The major components to this project will be the following
Unreal editor modification for specific data types - In-editor custom visualization - Camera systems - Advanced Native/Blueprint communication - Advanced UMG - Slate UI framework - Authoring a plugin for the Unreal engine
I don’t intend for this to be a particularly large project ultimately. I’m anticipating a lot of difficultylearning how to build and deploy a clean plugin for the Unreal engine but I’ve been surprised at how easy things have been in the past so maybe I’ll get lucky.
Here is my current set of milestones. Anything that is crossed out is complete already so as you can see I’m currently finishing up the second milestone.
Implement first version of a vantage point and vantage point manager. The vantage point represent the view at a specific position while the manager handles transitioning between each vantage point. - Get vantage point transitions working. Use existing unreal camera blending logic if possible.
Setup basic UI with thumbnails that represent a vantage point view.
Setup bare bones scene for testing.
User can select the first vantage point to use when start up the game rather than the first camera in the vantage point array.
Make sure that we also modify the player start to be near to the vantage point so that the game doesn’t start up with a crazy camera blend involving the camera moving across the entire level.
Setup basic UI with thumbnails that represent a vantage point view. Use render targets so that the thumbnails show what they represent. - Animate buttons in and out of the scene when transitions occur.
Have the buttons slide off the left side of the screen when a transition occurs. - Have a small button on the bottom left of the screen to show/hide thumbnails.
Spend a small amount of time working on the test scene.
In editor representation of the cameras transition relations to each other. See image below.
Customize details panel for editing vantage points and transition relationships. See image.
For human interest here are the first 2 pages I wrote up for the initial design of this project before moving over to Evernote.
Next here is some evolution of my test scene. I wanted to make a nice modern beach house hanging off a cliff. Sort of like a lot of the really fancy houses you might think of on the coastline of california. Here is what it first looked like.
Turns out I didn’t like the tall protrusion in the middle of the scene so I removed it for a flatter layout. I also adjusted the lighting to roughly match the direction I’m intending to have for the final project. I want it to be like a sun setting towards the deck of the house.
Finally I started some work on the back portion of the deck. This is where the open layout of the main area of the house is. It transitions into the deck with the idea that almost anywhere in the house always has a nice view of the ocean. The separated potion is the master bedroom.
Tags: levelviz unreal4
What I’ve been playing #005
2016-03-14 1:52 PM
I haven’t been able to play FPS games for a long time. This is due to me playing a lot of FPS’s in my late teens and early 20’s coupled with the fact I actively developed FPS games from my late teens to my late 20’s. I totally burned out on the genre. I also carry the opinion that while many FPS games have gotten more interesting from a story perspective, they have regressed from a basic gameplay (or gamefeel as some might say) standpoint. I still feel like Doom is one of the pinnacles of design in regards to just getting the right feel for movement and combat in an FPS. I also find the level design to be a lot more interesting. This is probably why I’m still able to go back and play Doom to this day.
I decided one early morning to give Shadow Warrior a try. It was just sitting there in my Steam library. Yet another game I bought on a Steam sale with the vague notion I might play it some day.
I have to say I’m pretty happy with this game. The general fighting mechanics and flow of the game feel quite nice. Thegame hasexplicit level based design, complete with kill/item/secret percentages displayed in a post-level completion screen. Very much a throwback to the old Doom shareware era FPS games. It’s still a little linear but better than most modern FPS level design.
The sword mechanics are pretty good. Good enough that I generally enjoy using the sword enough to make it one of my primary weapons. It’s continually upgradable and has a series of special moves that involve double tapping a direction then pressing the left or right mouse button to unleash some attacks such as an area of effect attack that immobilizes all enemies around you in middair. I didn’t expect to ever really enjoy a melee weaponthis much in an FPS.
The environments are also verynice. They might not win any overall fidelity awards but the composition and theme of the levels is always interesting and varied which is much more important to me than boring but technically proficient environments. The levels feel as if the designers and artists put their personal touch on them. Much like some older FPS’s and FPS mods from a time where there was less scrutiny from art direction which caused environments to feel to homogenized.
The story is pretty stupid as you would expect from a game like this although it wasn’t as bad as I thought it would be. It’s been a long time since I played the original Shadow Warrior but if my memory serves correctly this version isn’t as inane as the original. The dialogue is still bad but not nearly as embarrassingly bad as the original. My memory might be misleading me though, it’s been about 20 years since I played the original game.
If there was one thing I would like to see in the game, it’s an option to have a ultra high quality cherry blossom tree model
Rocket League is pure competitive fun and the most fun I’ve ever had playing a soccer video game. Who would have thought mixing high powered cars and soccer together would work so well?
The online matchmaking portion of the game is very well designed and implemented. On both the backend and frontend.
Finding a game rarely takes me more than a minute and after completing a game I don’t have to go back to the main menu and find another game. The frontend flow assumes I’m going to play another game so all I have to do is hit the accept button to say that I want to keep playing. From that point the game uses all the other players in my game who pressed accept to keep playing to create the next game. The matchmaking backend then fills in the empty slots from people who left the game and I’m back in and playing my next game very quickly.The Rocket League developers obviously understand how important it is to minimize the waiting and downtime between actual gameplay and they did a great job at addressing these issues.
TowerJam 005 Final entry and AI systems
2016-02-23 8:13 AM
TowerJam 2016 is complete.
At the time I decided to do the jam my schedule was a lot more free . Unfortunately life happened, my workload increased and I had a bout with the worst sickness I recall every having in my lifetime. I could have easily given up and not submitted to the jam but I decided instead to massively scope down to get something complete and submitted. I consider this a big victory for myself.
The game is not particularly fun, in fact I would recommend watching a youtube video of the game being played rather than downloading and playing the game. In fact you can do that right here!
Here’s some screenshots of the final game.
One of the development goals for this jam was to really dig into the aspects of the Unreal engine I’m unfamiliar with. This includes but is not limited to :
Character animation state machines - AI – Blackboards - AI – Tree editor - Matinee - The C# build system - Input abstraction - Blendspaces - UMG
I can now say I’m far more familiar with these systems. I’m so glad I dived into AI and character animation state machines because I previously feared working with them due to unfamiliarity with those types of systems but now that I understand them I feel I’m really able to use them effectively now. In fact I’m now wondering why I was so fearful of learning them in the first place.
In fact I think after this project, future projects in the Unreal engine will be more about making the game rather than spending most of my time learning how to do something in the engine itself. Unreal has a pretty steep learning curve if you want a holistic education but it’s well worth the time. I’ve used other engines in the past where getting something functional is quite easy but this comes at the cost of a project being tough to maintain when it starts to grow in size. In some cases the issues at scale are so bad that ultimately not using an engine would have actually been less time consuming. Unreal seems to handle this well and the dearth of large scale games that have already been released on the engine over the past decade is further proof it’s a capable engine.
The final bits of work I had to do to get my game complete was to implement an enemy. This means I had to learn how AI works in Unreal. Lucklily from a conceptual standpoint the methods Unreal uses to implement AI are very standard in both the game and AI world. I’d been exposed to the concept of blackboards in previous non-game related jobs I’ve had and behavior trees I’ve seen used in other engines I’ve worked with. That said I still had to learn how to use them in the context of Unreal.
Now I’m far from a professional AI programmer so take my opinion with a grain of salt but I think Unreal has done a very good job implementing tooling for AI via their blackboard and behavior tree editors.
A blackboard is essentially a set of key/value pairs where the value is a variant. In some implementations I’ve used the type of value is unknown so you have to remember what the type is and apply appropriate casts when getting and setting values from the blackboard.
Here’s what a blackboard looks like. As you can see it’s just a group of data that we wish to track. Unlike other blackboards I’ve used I can deduce the type of a value to some degree.
InUnreal implementing a blackboard was dead simple. I merely define the data that I’m interested in tracking and then periodically update the data in my enemy controller blueprint. From there I bind a blackboard to a behavior tree and use the data in the blackboard to make decisions in the behavior tree.
Here’s the relevant section of my controller where I update and set values in my blackboard. What I’m doing here is updating the “Target” value every update along the bottom line of execution.
The behavior tree editor was easy enough to use after I got past some roadblocks. I have to admit for a few hours I was quite stuck. This is partially due to some lacking documentation and partially due to my inexperience with the editor. My main issue was I wasn’t able to determine how to setup various conditional tests in a behavior tree node. It was only after looking around the unreal forums at screenshots of other peoples trees that I realized a tree node can be modified with decorators to execute the conditional logic to determine whether a node should be traversed or not. For instance I would have a node that tells the enemy to follow a target if they are within range of said target.
The other gotcha for the behavior tree is that task nodes such as an “approach target” task are only visible to be added to the tree if the appropriate type exists in the accompanying blackboard. So for the “approach target” node to show up I need an actor reference node in my blackboard. This makes sense but it was initially confusing to me as I was merely looking for the existence of the task when playing with the editor. Now that I know this restriction I’ll make sure next time I want to look for a pre-defined task that I have what I believe to be the necessary data already in my blackboard.
Here is what my enemy behavior tree looked at the end of the project. The decorator value for determining whether or not the enemy should approach is a blackboard value set from the controller blueprint. I suspect I could have gotten rid of that bool and replaced on a validity check to the target actor reference. I will definitely look into doing that in the future (the less state the better).
You can learn more about blackboard and behavior trees here :