#linux game engine

An intriguing outlook that linux game developers can take note from. Not only in the present but in further game engine development that will produce a more apt linux build. It's pretty incredible how far game development tools have come over the last generation of games. Even just 5 years ago, getting one's hands on game development tools was a difficult process, and learning those tools was even more difficult. Documentation was extremely scarce, and unless you were lucky enough to be tutored by an experienced team, or ended up in a game development job yourself, learning to use those tools effectively was even more difficult. Today, in 2011, getting one's hands on game development tools and actually coming to grips with them is a much more friendly process. For one, there are dozens of freely-available commercial-quality game engines available, from CryEngine 3 to Unreal Development Kit, and even those few games that ship with official software development kits are extremely well-supported by comparison. What's more, the rise of online video now means that getting concise, visual demonstrations on how to use those tools is easier than ever, and with a human touch behind it, it's very easy to learn tools quickly, even if you're a complete novice. In spite of this progress, however, I've found that modern software development kits still have a number of stumbling blocks they need to get over in order not only to make building games more intuitive, but also to make the process faster and require less fine-tuning, bug-fixing and other assorted issues. In this article, I'll be taking a look at a few SDKs I have experience with, examine where the problem areas lie, and provide comprehensive suggestions on how they can be improved. A quick disclaimer: I'm a design mind, not a programming one, and it probably shows in this piece. I'm sure others will have all sorts of issues they can bring up, so bear with me here, as I'm talking about what I'm familiar with above all else. Designer/Programmer Dichotomy This is the all-time biggest stumbling block in my opinion. People who are trained in scripting, programming and other more "technical" tasks tend to not only have certain skill sets and degrees of familiarity, they also tend to process information and think in different ways from designers. Speaking broadly (and I do want to stress "broadly"), designers, artists and so on tend to understand the world in more visual terms - for them, what they can visualize is reality, and creating something that is pliable, "physical" and visible is far more intuitive. Programmers, on the other hand, tend to think in terms of data - visual organization is very important, but for them, speaking in very broad terms, it's possible to understand how something works and will impact a final product without necessarily seeing it first-hand. Consequently, the organization of data tends to be different between these two general archetypes - artists like to keep things simple, uncluttered, and easy to understand, data-driven minds tend to be more focused with smaller details, on having information freely accessible at all times, and in general want to be able to consult any bit of information at any time regardless of what it might be relevant to. Again, I want to stress I'm speaking in very broad terms, and using stereotypes to do so - I don't want to suggest all people (or even most) think according to these, but rather only for the sake of conceptualizing the problem. That problem of interests conflicting, of course, arises when you start to build a user interface that is able to accommodate both sensibilities. Designers tend to think in terms of visuals, so, for instance, level-building tools tend to present themselves in terms of end results - i.e. if I want to make a mountain, I use the terrain tool and sculpt one. However, programming, scripting, and even animation tend to exist more in terms of logical building blocks which inevitably require more functions - rather than hiding things behind the scenes and letting the visuals speak for themselves, and this may not be immediately intuitive for the visually-minded. When you try to combine both sides of the coin into the same toolset, you inevitably end up with something that, to an outsider or an inexperienced developer, can look positively intimidating, as the sheer number of functions required ends up going over the tipping point.

Far Cry 2 provides an excellent and intuitive level editor... but it's limited by nature of its reduced feature set, making for a friendly but incapable SDK. One of the clearest examples of this I've seen is Far Cry 2's map editor. Running the Dunia engine, the home version available is stripped down to the essentials for those who want to build multiplayer maps. The basics of terrain manipulation and object placement are here, as well as texturing and vegetation, but beyond that, the interface is about as easy to figure out as any I've seen. For those who want to just get in and start building levels, frankly, it's great, and for rookies especially it's excellent in helping to teach the basics of level design. However, for those who want any more advanced functions - basic scripting, AI characters, triggers and mission objectives, they're out of luck, and anything more advanced, like manipulation of local and world variables, cutscenes, animation and so on are also missing. If you included all those features in this toolset, it'd be far more intimidating, harder to learn (as more interface elements means more to sort through, more room for error, etc.), which would be inappropriate for a level editor aimed at general audiences. More generally, however, these cluttered interfaces which arise from the dichotomy tend to cause greater problems - namely, they make the tools hard to learn and even harder to master, as the number of functions they must cater to ends up outstripping the talents of any single team member. What this ultimately means is that tools look cluttered and offer up, from an individual perspective, too much information to easily process and digest, and even for those familiar with the tools, can lead to a breakdown in workflow as more mental breathers are required to take everything in.

