Into the Unknown: UDK Part 4

I’ve finally reached that breaking point where I am comfortable with the Unreal Engine. I may not have knowledge of every aspect, but I am finally understanding the basic axioms driving the inner workings, which allows me to intuitively understand where to look when I am stumped. The unfixable problems are falling away as my problem-solving abilities increase with respect to the environment. When you are utterly clueless about the engine, it can be difficult to know what kind of help to look for.

So in the past few weeks I began working on the project again. This time, I would build up an easy, lightweight framework from the UDK (rather than UT) packages — that is, I started out with much less pre-built functionality so that I could understand everything that was going on.

I succeeded. So far I’ve built a basic Pawn framework (Pawns are objects controlled by players or AI) with a custom crouch system and an Inventory Manager that better suits my needs. I’m also working on a Weapon system, although I haven’t implemented sounds, particle effects, etc. My HUD system is minimal, but so far that is all I need.

When I need to, I go to the UT packages and look at their implementations. However, the number of times I’ve copied and cut down code has decreased dramatically. Now I can write my own code with confidence that it does everything I want it to (note that although I am perfectly comfortable coding, it is more about knowing which function calls go where in the logic chain, and what to reference).

Note that I don’t have grenades, vehicles, sounds, shields, AI, other characters, or environments yet. However, I’m more comfortable having a small, solid base of functionality that I completely understand, rather than a thin spread of half-implemented, opaque features. Down one road lies abandonment, down the other lies slow but steady plodding to completion.

Advertisements

The Future of the Source Engine

Valve’s Source and GoldenSource engines and Epic’s Unreal engines have had a long, acrimonious feud. Both Golden Source and the Unreal Engine debuted in 1998 in Half Life and Unreal, respectively. Both were considered revolutionary games at the time. Unreal blew technical and graphical expectations out of the water. Half Life left a legacy as one of the most influential games in the FPS genre.

Unreal Engine screenshot Unreal Engine screenshot
i2Zan0DmFkTfy Golden Source screenshot

Fast forward 6 years. Valve, in the meantime, has released Team Fortress Classic and Counterstrike, both extremely revolutionary games. The Unreal and Unreal 2 engines (the latter was released 2 years prior) had become extremely popular platforms for game developers, mostly because of the engines’ notable modularity and room for modification.

In 2004, Valve debuts the Source engine with Half Life 2, a ground breaking game that completely demolishes competition and sets a long-lasting legacy in terms of story, gameplay, and graphics. For comparison, Unreal Tournament 2004 was published the same year.

Unreal Engine 2 screenshot Source screenshot

In another 7 years, Unreal Engine 3 has been released and games like Gears of War and Batman: Arkham City have been developed using it. Valve has just published their first widely supported game, Portal 2. The Source engine has been evolved over the years, and many graphical upgrades have been applied along with compatibility with major game consoles.

Batman: AC screenshot
screenshot-2

However, it becomes readily apparent that the visual styles of these two engines have diverged in the years since 1998. The Unreal line of engines have supported games like Bioshock and Mass Effect, but have also bourn the brunt of AAA games. Such games are known for their muted brown-grey color pallete, uninteresting story, and factory-made gameplay. Unreal Engine games are commonly criticized for having character models that look “plastic” (a result of game developers setting specular too high on materials), awkward character animations, and overuse of lens flares and bloom.

Games on the Source engine, on the other hand, consistently revolutionize some aspect of gaming. For example, Team Fortress 2, Portal, and Left 4 Dead are widely known for innovative gameplay. Unfortunately, Valve has lagged behind in terms of pushing the graphical frontier. Half Life 2 was smashingly good for its time, much in the same way that Halo stunned the gaming world back in 2001. However, every Source game since its debut has looked more and more aged.

Even worse, developers are driven away from using the Source engine due to a set of tools that have barely evolved since they were developed in 1998. Hammer, the level creation program, and Face Poser, the character animation blender, are unwieldy and unfinished; Source SDK tools are notorious for their bugs and frequent crashes.

Conversely, the Unreal toolset is streamlined and easy to jump into. This appeal has drawn more and more amateurs and professional developers alike. The editor allows you to pop right into the game to see changes, whereas the Source engine still requires maps to be compiled (which can take minutes) in order for the most recent revision to be played. Unreal’s deformable meshes dwarf the Source engine’s awkward displacement system.

However, I have a feeling that a couple of factors are going to come together and boost both engines out of the recent stigma they have incurred. The biggest factor is that at some point the AAA game industry is going to collapse. The other critical event is Half Life 3.

Yes! Do I know something you don’t? Have I heard a rumor lurking the Internet about this mysterious game? No. But I do know history. And that is more useful than all the forum threads in the universe.

Half Life was released in 1998. Half Life 2 was released in 2004. Episode 2 was released in 2007. Half Life 2 took 6 years to develop, despite being on a side burner for some of that time. By extrapolation, Half Life 3 should be nearing release in the next 2 years. However, circumstances are different.

