Vaevictis_Music
-
Posts
879 -
Joined
-
Last visited
Posts posted by Vaevictis_Music
-
-
Stuart Walpole (Acumen), our resident Programming Manager, has written a great follow-up to his first developer article. This time, Stuart discusses the reasoning behind going 3D with 0 A.D. instead of the 2D/3D hybrid that was originally planned.
Click here to read the article, which, as an extra incentive, comes with a new, exclusive screenshot featuring the Romans.
In the near future, look for a dev article by Project Leader Jason Bishop, which details what's in a day's work when you're chief of the 0 A.D. development project.
-
Journey into the Third Dimension
by Programming Manager Stuart Walpole (Acumen).
IntroductionIn this article, I'll attempt to summarise how and why 0 A.D. evolved from a sprite-based game into the full-3D beauty visible in recent screenshots.
Full 2DAs you probably already know, the origin of 0 A.D. can be found in Ensemble Studio's Age of Empires II: The Age of Conquerors. When Wildfire Games decided to redirect development from an AoC mod to a stand-alone game, much of the game's design and vision assumed that we would be working within the limits of Age of Empires gameplay and the constraints of its Genie Engine.
This included certain assumptions, in particular that the game would be totally sprite-based. A sprite is simply a flat image of a particular width and height displayed at a certain x/y coordinate on the screen. By displaying lots of sprites in the correct order and alignment, we construct what appears to be a believable world with the illusion of depth.
I'm going to be distinguishing between 2D (sprites) and 3D (real-time rendering) quite a bit in this article, so in order to avoid future confusion, I first want to touch on a technique that blurs the distinction and makes 2D sprites "look" like 3D models: prerendering.
The basic approach is as follows ... Instead of handpainting each unit sprite, a modeller creates a detailed ("high poly") 3D model of the unit, wraps it in a high resolution texture, and positions the camera so it's pointing at the unit at a standard "isometric" angle. He also applies a mask to indicate which areas of the scene, such as the background, will be transparent when the image is displayed on the screen (rather like the "blue-screen" technique of chromatography). He then renders this detailed scene (which could take several hours) and saves the output to an image. This picture of a high-quality 3D object is then displayed in-game as a sprite.
[img left]http://www.wildfiregames.com/0ad/images/articles/spriteanimation.gif[/img left]
I thought it important to mention this as Age of Empires used this technique, 0 A.D. planned to follow in their footsteps, and it's often used in isometric 2D games (Diablo being another example). So when I refer to 2D or sprites for the remainder of this article, I will in fact be referring to *this* method of rendering them.
A full 2D game has several benefits:
- Better performance on low-grade hardware: Blitting sprites to the screen is much less taxing than rendering them on the fly.
- Simpler engine: Simply put, a sprite-based graphics engine is a lot easier to write and requires far less mathematical genius than one capable of loading, combining, and rendering objects in 3 dimensions. Considering that our initial team were mainly artists with scripting skill at best, lower programming requirements gave us a better chance of success.
- Postwork: The sprites can be modified in an image manipulation utility like Photoshop or Paint Shop Pro to make them look even better ... smoothing out rough edges, applying special effects, sharpening colours ... and the artist can be sure that his improvements will be accurately represented on screen.
Real-time rendering of detailed objects requires a lot of processing power. When rendering 3D objects on the fly, the more detailed a mesh (the higher the number of "polys"), the more processing is required. But it takes just as much work to display a sprite whether it's a hand-drawn stick figure or a render of a 100,000 poly teapot. With the prerendering technique, we get all these benefits, plus our images look like higher quality 3D models than could be real-time rendered on conventional hardware.
So this is the mindset that we had coming out of a modding background when first designing our own engine. As time went on, we were gradually seduced by the third dimension.
[img left]http://www.wildfiregames.com/0ad/images/articles/tbj.jpg[/img left]
3D Terrain, 2D ObjectsWork continued on 0 A.D., and our ranks began to swell. Skilled programmers started to come onto the team. Freed from the limitations of modifying an existing game, we started to evaluate what new features we could bring to the table.
Since we would now have to create our own game engine, we considered how we could best take advantage of new 3D technology. The first thing we decided to do was to use 3D terrain.
A tile-based terrain sprite system is quite limited because every time a terrain tile needs to be displayed at a certain inclination to create a slope, this requires an additional sprite. This means that 2D terrain tends to have hills with very jagged edges.
But by deforming a 3D mesh of interlocked triangles, we could warp the height as subtly and smoothly as creasing a bed sheet. Deep valleys, rolling vistas, and towering mountains are all just variations in the height map. Even more significantly, terrain can be painted onto the terrain mesh from a texture source to make up the full game map, combining terrain textures and even blending them together. We could create a multitude of separate textures to paint onto the terrain without having to pre-render each tile in every possible state.
Even with this flexibility, at the time we still opted for a hybrid 2D/3D engine, with prerendered sprites (for buildings, units, animals, etc) attached to this rolling terrain like cardboard cut-outs.
There were various reasons for this:
- A lot of game sprites had already been created for the 0 A.D. mod, and were ready to put in the new game.
- Our artists, as Age of Empires modders, were already most familiar with the rendered-sprites method.
- We were reluctant to give up the high level of detail provided by a pre-rendered image.
[img right]
http://www.wildfiregames.com/0ad/images/articles/raj.jpg[/img right]3D Terrain, 3D Units, 2D BuildingsIn time, our artists were seduced by some distinct benefits of using 3D units.
Since we plan(ned) to primarily release the game as an online download, we needed to keep the size of that download as small as possible. The easier it will be to get hold of the game, the more people will play it.
However, every frame of every animation, every variation in a unit's appearance or motion, had to be rendered as a separate sprite, and each frame occupied a certain amount of storage memory that quickly added up. We ran some calculations to project how many images we would ultimately require in order to provide the variety of units, animations, and abilities we required, and decided we would have to make serious compromises.
We also had to look at the way the rest of the RTS industry was moving. Even as die-hard Age of Empires fans, we generally agreed that more diverse civilisations made for much more varied and interesting gameplay with unique tactical opportunities.
Age of Empires provided a wide number of civilisations, but they shared a common base, with several civilisations often using identical sound effects and artwork. If we wanted to represent the major civilisations of the classical era, and represent them in 2D, we would have to continue to use this method. This would mean that, for example, the Romans and Greeks would have to have an identical appearance, other than a couple of unique units and technologies. The Persians and Carthaginians would have to share the same generic Middle Eastern architecture, and so forth.
Furthermore, the asset creation process became more and more lengthy. We had to consider unit colour, transparency, foot shadows, and so on, and try to find ways to generate these effects while the image was rendered. Despite our best efforts, some of these could only be refined through postwork, which would make a lengthy process even more time-consuming.
Finally, while the high level of detail was the major reason to stick with sprites, most of that detail is lost when a unit is scaled down to a tiny onscreen figure. We had to really exaggerate features to make them noticeable, and there wasn't much pointed in putting a lot of fine detail into their skins, since it would be reduced to a jumble of pixels.
In addition, 3D units appealed to us because of some distinct advantages:
- Context: A 2D sprite has little mass, depth or scale in a 3D world. It's arbitrarily pinned to the world through a contrived anchor point; a painting on a hill. By using 3D units, they could interact with each other and the world in far more realistic ways.
- Variety at Little Cost: This one was the biggie. 3D units could be assembled from basic reusable components ... a modelled mesh, a skin (a texture wrapped around the model), and a motion file (which tells the bones of the model where to be positioned during an animation). Basic humanoid units could be built from a stock of shared figure models. Two humanoids that needed to swing a sword could use the same swing-sword animation file. The components are combined on the fly, rather than having to prerender every combination of them, taking up a fraction of the space.
- Attachments: Attachments make a great concept even better. The basic idea is that instead of making a unit's weapon, shield, armour and other adornments part of their mesh, they are modelled separately as "props". These props can then be attached to the base mesh as needed at nodes ("sockets") on the mesh ... putting a sword in his hand, a quiver on his back, a pouch at his waist, and so forth. Like a grisly digital Worzel Gummidge, we can attach a different head to a unit whenever he needs a new helmet. Not only is it easy and a lot of fun to make a unit that swings a petrified deer as a club, but component-swapping is both efficient and has incredible potential. We can put a plume on a unit's helmet, buff up his armour, and give him a better pair of shoes when he gains a promotion. When instructed to till a field, a unit can change into grubby work clothes and a floppy hat, and start ploughing a rake through the soil.
- Effects: By making units a part of a 3D world, they can cast dynamic shadows from the scene's light source. Particle effects can shine in their faces. The colour bands in their skins can be cleanly processed and interpreted without being pre-antialiased. While these complex issues now become, alas, a programmer's problem, the artists are free to spend their time churning out new content rather than fighting to assemble old content.
[img left]http://www.wildfiregames.com/0ad/images/articles/3danimation.gif[/img left]
So we sold our 2D souls for the benefits of 3D units. But we still retained one aspect of our 2D legacy ... sprite-based buildings. Many of the disadvantages didn't apply to them ... As static objects, pathfinding wasn't much of a consideration (other than units navigating around them). As much larger objects than units, we could lavish them with more detail and truly take advantage of prerendering. Finally, they required little to no animation. At this stage, 0 A.D. would have appeared quite similar to the yet-to-come Rise of Nations ... detailed 2D structures in an otherwise 3D world.
Full 3DOf course, many of the benefits of 3D units could also be applied to our buildings. A realistic-looking building would have to be loaded with "eye candy" ... For example, a Barracks might have a training area with weapon racks, shields, barrels, practice dummies and so forth. In addition, we needed to consider the seasons feature and how we would apply snow to the buildings in Winter. For sprites, all these extras would have to be loaded into the scene, carefully positioned, and rendered for every variation of that building that might occur. However, since we already had the prop system for units, if buildings were also 3D objects, we could attach eye candy props to them in whatever variety we wished. We could even vary the placement of these props from building to building to really make them come alive.
[img right]http://www.wildfiregames.com/0ad/images/articles/highpoly.jpg[/img right]
Also, since buildings were not a true part of our 3D world, units could not truly interact with them when performing actions like garrisoning or attacking. Rather like movie actors playing parts alongside CGI monsters, they might be told the vague location of the computer-generated foe they are attacking, but he doesn't have an actual physical presence in their world. Making the buildings 3D would not only give them that presence, but allow them to interact in new ways, such as propping units to buildings, allowing them to stand on the building's battlements, for example.
Then came the final allure of a fully 3D world that sent us over the brink ....
Since 2D objects get pasted on top of a 3D world, you can't believably rotate the camera around them. They'll always point towards the camera, since they have no sides, no back, no depth, no third dimension. You might, for example, be familiar with how the corpses of dead opponents always spun so they were pointing towards you in Duke Nukem 3D.
By the same token, we had to keep the camera at a fixed position to avoid this strange effect (this is why the camera can't be rotated in Rise of Nations). Zooming also proved problematic, since the building sprites could become pixelated if we zoomed in beyond their texture size, also ruining the illusion.
Rotation isn't essential to a playable RTS game, so this wasn't the major reason we switched ... A major contributor, however, was non-interactive camera control: in-game cutscenes. The ability to cinematically track the camera around an object, place it at any position in the world, tilt and zoom in on a discussion between two great heroes, allows tremendous opportunities for creative storytelling in campaigns. We also knew it wouldn't be feasible to package movies with the game to tell these stories, since those movie files would be huge downloads, so doing it in-game was another nod to efficiency.
[img left]http://www.wildfiregames.com/0ad/images/articles/lowpoly.jpg[/img left]
ConclusionSo it was a gradual process with many lessons learned, but I hope recent screenshots demonstrate that we have made the right decision.
Fortunately, most of these discoveries were made through early experimentation and speculation, so we didn't waste too much time and effort on redundant work (and the work we did do, ultimately honed our artistic skills for the challenge of working in a 3D environment).
By Stuart Walpole (Acumen)
- Better performance on low-grade hardware: Blitting sprites to the screen is much less taxing than rendering them on the fly.
-
Be sure to vote in our new poll - where did you first hear about 0 A.D.? Your answer will help us determine where the fanbase comes from, and where to concentrate our PR efforts.
Also, you're welcome to elaborate on your answer (which gaming site, which community, etc.) by adding a comment to this newspost.
-
-
For all applicants to the 0 A.D. historian position: You have under one week remaining to complete and send-in your articles. On December 14, 2004 ALL history articles are required to be in the hands of Paal_101 for evaluation. Thank you and good luck to all!
-
Yes, it's true - two new screenshots featuring the Pre-Imperial Romans await you at the Gallery.
-
Those who have applied will be judged to go on to the second level. To those who have already sent in their application forms, be ready to receive instructions on the test projects. They could come at any time after Sunday the 28th.
Also, be sure to check out three new history articles written by our historian Joshua Gilbert (aka Shogun_144):
They all contain a wealth of information that we hope you will find fun and interesting to read!
-
Resident historian Paul Basar (Paal_101) has completed a new article. It is structured as a chronological overview over the historical battles of the Persians.
Remember that if you have a passion for writing articles like these, we still need a historian to work with Paul on the team (see the Vacancies page).
-
0 A.D. is looking for another historian to aid the project. If you are interested in researching the ancient world and writing about it, plus having a meaningful effect on the game, check out the Vacancies section of the site. There you will find a list of all the duties and skills required for this exciting position.
-
As you may have noticed, the forums have gotten a visual upgrade to fit the website theme. This is only one of several additions that will be made to the website in the near future. We're only just beginning...
-
-
Err - considering that this is a review thread, it's probably meant for those who haven't seen it .. unlike the information about who dies and who doesn't.
-
Exactly what Michael said. We have not 'monopolized' the concept of researching - we've just done it thoroughly, then added / modified what we felt was necessary for the sake of gameplay. That's why using our stuff may not be the optimal solution for either you or us. I'm sure Shogun, our resident article writer, can point you to some inspirational articles / sources that you can use to do your own research.
-
If you need help converting your midi files to another format on the fly for burning, you can send them to me (borishansen@gmail.com or MSN: belgarion1@hotmail.com)
-
23 over here.
-
David Benjamin is our newest addition to the team. He'll be teaming up with Shan to create unit textures for 0 A.D. David's profile will soon be up on the page. Welcome!
-
0AD Theme Song - Boris Hansen
-
What really surprises me is that it's now over two years since we did the trailer... shows on one of the Old Forum snapshots, where someone comments on how it in some ways beats the trailer for Rome: Total War.
And of course, Kristo was there right away to tell us how it sucked... great stuff! 
-
Looking at your evidence, Jason, it raises the question: What happened to the african villager mod?
Anyway, early 2001 sounds right, because I remember joining late 2001, and there were already some members then.
(Hmm... has it really been 3 years already??)
I really wish I had taken some screenshots from back then. Like when our forums were just 10 subforums on one screen, covering everything from 0 A.D. to TLA to Insurrection development as well as public discussion. I even seem to remember an earlier version of the forums too, but it's all too hazy right now.
-
Our new concept artist, Brendan (b.w.keough), has completed three outstanding concepts of Carthaginian footmen units. Check the Unit Concept Gallery to see them all.
- Boris (Vaevictis)
-
Just figured we should make this offical: Welcome to Shan Coster (Centurion_13), who has joined the ranks of 0 A.D. staff members. Shan is now a member of the Art Department, and he'll specifically be creating unit textures for the game.
Shan was recruited from the public forums, where some of you may have seen him recently. Remember, if any of you also feel that you may have something to contribute, check out the Vacancies page in the menu and send us an application. You could be the next one getting a front page welcome!
- Boris (Vaevictis)
-
Hear ye, hear ye!
The 0 A.D. staff is proud to present the brand new official 0 A.D. website. In the future, this site will be the place to find the latest news on all things related to 0 A.D.
Regular 0 A.D. fanatics may have noticed that up until now, the 0 A.D. website suffered from very rare news updates. This is about to change with the introduction of regular features, interviews and goodies, so bookmark the site today!
As the menu on the left suggests, the new website focuses on three different areas:
- Information about 0 A.D. such as gameplay, screenshots, etc. This section will be updated all the time, so be sure to check back often.
- Behind-the-scenes news. From now on, the website will give you some insight into the process of developing the game. We'll not only keep you updated on staff and department lists, but we'll also regularly publish dev articles by different staff members. These will tell you about all that's going on in the different staff departments.
- The 0 A.D. community. The forums have had a makeover, but that's only the beginning. We're going to make an effort to strengthen the community in the future through initiatives such as events, contests. etc.
The site is result of hard work by Nate (CodeOptimist), Stuart (Acumen), and Jason (Wijitmaker). Big round of applause for them!
That's it for now! Be sure to read the first Dev Article, tell all your friends about 0 A.D., and check back often for new stuff!
- Boris (Vaevictis)
- Information about 0 A.D. such as gameplay, screenshots, etc. This section will be updated all the time, so be sure to check back often.
-
Engine Philosophy
- by Programming Manager Stuart Walpole (Acumen).
INTRODUCTION
The purpose of this article is to provide a little background to the approach Wildfire Games is taking in the development of its 3D RTS engine. Don't swallow that cyanide pill just yet; I don't plan to get too technical.
Firstly, a few words on the different Departments:
The Art Department creates the visual assets for the game, starting with concept art, and then modelling, animating and texturing all the 3D objects that are found in the game, as well as 2D assets such as the game's user interface art.
The Audio Department handles the aural side of the game: creating and mixing the tranquil tunes, frenzied battle music, atmospheric ambients, and harrowing death cries that create a credible audio atmosphere.
The Design Department establishes the vision for the game, plans out the gameplay in minute detail, and helps in implementing it.
The History Department ensures that the game content is as close as we can get it to a representation of history, and write articles and historical background to anchor the game world in classical authenticity.
The Programming Department's responsibility is to create the software platform that supports the game. This is the "engine". It hides under the bonnet where it won't cause distress, so don't worry if you don't know "internal combustion" from "open heart surgery"; all that matters is that it's responsible for moving a pile of otherwise inanimate components from A to B, and hopefully you'll never have to see it in all its grease-smeared splendour.
To abuse another metaphor, the engine "skeleton" is covered over with the "skin" of art and sound to make it very pretty, and hide the casual eye from the bloated organs and sticky fluids pulsating under the surface. Creating life is a massive undertaking, since we are building this Frankenstein's monster entirely from scratch, and the project requirements are quite substantial.
ENGINE REQUIREMENTS
While the graphics requirements aren't as bleeding edge as, for example, an FPS, a real-time strategy game requires extremely adaptable game logic to allow for a wide variety of anticipated game modes and features.
It needs to provide support for varied skirmish games against human and computer players out of the box, single-player campaigns with plenty of eye candy, triggers and special conditions, random maps, replays, and the list goes on. The sheer amount of required content is astronomical.
Furthermore, we want to make our engine easy to adapt by "modders". Allowing players to change the nature of a game and add different rules and new content can drastically increase the lifespan of its interest. Most games can be modified only at a very superficial level or by editing data the developers never intended for external adjustment.
Consequently, modders are typically only able to replace things that are already in the game (such as the WFG mod "Rome at War", which replaces a couple of "Age of Kings"' existing civilisations with the Romans and Greeks).
We plan to keep our game data far more adaptable, allowing new content to be added and existing content to be changed. At the same time, though, we need to ensure that the game is not so flexible that a cheater can exploit this freedom to give himself an unfair advantage in multiplayer games.
"The Last Alliance" also plans to use our engine at least as the basis for their project, so we need to take into account that it could eventually become the platform for a Middle Earth RTS with an entirely different set of game rules and assets.
Finally, we want to cater to a wide spectrum of players. We want the game to be popular and well-received.
SHORTCUTS TO SUCCESS
After performing CPR on some of our more highly-strung programmers, we set about trying to meet these objectives within our lifetime. We came up with a few cunning strategies:
- Open File Formats: We avoid proprietary file formats wherever possible, and use formats that are widely available to the general public.
For example, we use simple Zip compression to generate our archives, so it's easy to extract and modify files, and distributing a mod is as simple as packing the altered file tree with WinZip.
Where closed formats could not be avoided, we provide methods for end-users to have as much creative freedom as we do (for example, a Max plugin to export meshes in our custom model format). - Data-driven Methodology: Above I compared the engine to a "skeleton" and art and audio to "skin". Under this approach, data is the "meat" of 0 A.D.
This process means that we shift game logic out of the engine, which is faster, secure, but nigh impossible to modify without access to the original source code and a savvy programmer, into external data (data files, scripts), which can't be processed as quickly as compiled code and is open to malicious manipulation, but can be modified without the attention of a C++ programmer.
The power of this method cannot be underestimated.
I have no hesitation in stating that our programmers are very talented, but it's rare to find an excellent programmer who is also an excellent artist. Furthermore, for a first project and especially for an RTS game, an immense amount of "tweaking" will need to take place in order to balance statistics, get those particles to create just the right sort of rain effect, create the effects for all the technologies, and fix that script bug where the War Elephant's head explodes when you click on it.
Most game data is handled by text storage files (mostly XML) for layouts and values, and scripts for game logic, GUI events, random maps, and so forth.
The data-driven approach frees the programmers to focus on developing and
fixing the generic components of the engine, while aesthetically conscious artists and anally retentive designers have the power to put 0 A.D. content into the game exactly the way they want it, and experiment until it is perfect.
The result is more efficient implementation and much higher quality. Combined with a file-handling approach that allows new or modified data to be kept independent of the "official" game data, this also provides an incredibly adaptable platform for end-user modification.
To revisit the "vehicle" metaphor, separating the engine through data lets other Departments take care of the chassis, the shiny hub caps, the tunes playing on the stereo, the angle of the mirrors, the smoldering mess in the ash tray, and that rather worrying array of flashy red lights on the dashboard. All the programmers have to do is make sure it never breaks down in the middle of the M1, and is capable of exceeding the speed limit. - Client/Server Architecture: People should be able to modify their game any way they want in single player, but everyone in a multiplayer game must follow the same rules. So if altering the game is so feasible, how do we stop an immoral player from hacking a multiplayer game to make himself an immortal player?
We have several plans in mind to confront this problem (and not allow a player to join whose data does not match that of the host), but one is to use a networking method where clients are dependent upon the host to periodically broadcast the state of the game and ensure that the same game state is retained for all players. So if a player attempts to modify his data so that his client differs, this won't match up with the server and so his session will be out of sync and dropped from the game. - Platform Independency: Different operating systems have different protocols and requirements. They do however share various architectural similarities, and so with careful awareness of both platforms and writing platform-specific code where necessary, it is possible to develop an engine which can be compiled for different operating systems. Where engine components have to be specifically written for a certain platform, we explicitly separate these from the rest of the engine so that they can be interchanged when compiled for other operating systems.
Using this method, we intend to provide both Windows and Linux versions of 0 A.D.; players on different operating systems could even battle in multiplayer together! This should add a very vocal market with a similarly independent philosophy to our fan base. This can only work in our favour.
Of course, the decision also greatly limits our options to those that function perfectly on both platforms. For example, we cannot use DirectX since it only works in Windows, and end-user tools need to be created using a cross-platform application builder or directly integrated with the engine. - Localisation: While it is fully dependent upon whom we can find to translate the game's text, from the start we are making it feasible to provide language packs for languages other than English, such as German and Hebrew.
- Third Party Libraries: We try not to reinvent the wheel. Whatever you're trying to do, there's usually at least one other sucker who's tried and failed, or succeeded and made the fruits of his labour available on the 'net for use by others. For example, we use free open source libraries to handle data packing (ZLib), XML parsing (Xerces), expose a scripting language (SpiderMonkey JavaScript) and accessing the audio layer (OpenAL). Assuming that it meets our requirements (such as Linux compatibility), such packages save a great deal of development time.
- Open File Formats: We avoid proprietary file formats wherever possible, and use formats that are widely available to the general public.
-
Anders - Can I presume that you're (also) Danish?
Not one, but two
in Announcements / News
Posted
Two aspiring historians made it through the eye of the needle. Welcome, Ashley and Nathan, to the History Department and the 0 A.D. team.