It’s been a long time since Revelation RTS was talked about, so I figure I’d post an update to let you know what’s happening with it. For those who are new to the site or my projects: Revelation RTS is a real time strategy package under development for the Unity game engine. The goal of the project is to construct a framework that allows a real time strategy game to be built without writing all code from scratch and to create a system that allows procedural generation of game worlds, ecosystems, landscapes, and so on. In addition, a first game is being constructed to show off the RTS platform and be a great experience in its own right. If you’re curious to know where I left off back in August, take a look at this video which has some extra info for you.
The project is set to pick back up in March 2017.
I am likely going to be hiring another developer part time to assist with the project and accelerate its progress on my internal timeline. There is still no release date that I can shout out with confidence but the game is on the verge of starting to be, well, a real game. It was troubling to leave off with that kind of progress. In other words, the development is at a stage that is very exciting and I just cannot wait to start dev back up! The name of the game has still not yet been announced but that will be soon after development starts back up.
Possible Nintendo Switch release in the future…
Recently, I agreed to the Nintendo Developer NDA (non-disclosure agreement) which permits me some level of resources in developing games for Nintendo platforms. So, in addition to PC & Mac, along with a Linux release – I’m investigating how to bring the game to Nintendo platforms as well. At this time, there is the possibility of a Nintendo Switch release but do NOT consider this an official announcement or anything like that. I am still investigating what it will take to realistically bring the game to Nintendo consoles.
Where I really left off…
The project really left off with working on the procedural terrain system, which will be responsible for producing all the landscapes, forests, animal ecosystems, and resources that you find throughout any game session. It was a lot of work: I wrote a lot of code to create a grid of tiles that were meant to fit together so that units could run across them and eventually: trees, rocks, and other stuff could get spawned on them. I ran into a lot of trouble with that work, and ended up starting over completely. It is a good thing I did a while back too because I found a much more efficient way of generating those assets at runtime.
Now, the entire grid gets created much, much faster. Once I end up fitting other tiles together to create hills, cliffs, and other landscape elements all the work I put into the running speed of that algorithm will be quite worthwhile.
Aside from that, I was about to start work on an input management system to allow the player (or myself) to customize the controls in-game (as well as write code to better reference controls dynamically), and a game configuration screen that would allow you to specify different parameters about the game. Hopefully, that includes stuff like map types, difficulty, and some other things.
Consider this not an announcement that development has started back up but that it WILL continue and I have a plan in place to get the project moving again. It was important to get some other things done on the side in the meantime (and probably still until March 2017). Remember to catch me every week on the Digicast podcast, which will soon be available on both the Digicades YouTube channel and Soundcloud.
Earlier this week, the Digicades YouTube channel announced that they have a newcomer: me (Scott Lee)! Check out the series premiere of gameFINITY, a new topical show covering all things video games below:
gameFINITY will cover current events in the gaming industry, video game reviews from a game designer perspective, discussions about the state of the gaming market along with gamer trends, and more. I have a lot of plans to take this in a very awesome direction. Work begins this week on content to cover Nintendo’s recent release of Star Fox Zero.
Some other stuff that is in development for gameFINITY (but not necessarily guaranteed for release!):
Work on the real time strategy game continues – currently most of the work centers around the game’s terrain engine and generating random terrain. Yes, work has been going on and on with that particular piece for weeks but it will all be worth it in the end. More news on the real time strategy game will be coming here soon. If you haven’t already, follow Scott Free Capital and myself on Twitter.
Admittedly, not a lot got done on the real time strategy game in March. The work has instead progressed steadily toward a new website, which is still under the works. A lot of personal life stuff happened too: I ordered a new washer/dryer, I was sick with the flu for about a week, I took some time off following working overtime at the day job. Anyway, it feels good to be getting back to it.
The goal is now to get everything playable in a very real way – get the random map generation working correctly, get input management set up so players can decide their own hotkeys, adjust the loading/start up process which will take input from a game configuration screen, and ranged combat. These are all fairly big undertakings. And they are all critical.
This is a very important time in the project. This is, I believe, that trough of sorrow idea that you may have seen in project management graphs. It’s bad. It’s tough, it’s complex, it’s the time when things are probably the most frustrating and depressing. This is the time when I’m probably most likely to give up if I am to give up. But have no fear!
Content creation actually enters full swing around this time too. Once random maps are being created successfully and consistently then that means populating those maps with good stuff: creating the living universe. As it turns out, generating random maps is not as easy as I would have liked. You have to actually balance between real randomness, and semi-randomness. All in all, though, there is actually a very solid, rigid structure for creating these terrains.
The general process for this game involves 1) creating a random map “seed”, or in this case: a long number that indicates characteristics of the terrain itself, followed by 2) generating a series of tiles which are all perfectly spaced and connected at their edges to each other, containing varying degrees of elevation to create hills, cliffs, the shore sides, and of course water. The first step is actually fairly simple to produce thanks to the fact that there are already a large number of programmer tricks to get yourself some “random” numbers. Of course, they are not truly random, just giving off the illusion of appearing random. For a good explanation of random maps in games in general, the YouTuber Gnoggin made a great video a while back about it.
In the near future: Step 3) Populate the ground level terrain with a wide variety of Unity GameObjects, all of which may have interactivity for the game’s mechanics: rocks, all the blades of grass, trees which grow on their own using their own reproduction AI, fish in water (if I ever roll around to including this), and entire animal ecosystems (or populations and where members of that population should be placed). This too, is a huge step: it means essentially balancing everything for a given map type over and over again throughout development. It is really important and is arguably almost half the game itself. The game world you play in a real time strategy game is a huge factor in how the game plays.
The 4th and final step: 4) Generate player spawn points, which will determine where each player begins, including AI players. Within that process, there may be some adjustments that are made to the landscape. For instance, we might want to make sure that each player gets approximately the same available resources located around them to make the gameplay a little more fair.
From a certain standpoint it might make a lot of sense to stop calling these processes “random” right? It is actually a very structured process, just introduces a nice range of variability. All of this code being written is being done for essentially the very first map type. Creating additional map types for worlds with say, a lot of water with little islands, or a snow map, or mountains everywhere may require some additional algorithms (or scripts that work with the map seed really).
Anyway, I better get back to work! If you have any questions, feel free to message me on Twitter via @ScottFreeCap, or leave a comment here on the blog! I’ll try to get back to you during, you know, like, weekdays when I’m not working on the actual game so much. Thanks for reading!
The dawn of animation is an important step in any game development project. This past month, I discovered a tool called Mixamo that changed the pace of the project tremendously from the standpoint of animation. Some seriously cool stuff happened, including unit movement, melee attacks, and serious progress on getting rid of those infamous test cubes I have had thus far.
After emerging from hours and hours of struggles, getting a character fully rigged and configured to work with Unity’s Mecanim has finally set the stage for making some serious headway. So, how did I get here? Well, it did not go quite so perfectly as I would have liked it. There was a lot of learning.
First, I learned about the concept of root motion. Root motion is essentially referring to the actual movement an object may have when you animate it: the animation itself can have a translation in 3D space. As this applies to Unity’s Mecanim system, it means that Mecanim will handle looping that root motion where it believes it makes sense. Unfortunately, this is a big problem when you combine root motion, moving animation, and the A* Pathfinding Project. Because A* moves your unit on its own, you really do not need additional movement from animation.
In other words, your animation should play as your unit moves, your unit should not move as your animation plays.
So, without understanding root motion: my first attempt saw my human unit running off the map into infinite oblivion. It was a little hilarious to see. Once I made some tweaks to get Mark to not move in the animation itself, everything began to really turn out okay.
Mixamo, as you can see, is a way to turbo charge the animation progression in Unity related projects. It takes full advantage of the Mecanim system, and thanks to the ability to modify existing animations before importing: they make fantastic templates for creating full blown animations to be featured in-game. Or, still with the defaults and build out a rapid prototype.
Did I just endorse Mixamo? Kind of. Yeah, I pretty much did. It is a pretty awesome technology.
What lies next on the animation horizon are the working out of death and multiple attack animations. To see how things progress, remember to check back here to the Scott Free Capital blog often.
Some Side News – New Website Overhaul Coming!
A ScottFreeCapital.com overhaul is on its way. Since March of 2015, the fundamentals of this website have mostly been the same. Well, some work has begun on a new version that will be based on much more powerful technological foundations. Moreover, there are plans to integrate the website with new web applications that will tie directly into future products.