The Dragon Age Toolset offers up huge amounts of functionality, but keeps them quarantined in relevant areas to help keep content creation more intuitive. One of the best solutions I've seen to this problem so far lies in the Dragon Age Toolset, BioWare's internal game editor for the Dragon Age series. While the updated version compatible with Dragon Age II is a no-show for now, the original version still has a logical way of organizing information for the end user, regardless of experience level. Effectively, game files, rather than stored within large level archives, are instead manipulated by an individual "mode" within the editor, and saved as individual files, i.e. *.dlg for dialogue. This means that, while level designers can easily create maps in the level editor, game designers can then hop in and create the actual gameplay via the area editor, by placing NPCs, triggers and so on. This extends to cutscenes, plots and quests, scripting, creature and NPC creation, and so on. The compartmentalized nature of the Toolset makes it easy to learn and easy to break up into small, intuitive pieces while still appealing to the more advanced sides of each discipline. I think that more game SDKs should take on this approach - if the tools need to be unified, they should still be small enough to learn the individual pieces of, rather than monolithic and intimidating. Don't Waste Time This might be a bit of a vague topic, but I think it's an extremely important one nonetheless. It's extremely common in game editors to have certain functions which take an extremely long time to perform, yet the function they provide is utterly essential. The most common I personally run into, and the most aggravating as a level designer, is that generating lightmaps, more often than not, takes just about forever to accomplish. I realize that, at a basic level, this is something that is hard to control - lightmap generation is something essential to modern 3D games, there are certain underlying factors that can't be hurried or sped up, and the size, complexity and number of lights in A level very often contribute to rendering time. Even so, more often than not I find that, in many game editors, half my time is spent waiting for lightmaps to render rather than actually building more content.

UDK provides extremely high-quality in-editor rendering, which saves a huge amount of time in building levels. There is an "easy" way around this lightmapping problem, and that is to have sophisticated and high-quality real-time previews of what in-game lighting will look like. Things in the editor are rarely identical in the game owing to optimization, in-game options, video drivers, and any number of things, but the faster I can conceptualize how a level is going to look in the game, the faster I can build it, and getting a sense for lighting and atmosphere is absolutely key - in fact, I'd say there is nothing more important in creating a level than knowing what the lighting is going to look like by the end of it. On top of it, lighting helps designers understand spatial relations, as without real depth perception, lighting and shadows help to give a sense of depth that is otherwise lacking when flat, static lighting is all you have to go on. If it's impossible, then at least provide me with fast, quick-and-dirty preview renders that take as little time as possible but still give a general idea of what the game is going to look like. Another thing that tends to take a lot of time is testing out changes in-game. It's easy to build content, but most time is generally going to be taken tweaking it, and fixing all the little issues and bugs that crop up. In my experience, the more often you cast test something in-game, the better. Unfortunately, some game SDKs still do not support this feature adequately. The Dragon Age Toolset as mentioned above is just one such example, as it requires a full export of project files and a full game restart in order to be able to see results - and that's not even counting how much time you might spend actually getting to the piece of content you want to spend.

CryEngine 3, through some arcane magicks, is able to allow you to drop into a game level at any time and place, and test exactly as it appears in the game itself. This. Is. Good. Although I'm not certain whose editor the first was to do it, Crytek's CryEngine and CryEngine 2 really popularized the idea of being able to jump into the game world and test things out exactly as they would occur in the game itself. I'm not privy to the technical wizardry behind this, and don't presume to know what kind of a feat it is, but suffice is to say that it makes building content much, much quicker on a design end, and means that content creators get real, accurate feedback on what they've done even moments after it's been put into the game. From a level creation point of view, this is especially important, as most know that placing 3D objects accurately without clipping errors, floating bits etc. can be a real pain sometimes, as can ascertaining a sense of scale relative to the player. Moreover, being able to test out scripting in-game is extremely convenient, and allows bugs to be fixed in seconds instead of hours. I'm sure there are dozens of other solutions that can save developers' time on the content creation front, everything from better standards between programs, to consistency in file formats, to removing or automating redundant and repetitive operations. These couple of examples are the two that stand out most for me, but depending on the field, I'm sure that there must be dozens of other issues - for example, I know audio designers would probably be happy to never again have to bother converting their *.wav files into some obscure and disused file format using a stand-alone compression tool that only works properly on Windows 2000, and batch actions when importing scores of diffuse, normal, specular, etc. maps would be a godsend for artists. Suffice is to say, any time-consuming tasks that could be made faster, should be made faster, end of story. Standards, Standards, Standards However, the fact is that oftentimes it's impossible to realize the demands for better tools, especially for developers which rely on their own technology. Whether it's because someone on a development team has a certain obsession with a proprietary format, because game technology is purpose-built for a specific product, or simply due to a lack of resources, a lot of these ideas I've presented get left on the cutting room floor for one reason or another. The solution to this, I think, might be controversial, but in the end I feel would be best for the whole games industry and the development process. Standardization of tools has already begun, to a degree, with just about every developer out there needing experience in Photoshop, Pro Tools, Maya, etc. depending on the particular field, but even beyond asset creation, game tools have also begun to homogenize. Ten years ago, accomplishing anything more than what a game editor was explicitly designed to do was a complex task involving lots of jury-rigging and a good deal of luck, and transitioning from one SDK to another was a long, arduous process that required a lot of re-training. These days, the interfaces between SDKs are so similar, at least on a basic level, that most people should be able to jump in and create something useful within a week or two, and that is most certainly an improvement. At the same time, much as we have those standards for the asset creation, we don't really have standards for development tools themselves, despite the similarities. I think, more than anything, what is necessary to cut down on development time and expenses, is the creation of a unified SDK front-end common to every game engine. The best analogue I can provide for this is Photoshop - while it can export a variety of image formats, compatible with just about any other program or device, the actual creation process is extremely standardized. Photoshop's interface has come to define modern image editing, and to a degree, even 3D modeling and texturing tools like Mudbox, to the point where any artist, photographer, etc. can use Photoshop and create something suitable for any job. The dream, for me, is to have a Photoshop for level editing, another for scripting, another for animation, another for audio work, and so on, so that skills would remain consistent and practical across just about any project, while the code underneath, the game engine itself, remains in the hands of the game developers.