The Source engine was developed FOR Half Life 2. Graphics were updated. But the toolset remained the same. In the time between HL2 and now, Valve has been exploring other genres. Team Fortress 2, Portal 2, and Left 4 Dead 2 all took a portion of the company’s resources. In addition, that last few years have been spent intensively on developing Dota 2 (which, by the way, was the cause of the free release of Alien Swarm). The second Counterstrike was contracted out. So Half Life 3 has been a side project, no doubt going through constant revisions and new directions.

However, unless Valve is going to release Day of Defeat 2 or Ricochet 2 (yeah right) in 2013, production on Half Life 3 is going to kick into high gear. There is one fact that drives me to believe even more heavily in this theory.

Since 2011, and probably even earlier, Valve has been pumping a huge amount of effort into redesigning their entire suite of development tools. It had become readily apparent to everyone at the company that the outdated tools were making it impossible to develop games efficiently.

“Oh yeah, we’re spending a tremendous amount of time on tools right now. So, our current tools are… very painful, so we probably are spending more time on tools development now than anything else and when we’re ready to ship those I think everybody’s life will get a lot better. Just way too hard to develop content right now, both for ourselves and for third-parties so we’re going to make enormously easier and simplify that process a lot.”
-Gabe Newell

Because both TF2 and Portal 2 have been supported continuously since their release, they have been the first to see the effects of this new tool development. Valve seems to have used these games as testing grounds, not only for their Free to Play business model and Steam Workshop concept, but also for new kinds of development tools. First, the Portal 2 Puzzle Maker changed the way that maps were made. In the same way that Python streamlines the programming process, the Puzzle Maker cuts out the tedious technical parts of making a level.

The second tool released was the Source Filmmaker. Although it doesn’t directly influence the way maps are made, its obviously been the subject of a lot of thought and development. The new ways of thinking about animation and time introduced by the SFM are probably indicative of the morphing paradigms in the tool development section at Valve.

Don’t think that Valve is going to be trampled by any of its competitors. Despite Unreal Engine’s public edge over the Source engine, especially with the recent UE4 reveal, the AAA game industry is sick, and no other publisher has a grip on the PC game market quite like Valve does. And although 90% of PC gamers pirate games, PC game sales are hardly smarting. In fact, the PC game market is hugely profitable, racking up $19 billion in 2011. This is just a few billion shy of the collective profits of the entire console market. Yet the next best thing to Steam is, laughably, EA’s wheezing digital content delivery system Origin.

Numbers Source

Anyways, here’s hoping for Half Life 3 and a shiny new set of developer tools!

Udacity

I was going to write this post a lot earlier, but I’ve had a lot on my plate recently; AP tests are coming up, track is coming to a close which means a slurry of meets, and I’ve been doing a Udacity course. Udacity is a site that offers free online courses in a video-lecture/machine-graded-homework format that allows thousands of people to participate in each course as it’s happening.

logo-udacity-1600-900px_article_landscape_gt_1200_grid

It was created by the professors who taught the Stanford AI online course, which pioneered the format. It was a huge success, so they decided to create a separate organization which offered a variety of these free classes. They also bring in different people to teach the different courses.

For example, the web programming course that I’m taking is talk by one of the cofounders of Reddit, Steve Huffman. The course is quite interesting. Of courses, I taught myself HTML and PHP, but there are holes in my knowledge, both basic and advanced. The course filled some of those in, but it also teaches an area I’ve never worked in before.

The course is mostly about building an app using Google App Engine. For those who don’t know, App Engine runs a Python environment. You upload code and other files which, given a request, generate a response. You can map out various directories to either query code or directly draw HTML or other documents. Within the code, you have to write one or more handler classes which extend the App Engine API. They have functions for GET and POST requests, which then build a response. Google App Engine also has other functionality, such as data storage.

Anyways, posting will get back up to speed after the AP World History test, which marks the end of a lot of my business. Next post will be more TF2, so stay tuned.

The Chicken or the Engine?

When designing an application that has separated functions for created and displaying data, the developer faces a dilemma. It is difficult to test the application that displays the data without an existing test set. However, it is hard to create a data set by hand, and it is difficult to know whether your data creation program is operating correctly without being able to view the product in the display program. It always ends up being a balancing game; develop a small part of the display app with a limited hand-crafted data set, then build the creation app, and then try to develop small modules in parallel until you have a robust enough codebase.

Really the problem is the development cycle itself. Say I want to create a game. So maybe I decide to use a preexisting engine so I don’t have to create my own renderer (by the way, my 3D game engine is coming along nicely, albeit slower than I expected. I need to rework a lot of the math behind it, but once I’ve built the basic graphics part I expect it will get easier). First you strip down the engine, but then what the hell do you do?

I suppose you code game mechanics, or at least the UI and then the way user controls interact with the game. Then you start to build up a set of game entities, until you have the basic game and then you can add in features. You can create test assets as you add features. Once the main meat of the game is coded, you can pass it off to the environment designers, etc. After that you can continue to polish the game and add features that don’t change asset requirements or level design needs.

But that’s only if you start with a pre-built engine. When building an engine from scratch, you need some sort of test data, such as a 3D model or XML file. You need it to be be simple enough to debug, but that may involve a lot of hand work. Often you need the display codebase to build the test data in anyways! Hmm. Not sure where this is going. I guess it was more of a complaining session than anything else.

%d bloggers like this: