This newsletter includes
My personal opinion on forthcoming Valve Index VR Set
ROT-8 Rover explained
Unreal Engine development with Git
Why I think Valve Index VR Set is bad for VR development
You have probably seen the news already - Valve has released the full specs of its forthcoming Valve Index VR Set. What I think about it as a developer. I have to say that I am disappointed, and I strongly think that it is something we do not need at this moment. In the future, yes, but not right now. It clearly shows that Valve does not understand the state of VR when it is only interested in selling high-end gadgets to gadget freaks. Let me explain my point of view as a VR developer, not as a gadget freak.
Valve uses the words "high fidelity" to describe its new VR set, and that it is. It has a bigger resolution than original Vive and 120 Hz refresh rate with experimental 144 Hz mode. There are also other technical improvements. While all gadget lover fanboys are probably drooling all over it, I am not. Bigger resolution and faster refresh rate should make VR games better, don't they? Well… no, they do not. Not really.
I could compare this with a situation where you buy a Ferrari to drive within city limits in Finland. Ferrari has considerable top speed but there is a speed limit of 40 km/h in the city. Well, you may collect lots of looks with your shining car, but otherwise, it does not make you go any faster than someone driving a Skoda. It does not even help to go outside the city since every road has a speed limit between 60-120 km/h. If you want to go somewhere fast, the problem is not your car (all of them have a top speed of more than 120 km/h), the real problem is the road network. You need roads that allow you to drive faster. Otherwise, your high-end car is just a waste of money.
What I mean with this, is that you do not solve current problems in VR by making VR sets that demand even more performance, when you should concentrate on technology and algorithms that would demand less performance on current CPUs and GPUs. Valve Index is like that Ferrari, which is stuck on those slow-paced roads because the roads do not change when you buy a new fast car.
From a developers point of view, this is even more horrifying. For years people have complained that why there is no or very few VR games with good graphics, complex and immersive gameplay, or games with large worlds. The reason is quite simple. It is very hard to squeeze all that, and keep the game running at 90 FPS which is the expected minimum. Now Index rises the bar to that of 120 FPS.
As an example, we had to do an astounding amount of optimization to get Planetrism running at 90 FPS with realistic graphics, dynamic lighting, large 3D world and complex game world with robots and NPCs demanding lots of CPU cycles with their AI routines. And there really is not much in the reserve, not enough that 120 FPS would be possible.
Someone probably argues that Index is compatible with 90 FPS games. True, but that only makes things worse again. I can already hear gamers whining and complaining "why doesn't this game run on 120 FPS. Bad developers, bad game". Of course, people expect to use those features they paid for. If you buy an HMD that runs 120 FPS, that is what you want. Gamers do not understand the concept "in the future (there will be 120 FPS games)", they want it now.
In my opinion, 90 FPS is quite enough. First time I used Vive, and even today, I still get that immersive feeling, on such level that is possible with current quite crude VR technology. It is totally good for gaming.
Another part of the problem is the new hand controllers. Yes, they are very high-tech and enable the implementation of quite complex interactions. But that is another problem. They are one more entry in the long line of unique controllers with all kinds of features, buttons, and sensors that other controllers do not have. And of course, people expect that they are supported. For small studios limiting factor is not just money, but most importantly it is time. And implementing different controllers with some special features will take time. Lots of time with all that coding and testing.
Don't get me wrong, I really think technology should advance. But the problem is that it should advance as the whole package. This isn't it. Index is something that needs other software and hardware that is not available yet. Maybe in a couple of years, but now it just creates unnecessary extra demands for developers who are wrestling with dozens of optimization problems to get their quality VR games running on current hardware.
For two years - at least - the VR scene has suffered from slow growth in the user base, and the main reason is the fact that the VR hardware scene is like a Wild West. Each manufacturer has its own "solution", which is different than others. This leads to the situation where hardware is poorly optimized, and small teams are not able to support the special features in every different VR set.
Bigger studios have lost their interest in VR almost totally. Right now we need more unification in hardware and software and cheaper but adequate hardware which should be easy to adapt and use. In my point of view, Oculus is now on the right track with their new sets and hopefully, it will increase the user base. Because the VR scene needs a bigger user base to convince more studios - small and especially the big ones - to invest in developing VR games. Forget the gadget freaks, they are a minority group that is more interested in bragging with their hi-end hardware and focus on basic common gamers by offering an affordable and easily understandable and adaptable entry point for VR gaming.
What we really need right now is optimization in current VR technology - such optimization that developers had more room to squeeze game mechanics, AI and large highly detailed worlds into that 90 FPS limit. Without such advancement, there is very little hope that VR games could evolve onto the same level as desktop PC games. Also, VR hardware should evolve in a unified way, towards a common standard instead of a dozen of unique technological solutions.
So in my opinion Valve is shooting VR scene on the foot and head with this new hardware. It will just add unnecessary diversification on hardware that developers should support. And for gamers it will give false promises about super high fidelity VR gaming, that is impossible on current affordable PC systems - unless you want to play just those simple arcade shooters, where you stand and shoot some low-level simple polygon models.
ROT-8 Rover overview
While we were developing Planetrism we suddenly had a (totally crazy) idea that those cube shaped ROT-8 survey robots could make a game of their own. In Planetrism they are AI controlled, and although the player may issue some tasks to them, they move and operate on their own. Also, their movement is physics based which usually is a basis for an interesting platform and skill-based games.
So I made a quick demo with a couple of simple components, and we found out that it could be a really fun game. Since Planetrism is a very long and large project, we also welcomed some diversion from it and made this plan that we will develop both.
Thus we started to design the ROT-8 Rover game for real. As everyone knows, the real game is more than just the basic mechanisms. There have to be clear goals for player, controls that work and make playing fun, and many other things. What we first had in mind, was some simple mobile game with one-finger controls, but quite soon we found out that it just does not work that way. It would be impossible in this case, mainly due to control problems.
The whole idea in this game is to control and steer a robot with totally physics-based movement. The robot moves only by turning itself with internal gyros in quick succession. There are robots like this in real life. Not as fast as ours, but the principle is the same. Additionally, the robot has weak jets based on pressurized air, which give it a limited jumping and hovering capability. Thus the game is very acrobatic, and the player can do all kinds of stunts.
Since the robot is AI controlled in Planetrism universe and used for various purposes, we thought that the game could involve
training of those robots
single player exploration missions with some puzzle and adventure elements
co-operative multiplayer missions
multiplayer ballgame
other multiplayer game modes like capture the flag, domination, tag game, etc.
In a way, the game is about how an individual ROT-8's AI (the player) starts at a basic level and gradually learns to survive and perform various tasks in different environments. Other game modes teach teamwork and survival in hostile situations and extreme responses.
Single-player exploration missions test players steering skills and decision making. Player has to collect data and information from a sector within a time limit. When a sufficient amount is collected, the player is guided to pick up point and retrieved by a drone. The player may gain extra time for mission by picking up samples.
The environment is very demanding and dangerous, and it is quite certain that the robot will suffer damage and malfunctions. Movement and other actions use energy, and while the robot has solar cells integrated into its outer shell, they provide an only minimal amount of energy - sufficient to keep batteries on the operating level if the robot moves at a relatively slow pace. Fast movement, hovering and jumping use lots of energy. In emergency situations the robot may send a signal to a drone, that can dispatch battery packs and nanotechnology repair units.
Right now we are developing different multiplayer game modes. Ballgame mode is mostly done, and you can see how it works in several videos I have streamed. Capture the flag and Domination modes are under heavy development, and they bring weapons and other mechanics into play.
Development of ROT-8 has been really interesting diversion since the game is completely different than Planetrism. I have had wonderful time implementing
an intelligent camera system,
a game control system that works on a touch screen, mouse + keyboard and gamepad,
spectator cameras for multiplayer,
AI robots, weapon systems, and other features.
Programming a multiplayer networking system is actually relatively easy with Unreal Engine - easier than most people think - but even then it is something that I recommend only for experienced programmers who already understand how Unreal Engine works. Multiplayer has so many programming layers that you need to understand and keep in mind constantly. Also, the in-built replication framework is not so automatic as many people think. But I will tell more about those aspects in future newsletters.
Unreal Engine, Source Control, and Git
Source control is one of the most important things in collaborative software development. Even if you would be the sole developer, it pays to use source control. That way, every modification you make in the code, assets, etc, is recorded in a repository. If you make a catastrophic mistake, you can easily revert back to a previous functioning version with a couple of commands. There are many different source control software available, like SVN, etc, but in this case, I will focus on Git.
First of all, I have to point out, that the workflow I describe here is a mixture of Git command line and Git plugin integrated into Unreal Editor. Also, please understand that it is a workflow that suits me. It is not necessarily the right or best one for you.
Git command line
Why use Git on the command line? Quite simply, you can use the command line in almost all situations. If you make a remote connection to a server, it is quite probable that you are using ssh terminal connection instead of remote desktop connection. With a proper app, you can control git through command line on a mobile phone, even. Also, the git command line is the same on every platform - Windows, MacOS, and Linux. I prefer the command line, and generally, I don't use any Git GUI Tools. If you do, it is your choice, but these instructions are intended for command line users.
When you want to learn how Git works, the best thing is to create a project that has no other purpose. You can create a dummy starter project from UE Editor, and practice with that. Then you can practice any kind of situation, make merge conflicts on purpose, and try to solve it. There is no fear of screwing everything completely, since you can always start again, from scratch.
I assume that you already have a basic understanding of what Git is - perhaps you have used it before - and you already know what repository is, and some basic actions. If you do not, then I suggest looking Git documentation for basics.
The practice is the best educator. This way you won't screw up a real live project, and someone has to use his valuable development time to correct mistakes you did because you did not make your home lessons. One thing that irritates me most, are those whiners who make mistakes because they did not bother to learn things beforehand on their own time, and then they scream others to help them, while they could try to find the solution to the mistake themselves. I usually have no patience with these types. If someone has already tried to find a solution from several sources, then I can gladly help - if I can.
Source Control Plugin
When using git in a game development project that is based on Unreal Engine, you can handle the source control outside the UE Editor. In several projects, I used command line Git only, and it worked if you were careful. However, there was one area, namely Blueprints, where you could have problems especially if you encountered a merge conflict.
Every UE project has at least a couple of Blueprints, and programming with Blueprints is just the same programming like C++, except that it is presented visually. Although it is stored as text, it is in a format that is not very human readable, and you cannot solve Blueprint merge conflicts in a text editor.
Fortunately, UE Editor has a Source Control plugin, which handles most of the source control routines and gives the user the possibility to solve Blueprint merge conflicts. Source control plugin is installed by default, all you have to do is to activate it in your project. If you have already installed Git and activated your repository, the source control plugin will detect your settings. You can find installation instructions here.
Beneficial But Not Perfect
There are many benefits from Source Control Plugin. First of all, it is integrated into UE Editor, and you can do most of the common Git operations within the editor. You can easily find what files you have changed or are working on, and you can commit your work either as individual files or a group of files. It is also a good thing, that having Source Control Plugin activated does not interfere with other Git tools, because UE Source Control Plugin is just another visual Git tool.
As I said, you can do many Git operations within the editor, but not all of them. You still have to use either Git command line or some other tool. Most importantly you cannot push your commits to project repository. You can commit your changes, but they will stay only on your PC unless you push them manually.
Also, the plugin is not informative enough at least for my taste. While you can pull the latest version of an individual asset from the repository, it does not work the way I want. What is very confusing is that it will pull the latest version and seemingly overwrite anything you have done. But just seemingly. Actually, your work is still there but unmerged, although the editor does not inform you about this. Thus, I prefer to do fetching, merging and pulling mostly on the command line.
My workflow
As I said above, I use both Git command line and UE Source Control. My basic workflow in a situation where there is just one main branch in the project is as follows.
I usually check the current state of the central repository with
git fetch
followed with
git status
This will tell me if there is anything new in the central repository. If the status shows that I am behind, then I will check what has changed with
git diff origin/master
or
git diff --name-status origin/master
depending on how detailed information I want. This way I can check if there are changes in any of the files I am working on and thus, possible merge conflicts. If all changes are assets I am not working on, then I just merge everything with
git merge
And I am good to go. After a pull the UE Editor may notice that certain assets have changed (because someone else has made changes and committed them into the repository), it will ask if I want to reimport them. I always answer NO, unless I have just added them myself. I found out that reimporting assets that other people have imported into the project is not necessary, but it also alters the file, and you will see them changed in source control status, although nothing has really changed.
Merge conflict
However, if someone has made changes in the assets I am working, then I know there will be merge conflicts, probably. First I check if I have any uncommitted changes on those files
git status -s
If I do, then I will commit them using the source control tool in UE Editor. I just commit those files, and then I still have to do
git merge
and it will merge all the files it can. If there is a conflict then Git will inform about that on command line output. If it is a Blueprint, then I have to use UE Editor to solve that. Source Control plugin provides a visual diff tool to see how my version of Blueprint differs from the one I just pulled from the repository.
After I have solved the conflict, I have to save the file and commit it. In this case, I usually do it on the command line with
git add /Content/Path/To/File.uasset
to mark it as solved, and then put my work in sync with
git rebase --continue
Commit changes
When I have worked on files, eventually I should synchronize them with the central repository, so that others may use them. When and how often I do this, depends a lot on how important the asset is. There is one rule that I follow - you can commit on your local repo any changes you think are necessary, but I only push (into the central repository) stuff that really works, and does not interfere with other assets.
Commits are really easy with Source Control Plugin. You can either commit in several files together or individual files. Right-clicking a file on Content Browser with show the source control actions, a pop-up window appears, and you can write change notes. You can do as many commits as you want and then push them into the central repository.
Before I sync my work with the central repository, I usually check its status with
git fetch
and then
git status
If I am not behind, then I just sync everything into the repository with
git push
However, if I am behind, then I have to first merge those new changes with my work. That is basically just what I described above.
This is my basic workflow, but there is still much more that every user should know about Git in a Unreal Engine development project. But I will save that for future newsletters.