Starting with UDK and venturing in to Unreal Script.
After working in RPG Maker and getting a grasp on Valve’s Hammer Editor I decided I wanted to pursue a standalone 3D creation utility. Having watched many tutorials and created a basic map using the editor with Unreal Tournament 3, I decided to give the UDK a go. Many of the things I learned in the Unreal Tournament 3 editor carried over to UDK so straight away I was presented with a familiar interface. This was great for level creation however there was still so much more to UDK that I never had to learn with Unreal Tournament 3. Items such as importing resources, creating materials, and working with skeletal mesh physics and animations to name a few.
I would learn to address these over the coming weeks as I decided on the type of game I wanted to create. Given the abundance of first-person shooters churned out with UDK, I wanted to take a slightly different approach; the platformer (which there is also no shortage of using UDK). Given I am far too inexperienced to create a platformer akin to Mario 64 or Banjo-Kazooie, I decided to go with the sidescrolling platformer route – ala Contra. I eventually came across a blog on the Vectorform Labs website with some great starter code to create a sidescrolling shooter through UnrealScript. It was implementing this when the realization set in that I would need to gain at least a basic understanding of this programming language.
As I began working with the code, it started to make more and more sense to me. Expanding from the existing (Unreal Tournament) classes certainly made things easier as there was already a solid code base to work off of. Given the Vectorform sidescroller extended these, a lot of the functionality was already done. I just needed to expand on it to get the desired results. The more I worked with this sidescroller concept, the more I wanted to expand on it and utilize other perspectives.
Eventually I came across the Camera technical guide on the Unreal Developer Network which provided not just a sidescroll view, but also a top down, Isometric, third-person and of course the first-person perspectives all in a single Pawn/Player Controller. The code was designed so that one could switch between them in real-time, updating both the camera and controls for each of the different views when called. It was then that I decided to use this as a base for my Pawn and Player Controller classes, integrating only the piece of code that restricts the player to a particular Y-coordinate from the Vectorform Labs tutorial for the Sidescroll sections and the basic HUD.
After the basic control was established I had moved on to building on top of the code base to expand the functionality. This included displaying additional information on the HUD, creating pickups that work without needing to manually set every one up through Kismet, and a save system. I expanded many other classes from their default UT classes, including the vehicles, weapons, and projectile classes to make modifications to them. I broke up the weapons so that each only had a single fire, altered colors, varying fire rates, and automatic recharging. I also changed the core mechanic so that the player could only have one weapon in their possession at a time. Originally brought on while implementing the save system (as saving inventory proved to be far more complicated than it should have been) but as time went on, I enjoyed this option more.
Removing the illusion of freedom.
The general premise for the game was that there is going to be a robotic uprise (see i,Robot) where the player would be sent to investigate the production headquarters. My original concept for this project was to create a large landscape “overworld” where the player would approach different locations and enter said level (similar to a role playing game) eventually working their way to this main facility. As I began to create this, I realized that it was more of an illusion of freedom as I would still require the player to complete certain levels before they could enter others.
During this time I had also began playing Super Mario 64 again and decided that I loved the idea of just creating a hub world (ala Peach’s castle) where the player would need to collect ‘X’ number of items before they could progress. Given the already-linear premise of the overworld, I decided to shift from an overworld to the entire game taking place within the robot facility. Here the player would need collect Circuit Chips (equivalent to the power stars of Mario 64) in order to open up additional areas of the facility. While I decided to scrap the overworld, I still wanted an outdoor area. So I greatly reduced the size of the landscape and used it to make the area surrounding the robotics facility. This would be where the game begins, requiring the player find a way in to the facility to begin their investigation.
Once inside, they would stumble upon the area used to train the robots prior to the uprising; this would also serve as an introduction to the controls, abilities and various perspectives of the levels ahead. Although it is a formal training level, I tried to incorporate it in to the theme of the game as to not come off “too novice”. After completing this they would be taken to the hub world, where they could then begin to collect the Circuit Chips and progress through the game. The idea was that the manufacturer would have portals leading to various environments which they would use to collect various materials to construct their robots. This was a rough idea, but I did not want to restrict the player to just industrial-themed levels (as would be expected in a facility like this) and instead allow for a more colorful palette of environments. I have recently made a video of the roughly whiteboxed levels at this stage to flow and load as I intended them in the final product:
The transition to Unity
As I began to implement the hub world mechanics of the game, I began to wish this was more of a mid-90’s platformer instead of a hybrid platformer/Contra/Unreal-style game. Instead of weapons and shooting, there would be jumping and stomping. Instead of dark detailed levels, there would be simple colorful exploration.
I had always had an interest in Unity but never truly downloaded and explored it. I was content with UDK, until I discovered the Complete Physics Platformer Kit on the asset store. This was everything I wanted to accomplish in UDK but couldn’t due to my limited knowledge of Unreal Script. I could have vested more time in to learning it, but given its abandonment in Unreal Engine 4, decided that it would not be worth it. Not to mention this kit provided me with a great starting point with a lot of the core functionality already implemented. After having played the web player demo of the kit, I was convinced that I wanted to learn more about Unity.
Given that Unity offers a free version which is more than capable of creating great games, I finally took the plunge and installed it. It was definitely a bit overwhelming at first given my comfort with the quad-view editors (UDK and Hammer) and lack of familiarity with how projects are laid-out and how to create anything, but a handful of online tutorial videos later and I was at a near-UDK comfort level. It was then that I began to miss a lof of the core features included with UDK; namely Kismet and Matinee. This is where the only drawbacks I have found with Unity come in to play. In order to get a lot of the “systems” that UDK offers in Unity, you will need to purchase (roughly) a couple hundred dollars worth of assets; unless of course you want to stick strictly to coding and scripting.
- PlayMaker/uScript replace Kismet
- Shader Forge replaces the Material Editor
- Camera Path Animator “replaces” Matinee
- Miscellaneous assets replace the stock UDK assets
The difference here however is the Asset Store itself. There are limitless items available to purchase ranging from editor extensions to character models to particle effects. For someone like me who wants to work on their own project and isn’t a pro at 3D modeling, rigging, animating and coding, access to the asset store alone was worth the switch.
I get to feel more and more comfortable with Unity with each passing day, which finally makes me realize what all the talk surrounding it was for. No doubt I may find my way back to UDK again in the future, but it will likely be a ways off given the number of game types I can already see being both easy and possible with Unity.