Machinations - Developing a Real Time Strategy Game

The terrain is more or less finished now. The terrain supports a number of new features, including:

01/02/2005 - Jon

customizeable water and special-effect planes
a diffuse map for superimposing (i.e., adding) subtle colors to the stratum textures. For example, we can use the diffuse map to make the grass appear yellowish in some areas and brownish in others.
dark gray edge trim surrounding the map on all four sides.
patch textures (i.e., localized detail textures that I generate dynamically in the back framebuffer)

The terrain is also fully customizeable. I have about 40 options that the user can change from inside the terrain manager (actually, the terrain manager is merely a terrain viewer at the moment). These options allow the user to configure the terrain for the optimum balance between quality and performance. The options are also incredibly helpful for testing. For example, I can toggle vertex-buffer objects and immediately observe the impact on the frame rate. I can also switch to a secondary view and ensure that objects outside of the viewing frustum are getting culled properly. Since the terrain options are so valuable, I will probably integrate them into the game.

The models are also more or less finished. Tom and I have developed an elegant model LOD system. Tom generates about three levels of details for each model--say, 400 triangles, 100 triangles, and 25 triangles. We then tell the program the distance from the viewer at which each level of detail becomes visible. To avoid abrupt transitions, we gradually fade in one LOD and fade out the other. I discovered that blending causes problems with traslucent faces, so I'm using stippling instead. This approach is easy to implement and works well.

I'm still using the same approach to shadows (a cross between projective shadows and shadow mapping). I recently discovered that the location of the near and far planes is critical for shadow mapping (all approaches, I think). Unfortunately, I'm having a hard time thinking of an efficient way to calculate the optimal near and far planes. Currently, I'm rendering the depth component of the terrain to a 64x64 viewport, reading the 64x64 array of depth values, and searching for the extrema. Although this approach works, it significantly lowers performance.

Now, I'm working on the first revision of the model animations. Once again, I'm tieing up loose ends, removing ugly code, cleaning up the scriping syntax, and integrating the model animations with the new parser. When I'm finished, I'll probably put together a model-animation viewer for testing and possibly unit development. I was thinking of associating a button with each procedure--this will allow the user to simulate events that would ordinarily originate from the engine. I was also thinking of using the mouse pointer to position the target for aim procedures (aim procedures are routines that automatically aim a gun barrel by adjusting a number of user-defined joints). This approach will allow me to exercise far more control over the animation's environment than I had inside the game.

In other news, Tom has put together a wonderful new website here: http://www.machrts.com/ We will post announcements and images on this website henceforth, so update your bookmarks!

In case you didn't see the forum post, Tom and I have decided to keep the project entirely open source. You'll be able to download the latest source code from the members section. We haven't decided on a license yet, but at the very least, you'll be able to compile the source code and make changes to it.

12/10/2004 - Jon

Hello, everyone. I haven't had much time to work on Machinations since my last post in September (wow, the time flies). I've abandoned the heightmap manager I described a long time ago. The heightmap manager is great for developers who want to combine noise in cool ways using mathematical formulas, but it's not practical for most users. Besides, many programs (such as TerraGen) already generate high-quality heightmaps with the click of a button, so there's no reason to reinvent the wheel.

Lately, I've been learning about a widget toolkit called FOX. With the exception of a few small quirks (like menus stealing focus from your window), I'm very pleased with the library. FOX seems flexible enough that I can replace the default appearance of the controls with Tom's beautiful textures (more on this later). If all goes well, I plan to implement the entire GUI using FOX.

Over Thanksgiving break, I spent 35 hours on the terrain and nearly finished the new-and-improved terrain module (~3000 lines of code). The new terrain has the same capabilities as the old terrain (with the exception of waves and water motion), but features a much better LOD system. I've also tied up many loose ends, removed interdependencies, and contructed a nice interface. Next, I'll probably revamp the unit animations.

11/30/2004 - Jon

Jon and I have decided to develop Machinations as a commercial title. We feel this mode of development will provide us with the motivation and direction necessary to finish the game and make it awesome. Up until now the Machinations project has become somewhat of a confused beast which was beginning to run away from us. We aim to tame this beast and release it sometime around Summer 2005, via the Internet. It will be an independent budget game with periodic small updates and expansions. We've appreciated the community's support so far and hope you'll stay with us!

11/24/2004 - Tom

comments: 9

11/23/2004 - Tom

The Raider mech has been redesigned and now employs a back space for one 10x10x10 AWM (Auxiliary Work Module). Additionally, the wrist and elbow joint component has been standardised to facilitate consistent interconnections between weapon modules. Note also the knee joint has been simplified somewhat, and overall the polycount has been reduced.

It's hard to imagine context and storyline when my thoughts are filled with concepts of robots and vehicles. Perhaps the best approach is to extend from modularity, rather than attempt to link storyline XYZ with this robotic army's philosophy of design and organisation. One could focus on the benefits of this manufacturing technique, and extend outwards a context. Why does this robot army modularise it's weapons, propulsion systems and unit functionality? What practical benefits does this methodology provide them? Cost and resource efficiency? Perhaps the planets are resource scarce. Does modularity enhance the army's environmental adaptability and flexibility? Perhaps environmental variables - climate, terrain, threats - change unexpectedly. Who are these machines - where did they come and what do they want? Stay tuned.

11/19/2004 - Tom

I've made some minor structural changes to the warrior mech to support an emerging gameplay concept as well as to improve it aesthetically and reduce it's polycount. The polycount has been reduced significantly around the hip, foot and back regions, with the wrist receiving a complete redesign to improve it's look and to standardise the interface between the weapon module and the unit.

Most importantly, a small depression has been made in the warrior's back. This compartment will house the optional Auxiliary Work Modules (AWMs), each a 10x10x10 unit cube. The warrior mech's generous 20x30x10 AWM compartment will allow it a possible six AWMs. (The barbarian and raider mechs will support two and one AWM respectively.) AWMs will provide units with a range of secondary abilities (their primary abilities being whatever is connected to their arms; usually weapons). Some possible AWMs have been mapped out on paper here. Most AWMs will be 10x10x10 however certain ones will be 20x20x10, 30x30x20 and upwards, necessitating their deployment only in larger units (the warrior can support one 20x20x10 and two 10x10x10 AWMs or six 10x10x10 AWMs). This AWM concept will be extended to buildings, existing as empty "milk crates" until AWMs are slotted into them (in which case they'd be better termed PWMs - Primary Work Modules). The cross sharing of A/PWMs with mobile units would be awesome - imagine housing a factory PWM inside a vehicle.

In the top image the blue components represent optional modules. The SAPS (Self-Annihilation Packs) component connects to the warrior's waist providing it a triggered powerful self-destruct capability.

11/09/2004 - Tom

To celebrate the start of my excessively long (four month) uni break i've scripted the new warrior and raider mechs and added them to the game. They're looking pretty good. What i might do in the future is remodel the warrior's elbow and wrist section, as well as the raider and barbarian foot components, but essentially the mechs are finished, and now await a method of equipping them with weapon modules dynamically. I've also added some sketches of the modular vehicle and warrior mech (1) (2).

So far Jon and I have brainstormed countless ideas to make Mach original, but all these ideas come and go and float around in space with no underlying concept binding them together. Gameplay involving variations of building units and fighting wars (i.e every RTS ever made) is beginning to sound really ordinary. Modular/customizable units i hope will be just one part of conceptually intriguing Mach in the future.

All combat vehicles regardless of environment are characterised by three variables - offensive measures, defensive measures and propulsion. At least two of these three variables are compulsory in any combat unit. The modular surface vehicle attempts to satisfy a multitude of different combinations of these variables in a single vehicle system. The benefits of a modular vehicle are paradoxical in nature - it reduces the number of models a developer needs to model/map/skin while multiplying the number of possible vehicle combinations the end user can create. In an industrial sense, modular vehicles and their components are easier to mass-produce. In a tactical sense modular vehicles can be quickly repaired or even assembled on demand in the field with support units.

11/05/2004 - Tom

Of the three variables - offensive measures, defensive measures and propulsion, propulsion's effectiveness is inversely proportional to the former two. Additionally, all three possess a weight. The presence of weight necessitates the modular vehicle's chassis (the cental module) be extensible to accommodate larger (heavier) offensive measures, defensive measures and propulsion systems.

The modular surface vehicle shown above comprises the following components; an extensible chassis (compulsory), self-powered tyres (compulsory - compatible propulsion modules will include wheels and propellers with internal engines, jets, rocket-engines, anti-gravity plates giving the MSV ground, marine, submarine and air capabilities), an armour rig module (not compulsory), a weapons platform module and a weapon module (not compulsory).

09/30/2004 - Tom

The other day i wrote up a small document outlining the game concept of power and the relationship between power generation, power distribution and shields in Machinations. If you have any suggestions after reading the document, please make them in the comments! Following the creation of this document i modelled several stationary power generation units (PGUs), which you can see in the above image. Each PGU is comprised of (1) a collection module (a propeller, fan, or mirror panel, for example), (2) a power core and (3) a power distributor (not yet modelled). The power distributor establishes an electric field around the PGU of field range X and field strength 1/X.

Also complete is the first low LOD unit - the Barbarian. The low LOD model to the right will replace the high LOD model to the left at low magnification, using Jon's LOD system. I envision the low LOD models will trickle into the game without an extreme urgency, since they're not essential items. It's likely also the buildings and super units won't receive low LOD models.

Above is a 3D render of the final skinned Warrior, Barbarian and Raider mechs. These skins involve a number of manual steps as well as the use of the automatic texture actions i developed. There's a strong possibility faction decals will be skinned onto units in the future, when we have a better understanding of the final game. Different color themes can easily be achieved by manipulating the two color layers in the skins' psd files, which you can also see in the image on the right. Next i'll be modelling some new turrets which are more compatible with vehicles. Stay tuned!

09/21/2004 - Tom

09/19/2004 - Jon

Lately, I've started the Heightmap Manager as the first stage of the terrain system. The Heightmap Manager generates heightmaps from a variety of sources, such as random noise, an image file, or a spline surface. The utility also lets you combine heightmaps in bizarre ways by entering an equation. For instance, suppose you want to fade from heightmap HM00 to HM01 from left to right. Then, you can enter "(1-x/255.5)*HM00 + x/255.5*HM01". The utility evaluates this equation at every point, replacing HM00 and HM01 with the height of the corresponding points in HM01 and HM02. The utility also replaces 'x' and 'y' with the x- and y-coordinates of the point that the utility is currently evaluating. In this screenshot, I've superimposed two channels of noise using the max() function. The effect will look even more spectacular once I introduce spline surfaces and shademaps.

Once this utility is finished, I have plans for a Terrain Manager, which will load a heightmap as a grayscale image and generate a mesh. The Terrarin Manager may also let you apply textures and see the results instantly.

09/14/2004 - Tom

For the past two weeks I’ve been busily sketching the wheeled vehicles. Two models have emerged from the concept process thus far – a light buggy chassis and a heavy chassis which will likely be a medium to heavy class. These two vehicles like the others to come are basically just mobile weapon platforms. The size of the chassis will determine the size of the turret and in turn the size of the weapons. Jon and I had an inspiring brainstorm earlier this week on the future implementation of the unit customisation feature. We proposed a primary factory would produce the main chassis component of vehicles, while auxiliary factories would produce essential vehicle modules and source the primary factory. For instance, the primary factory producing tank chassis’, aircaft fuselages or ship hulls would be sourced by a propulsion factory specialising in wheels, propellers and thrusters, and a weapons factory specialising in weapon modules. Also discussed was a weighting system, to balance the vehicles. Each module in the Mach world would have a weighting, typically proportional to it’s power or effectiveness. Parent components would also need a weight capacity. When a chassis cannot support it’s payload it’ll move slowly and possibly loose hitpoints as it moves. (Since it’s components are overstressed.) In contrast a chassis with weight capacity to spare will move faster – hence unequipped buggies would be excellent for reconnaissance style missions.

The top image illustrates Jon’s cool idea of modular armour. The blue body armour forms an exoskeleton around the standard (but already devastating) M3 Warrior making it an incredibly enduring unit. Because the armour is made up of a number of separate plates it can be modularised – the entire kit or parts of the kit could be used. Most players would opt for the frontal chest plate and shoulder armour (offering the best coverage to key areas), while less would opt for the back plate. (Distinguishing front from back damage would entail a complex hit detection system, which probably is overkill for an RTS. Purchasing the back plate at this point would simply increase overall hitpoints.)

I’ve also started organising and mapping the weapon modules. So far six modules have been mapped. Two new modules have been modelled, too – the triblaster and fabricator gun.

09/06/2004 - Jon

I implemented my own mesh reducer using an algorithm that Michael Garland and Paul Heckbert developed here. The mesh reducer prioritizes each edge based on the amount of error that contracting the edge would introduce. It then selects the edge with the lowest cost (i.e., lowest error) and moves one of the two endpoints to the other end. This process repeats until the mesh contains the desired number of vertices or edges. In this screenshot you can see a close correspondence between the terrain's contours and the mesh triangles. The algorithm fills flat areas with large triangles and coarse areas with small triangles. Each LOD uses the same set of vertices, so I need to store only the vertex indices for each LOD. The mesh reducer takes about 30ms to reduce a tile containing 2,000 triangles. Since the map will contain upwards of 256 tiles, I'll need to preprocess the terrain and save the levels of detail in a file. I'm also considering using a 3rd-party utility to create and reduce the tiles. For example, Tom could create some modular tiles in Rhino 3D and decimate each mesh to the desired levels of detail.

I've started my next (and hopefully final) terrain LOD system. I divide the map into 256 tiles and draw each tile with high detail (512 triangles), medium detail (128 triangles), or low detail (32 triangles) depending on the tile's distance from the viewer. I also clip invisible tiles using a hierarchal visibility algorithm. When the LOD of a tile changes, I fade in the new LOD and fade out the old LOD. Thus, there are no abrupt changes in detail (except for the water plane--I haven't decided what to do about this yet). For each pair of adjacent tiles, I create six seams that bridge the gap from one LOD to another. The system works well, and it is much faster than my triangle bintree and square quadtree approaches. The first screenshot depicts several tiles transitioning to a different LOD. The second screenshot illustrates the triangles in each LOD.

View image 1
View image 2

09/02/2004 - Jon

comments: 10

08/22/2004 - Tom

Lately i've turned my attention away from the concepts and modelling and towards the tedious (yet strangely refreshing) process of skin mapping. The three mechs, small turret base and three small turret shells have been mapped, and likely the gun modules will follow, however i must first finalise the connections of the gun modules to ensure their universal compatibility between the "gunports" of mechs, tanks, ships and aircraft of all sizes. Using Jon's [awesome and effortlessly easy] mesh manager i've started the component library which currently consists of 29 components. In the animation above you can see three mech classes with three skin themes, automatically developed using macros.

With the mechs largely finished (I'll probably be postponing the fourth mech class and four legged platform) and a healthy array of turrets modelled i'll be soon focusing on modelling the much overdue wheeled vehicles. Stay tuned.

I've set aside the level-of-detail manager because I'm running into problems with semi-transparent faces. As I feared, textures with semi-transparent areas makes a smooth transition between two levels of detail nearly impossible. The semi-transparent faces either (1) occlude faces that are farther away or (2) overlap a semi-transparent area in the other LOD causing the area to become overly opaque. I could do away with semi-transparent faces and make a texel either full opaque or fully transparent. This approach also eliminates the need to sort semi-transparent faces because the order in which we draw the faces no longer matters. On the other hand, we may discover that an abrupt transition from one level of detail to another is tolerable, so we won't need to worry about fading in one LOD and fading out the other.

I'm now turning my attention to the networking module. The module has a number of tiers. On the bottom, the socket manager provides a uniform interface for TCP/IP and UDP socket connections. You can listen for connections, connect, and of course, transmit data. Next, I have a packet sequencer, which guarantees that UDP packets arrive at their destination. This may seem redundant since TCP/IP takes care of all of that for you, but this approach allows me to tailor the system to my needs. For instance, I can include X bytes of data from previous packets in each outgoing packet so the receiver can accomodate packet loss. I can also mark some packets as "out of band" so the receiver will process the data as soon as it arrives, even if it's out of order. Finally, I have a network module for establishing a server-client network. Each network "node" has a list of every other node in the node. The nodes can send messages, send files, send directories, drop users, etc. Once I get all of this working, the next step will be a more robust (and hopefully generic) synchronization system. My existing synchronization system works well because the bandwidth is so slow, but everything goes to hell if two computers get out of sync. In this event, I'm considering momentarily pausing the game and resynchronizing everyone. If you're interested in network synchronization or you know of a good solution, let me know.

08/13/2004 - Jon

comments: 34

08/11/2004 - Tom

Over the past couple of weeks I’ve been experimenting with ways of rapidly developing the unit skins. Because there will be dozens upon dozens of components to skin and human cloning is outlawed I’ve constructed a growing library of Photoshop actions which will automagically assist me by doing the repetitious tasks of skin design (for instance, the base coats like metal, eroded metal or camos and effect washes like rust, dirt and charring). This texture is an example of one of the macros in action. It cuts a good 2 hours of manual labour out of the skin design process for each skin.

The image above shows the 4 Mech classes together. The fourth in the series, the “Godslayer" (1, 2 - incomplete) will be enormously powerful and it’ll be fairly uncommon to see more than a few at a time. The head region will likely have a gun mount similar to the “Warrior" class mech.

Also modelled is a new palm tree (High LOD). I’d really like to modularise the fronds/leaves on the trees but this will probably be highly inefficient. Expect a skin soon!

comments: 3

08/07/2004 - Tom

I’ve managed to extend our modular unit theory to the building concepts – above is the standard shipyard, a factory which utilises several of the components of the ground vehicle factory and aircraft factory (coming soon). In the shipyard above the red arms connect to a rotating ring which builds a unit at it’s center. Once the unit is completed the entire ring structure climbs up the support pylons. In the ground vehicle factory the unit is built on an elevated platform which then lowers allowing the unit to exit underneath the rotating ring similarly to the shipyard. Soon I’ll be developing a single, extensible super factory which can expand to support vehicles of any size, unlike the standard factories.

Also complete is a collection of small turret shells; from left: dual shell (expensive), single shell (standard), inverted shell (greater angle of fire), magnetic shell (fast) and drum shell (high rate of fire). Underneath each shell you’ll notice the ground variant small turret base (The other variants being pontoon and submerged, coming soon). The gun module collection which I’ve reported earlier has grown slightly, with the addition (from left) of the laser lance, twin plasma cannon, torpedo cannon, tri-blaster, light cannon and dual light cannon.

The modular foot of the 4th mech class has also been modelled. This leg will connect to a special expandable chassis which can accommodate a whole range of different structures, from shield generators to gun or missile platforms to light mobile factories.

I’ve also modelled a low level of detail version of the Barbarian mech. Most units excluding buildings and super units will receive a low LOD model which will replace their high LOD model at low magnifications.

08/06/2004 - Jon

I finished the sound manager. I discovered that abruptly stopping a sound source prematurely is not noticeable unless your system supports fewer than 8 sounds sources. I also finished the mesh manager and the GUI for converting 3DS models to the native Machinations MSH format (formerly MOD). The mesh manager is one of the simplest modules--it simply loads vertex, normal, texture-coordinate, and face data from a binary file and draws the mesh using a display list and/or a vertex array. The mesh manager will load unit meshes, terrain decorations, 3D mouse pointers, 3D icons, etc. I decided to isolate meshes from skins so we can (efficiently) apply multiple skins to a mesh, and one skin to multiple meshes.

You can see a screenshot of the GUI here. The GUI lets you import 3DS models, break them into disjoint meshes, merge meshes, delete meshes, and save each mesh as a .MSH file. You can translate, rotate, or scale the vertices and texture coordinates. You can invert a mesh's normals or sort its faces using a variety of criteria. You can also apply skin to the mesh (although the utility doesn't save the skin in the mesh files).

Next, I'll turn my attention to varying the level of detail (LOD) of a model. The idea behind LOD is this: We'd like to draw each unit with 200+ faces at high zoom to showcase Tom's marvelous artwork, but at low zoom, 200+ faces/unit will kill the frame rate. Moreover, there is no point in drawing so many faces because many faces are the size of a pixel. Thus, I'd like to make three meshes for each unit--one with low detail, one with medium detail, and one with high detail. The number three is arbitrary--I'll have to experiment to see what works best. To avoid abrupt transitions between LODs, I'm going to fade in one LOD and fade out the other. This approach will lower the frame rate slightly because it increases the face count and uses alpha blending, but hopefully I can reduce the penalty by changing the LOD of only 10% of the units at one time. Unfortunately, generating meshes at three levels of detail is proving to be a challenge. Mesh reduction software doesn't work well because the meshes have so few faces to begin with. Does anyone have any suggestions? What would be ideal is a program that lets you reduce the mesh manually by selecting vertices to decimate or join. We also have to take care to preserve the texture coordinates since we'd like to use the same skin for every LOD.

I have a job opening for anyone who is interested. I want to build an abstract particle engine system for explosions, smoke, dust, bubbles, etc. Ideally, I'd like to parameterize it as much as possible so we can use the same particle engine for every effect. Also, I'd like to specify the parameters for each effect in a text file so users can experiment with new effects or improve existing effects. The system will need to efficient because there could be thousands of particles visible at once. Here are some other considerations:

* We'll need a clipping/level-of-detail mechanism. If a particle engine isn't visible, there's no point in drawing it or calculating the position of the particles (unless we want to anticipate movement of the view). Similarly, if we're viewing the entire map, then it's ridiculous to draw thousands of particles when each one is smaller than a pixel.

* There are three components to a particle--its position, color (including transparency), and texture. Typically, the particle will fade out (i.e., its alpha component will shrink to zero) and the texture will remain the same, but there are other possibilities. Each component is a function of time (and possible other factors such as elevation).

* Usually, we'll want to draw each particle perpendicular to the line of sight, but we may want to consider particles that appear differently from different directions. A model for each particle is overkill, so perhaps we could use a combination of sprites.

If you're interested, let me know. It's best for you to design and implement the particle engine as an independent module with a generic interface. This will allow me (and others) to easily adapt the particle engine to future projects.

07/31/2004 - Jon

The renovation is going well. I've finished the expression evaluator and the new texture manager. The texture manager consists of four parts: textures, subtextures, animations, and patterns. A texture is an image that I load using DevIL. A subtexture is a rectangular piece of a texture. An animation is a series of subtextures that I display in succession. A pattern allows us to elegantly texture boxes of different sizes. Consider a window in Windows, for example. As you resize the window, the corners remain the same, the edges stretch in one direction, and the interior stretches in two directions. To achieve this effect, we render a dialog box, button, etc., break it into nine subtextures, (four corners, four edges, and one interior), and enter the names of the nine subtextures in a pattern file. We also specify whether we want to stretch the margins and interior, repeat them, or tile them (a combination of the other two).

I've now started work on the sound manager. I'm still using OpenAL for the sounds, and so far, I'm pleased with it. At one time, I believed that OpenAL limited the user to 32 sound sources, but I've since discovered that this is a limitation of the sound card. Newer sound cards support 64 sound sources, but this still isn't enough for a real-time strategy game. Thus, I'm devising a priority-based system for clipping sound sources. Basically, I measure each source's "importance" as a function of its volume and user-defined priority. When I run out of sources, then I compare the importance of a new source against that of the least-important source that is currently playing. If the new source is more important, then I stop the old source and begin playing the new source. I haven't tried the technique, so I don't know how well it will work. If the early termination of a sound source is too noticeable, I might try queueing sound sources, or lowering the volume of sound sources that I'm about to terminate. I'm also planning to associate each sound file with a text file that describes the sound's volume, attenuation, and priority. This will allow us to create two sounds from the same file (for example, a loud explosion and a soft explosion). This will also allow us to create sounds that players can hear from anywhere on the map.

07/29/2004 - Jon

07/14/2004 - Tom

After a lot of concepts and sketches the Warrior and Raider Mechs have received their redesign. I’m overjoyed to say that these new developments mark the beginning of the end of the development of the units for Machinations – I’ve left the conceptual fog, so to speak – a clear concept for the game has finally hatched.

The 3 (and possibly a fourth to come) Mechs are perhaps the most time consuming of the units to design as each requires it’s own custom propulsion system. What dawned upon me several days ago was the highly extensible nature of the interface between a car’s wheels and it’s chassis. I proposed that in the Mach universe were the ultimate vehicles; uniform machines which could be adapted to land, water or air simply by altering their propulsion systems. Each propulsion system would interface with the vehicle as wheels would a car. The only requirement of this exciting opportunity for modularity is each propulsion module must have a cylinder or square of a specific diameter/length to fit snugly into the wheel (propulsion) port of each vehicle type. So far I’ve modelled 4 propulsion systems which will range in cost, speed, endurance and capability. From left: submarine module (underwater propulsion), armoured all-terrain wheel (slow, capable, strong), armoured wheel (strong) and conventional rubber wheel (fast). Soon to be modelled is a marine module (using propellers), an anti-grav module and perhaps a cheaper alternative to anti-grav: a hovercraft module.

Also modelled is the start of (hopefully) a very large collection of weapon modules available to all the vehicles (some exceptions will apply) in Mach. From left: heavy cannon, sniper cannon, dual lasers, ion rifle, ion cannon, dual particle beam and tri-rocket pod.

On the turret front I’ve developed quite a few turret “shells” – the casing around the gun modules of turrets (no screenshots yet), as well as a mobile turret base, available to small and medium turrets. This mobile turret module will basically turn static turrets into field artillery. It’ll also have a cute animation. You might be able to guess how it works by looking at the screenshot.

I'm in the process of renovating and testing all of the source code. My goal is to build a huge library of modules (e.g., a parsing module, a network modules, a texture module, a model module, etc.) that I can adapt to any project. Tom and I have enough ideas for a hundred games, so the library will have plenty of uses in the future.

At the moment, I'm revamping the parser yet again (this is the fourth revision). I've developed my own C tokenizer that reads numbers, identifier, strings, and operators from a file or string. I've also developed a C-style preprocessor that supports include files and macros. The preprocessor recognizes the following keywords: #define, #defblk, #enddef, #undef, #include, #if, #ifdef, #ifndef, #else, #endif, #concat, and #string. The #defblk and #enddef directives let you define a macro that spans multiple lines without the need to place a line-continuation character at the end of each line (this is a tremendous hassle in C). The #concat operator is similar to the C ## operator. It concatenates two identifers or two strings. The #string operator is similar to the C # operator. It converts an identifier to a string.

My preprocessor also lets you nest directives. For instance, you can type:

07/10/2004 - Jon


#defblk DEF_ERROR(x,y)
   #define #concat(ERR_,x) #concat("Error: ",y)
#enddef
DEF_ERR(TOOBIG,"The value is too big")

You can also type:


#defblk MY_INCLUDE(x)
   #include #concat("c:/my documents/",x)
#enddef

The second construct is useful when you want to define the location of all of your include files.

As a final example, you can write a macro to flag multiple definitions (my preprocessor allows them):


#defblk MY_DEFINE(x)
    #ifdef x
        #error #concat("You have already defined ",#string(x))
    #endif
    #define x
#endblk

MY_DEFINE(width) 100
MY_DEFINE(sum)(x,y) ((x)+(y))

The parser will be invaluable for unit definitions, animation definitions, and eventually, user-interface definitions. Next, I'll turn my attention to the expression evaluator, which will evaluate constant expressions like .sqrt.2/2 and variable expressions like active?0:(velocity*10).min.10

I implemented a Real-time Optimally Adapting Mesh (ROAM) using a square quadtree instead of a triangle bintree. Square quadtrees have a number of advantages over triangle bintrees:

06/22/2004 - Tom

The render above of the remodelled "Barbarian" Mech is one example of the new direction i’m now taking with the unit design. I've decided to modularize all the units in an attempt to foster component compatibility between mechs, tanks, ground turrets, ships and even aircraft, using Jon's very powerful reference frame and component transformation system. This will reduce the modelling and skinning load and vastly cut down the time i need to spend on the units overall. Also, this modularity will open the door to the possibility of ingame unit customization in the future.

Over the past few weeks i've been busy modelling some long overdue structures including a solar array, metal extractor, aircraft fabricator and wall concept (Check the forums for a small discussion on the walls). Also developed is a light aircraft fuselage, which will support a variety of wings including albatross (bomber) and sparrow (fighter). Upon these modular wings will hang modular payloads (From left - cluster bomb, conventional bomb, air dropped depth charge, torpedo bomb, all-purpose missile, heavy air-to-air missile)

I've also done a mental draft of the turret tech tree. Small, medium and large will form the 3 possible component bases for turrets, with the universal gun modules being built atop the base in a second, perhaps separate building phase (Similar to 2 stage GDI turrets in C&C Tiberian Sun). The 3 turret sizes will have definable foundations - small base turrets can be "grounded" (land), "pontooned" (water) or completely submerged - medium turrets can be grounded or pontooned (Gun module shown: the Cloud Hammer anti-aircraft gun, also fitted to the middle mech in the top render) while large turrets can only support grounded bases.

Jon and I have also more or less decided on some of the signature features of the mach world which will shape it, we hope, as an original and awesome game. Briefly these include the unit modularity mentioned above, distributed power and power grids, support and supply chains possibly including an ammunition system, mobile bases and mobile factories, super units, significant focus on long ranged weaponry and mass unit creation and expendability, CPUs permitting.

Enjoy the update and please, show your interest by posting a comment or something in the forums! :)

comments: 5

05/22/2004 - Jon

There are fewer intermediate nodes because each parent has four children instead of two.
Each leaf represents two triangles instead of one. (Actually, I ended up drawing four triangles for each leaf due to the way I handled cracks.)
Quadrees are ideally suited for a dynamic texturing system.

The only drawback is cracks. I discovered an elegant (although inefficient solution). I draw each leaf as a triangle fan. For each neighbor at a higher resolution, I add one vertex to the fan. The screenshot below illustrates the technique. Notice that the triangle in the center has dozens of vertices. Square quadtrees seem faster than triangle bintrees (it is difficult to say for certain because I haven't optimized either implementation). Nevertheless, the frame rate is still unacceptable. The computer is spending too much time tessellating the mesh and outputting the vertices. Since the mesh constantly changes, caching the vertices is difficult. I'm now considering dividing the map into about 1024 blocks. I will then render each visible block using a predefined set of vertices according to its distance from the viewer. Jon Blow has an excellent example of the technique
here. By generating seam triangles and fading between levels of detail, the transition from one level of detail to the next is almost imperceptible.

The second screenshot below illustrates a technique I conceived for making the transitions between textures more interesting and realistic. I use a noise map to bias each texture's transparency near the edges.

Square quadtree
Noise map for texture transitions

User's view

User's view with visible mesh

World view

05/17/2004 - Jon

Now that the spring semester has ended, I've resumed development on Machinations. I have a week off until my summer job begins on May 24th. My summer job is full time, but hopefully, I will have plenty of time (and motivation) left over for Machinations.

I'm now revamping the terrain (for the third time). Tom wants to add details to the terrain like roads. I'm currently blending triangles to achieve smooth transitions between strata. This method works well as long as only two textures meet at each triangle, but becomes costly when the user randomly distributes textures. This method also uses processor-expensive multitexturing and blending. I decided to implement a fully dynamic level-of-detail (LOD) system for the mesh and textures using ROAM as a starting point. ROAM provides excellent results with little optimization because it takes advantage of view coherence. With 10,000 polygons (approx. 4,000 visible polygons), my implementation took only 5-8ms/frame to update the view when panning at full speed. ROAM also lessens the appearance of sudden jumps from one LOD to another. I implemented everything according to Mark Duchaineau et al's paper here with a few exceptions: (1) I used a heap instead of a queue; (2) Rather than projecting a triangle's height error on the screen, I just multiplied the height error by the triangle's minimum distance from the viewer (its w coordinate); (3) Placing an upper bound on priorities sounded complicated, so I resorted to discrete distance groups. A triangle's height error remains constant and I update each triangle's visibility and distance group each frame with two optimizations: (a) If a triangle is entirely visible (or invisible) and fits entirely within one distance group, then all of its children are also visible and belong to the same distance group; (b) If a triangle remains entirely visible (or invisible) and it still fits entirely within the same distance group, then there's no need to update its children. I am using about 3 distance groups at a time, which seems to work well. I haven't profiled the code, so I don't know how much these optimizations improve performance.

I implemented a texture LOD system that is analogous to ROAM. I begin with a single 256x256 texture that covers the map. I then select one quadrant and render a 256x256 texture for it. Thus, the second texture has twice the detail (i.e., texel:world coordinates ratio). I construct a quadree of up to 64 textures that I update before each frame. I also have a texture-creation queue and texture-removal queue that are analogous to the split queue and merge queue. The system works well, but it needs a lot of optimization.

The first two images illustrate the user's view. Notice that the triangles are approximately the same size, and the textures are all crisp. The third image shows the entire world. Notice that the mesh and textures are course in areas that the user cannot see.

The 3rd of the three mech classes - the Warrior - has been skinned! This week i've also sketched a repair pad and aircraft factory, which i'll be modelling soon. We might be releasing the next version of Machinations in early or mid May, so stay tuned!

04/24/2004 - Tom

comments: 4

04/20/2004 - Tom

Above is an image of the skinned thunder artillery tank. It would be cool if land-only vehicles could detect shallow water and be able to move through it, as in the render (The water doesn't look shallow, but it is =) ).

I've given some thought to the random terrain and stratum system Jon and I have been perfecting for some time now. It's main drawback at this point is extra terrain details like roads and nonconforming strata like random dirt patches etc cannot be added. Additionally there are some texture blending issues when the surface is steep. As an alternative, using Photoshop it's quite easy to design an image to generate a custom terrain heightfield in Rhino. Posterizing the image simplifies the color levels and defines each strata which can then be filled with textures. After applying the strata textures (which can be applied in any degree of transistion, or "feather" in Photoshop) extra details can be added to the texture like roads. Check out the process below and a render of the example terrain.

Example Texture
Example Textured Mesh

Today i've mapped and skinned the archer tank and mapped the thunder artillery tank. Using a premade dirt/wear overlay i can quickly and easily create skins better than i could before. I've created a promotional render of the new Archer and some of the other skinned units, shown below. I plan to do the unit renders for the build menu this way.

04/19/2004 - Tom

Just a small update with some new unit models. I'm having some trouble conceptualizing decent looking rocket/missile units, so i'll likely model some buildings next. Please provide your suggestions in the comments if you have any!

04/18/2004 - Tom

comments: 4

04/09/2004 - Tom

Progress has been slow lately with Jon and I both busy with study. I've got a week off from uni which will likely give me a chance to model some new units and skin the Warrior mech. Today i made some aesthetic improvements to the terrain - Unfortunately the trade-off of nice terrain at a distance is ugly pixelated terrain at high magnification. A solution to this would be a texture replacement as the zoom changes, or a zoom lock.

In other news, we've purchased a domain, machrts.com, which we will likely use in the future. Stay tuned, and please, support us by commenting on the news!

Terrain Improvements (1) (2)

The Warrior class mech has been completed! This beast is the 3rd tech level of the Mechs, second largest only to the Godslayer Mech class, which will be revealed soon. The Warrior class assault Mech sports a “Swarmer” guided chaingun and an “Annihilator” heavy antimatter cannon. The device mounted on it’s shoulder uncloaks units and paints targets for bombardment. The fusion reactor within the Warrior’s chest which powers it’s movement, computations and weapons can be destabilized to elicit self-destruction. (Yes, it's a walking bomb too) =)

03/07/2004 - Tom

Also completed is the “Mako” anti-naval ground turret. This unit may replace the Rhino. A few days ago I also added a screenshot of the metal and energy storage units, which can be clustered together to provide an economic advantage. Enjoy!

Warrior Mech
Mako Turret
Storage Units

Yesterday i completed a detailed palm model which reached a level of decency surprisingly fast. The model uses 141 triangles which isn't too bad considering around a third of the triangles are duplicated backfaces of the palm fronds. (Allowing you to see the underside of the leaves.) Currently the palm uses a 256x256 texture. In the ideal situation, the high detail palm model would switch to a 128x128 texture before switching models and using a 64x64 (Or smaller) texture as the player zooms out. When you see the palms, notice how kickass Jon's shadows are looking =)

Next i'd like to skin the Mech fabricator and possibly some turrets like the Overlord and Phalanx which have been sitting around for some time. Stay tuned!

Detailed Palm (1) (2) (3) (4)

03/02/2004 - Tom

Lately i've turned my attention back to the terrain textures, which i've optimized and improved slightly. The less important textures which simulate the reef and underwater terrain have been reduced in size along with some of the beach textures. The tile size has also been reduced on most textures which virtually doubles the terrain texture quality. Next on my list is to model a detailed palm tree which will replace the low detail palm tree at higher magnifications.

In the unit department i've given all the skins a new worn and dirty overlay to reduce the bare look. I've also modeled and mapped the first factory; the Mech Fabricator Tech 1. This is the simplest Mech factory and the current idea is it will be the game's seed - each player will begin with a levitating Mech Fabricator which he/she can move (slowly) around the map until a suitable location is found to set up a base (Similar to the unfolding base vehicle in C&C: Red Alert). The Fabricator will then be ordered to land and Raider class Mechs can be built and a base started. Unfortunately with this idea there would be no commander style unit, unless the commander is actually bundled inside the Mech Fabricator at the beginning of the game and then exits once it's landed.

New worn textures
Worn texture close up (1) (2) (3)
Improved terrain look
The Mech Fabricator Tech 1

02/24/2004 - Tom

comments: 4

02/18/2004 - Tom

I’ve devised a relatively quick routine of adding wear to unit textures for the interchangeable texture idea where a unit’s look will depend on it’s health status. A simple painting procedure is necessary for there will be scores of unit models each requiring multiple textures. I think 3 texture levels, which would include the new texture, worn texture, and very worn texture would be sufficient. There would also need to be a 4th texture and most likely a separate model to represent a destroyed unit. Here we could get away with all Mechs of the same class sharing a single destroyed model and texture.

Check out the screenshot here. Note that the Barbarian’s body texture has the worn effect but not the guns, because I was lazy =)
I thought i'd add news more regularly, even if it's not earth shattering, to encourage suggestions and regular visits.

comments: 5

02/13/2004 - Tom

I've added two new screenshots to the gallery - The first shows the newly skinned Assault Barbarian with it's little brother the Assault Raider. The second is an artist's impression of a nuclear artillery bombardment. (Yes, I’m the artist) =)

Enjoy!

Raider and Barbarian classes skinned
An Overlord (turret) slows a Mech invasion

02/10/2004 - Tom

I finally got around to composing a long overdue unit list which you can find on the units page here. I'm glad I’ve done this as it's provided me with a solid direction and no longer do I feel like I'm muddling around with ephemeral concepts.

The main innovation in the unit list at this point is the four sequential Mech Classes. Each Mech class includes at least an assault, artillery and "Archimech" (Jon's I.P. =P) variant. The heavier classes (Warrior and Godslayer) will include extra variants. The assault and artillery variant Mechs will become bigger and more powerful with higher classes, while Archimechs (Construction Mechs) will become more architecturally capable (More build options, faster fabrication) with higher classes. When the Mech factory is first built, only Raider (Class 1) Mechs will be available. To make available the Barbarian (Class 2) Mechs, an Archimech Raider must be produced and then ordered to upgrade the Mech factory. The Archimech Barbarian can then upgrade the Mech factory to a Warrior (Class 3) capable factory, and then finally, the Archimech Warrior can make available (Unleash, rather) the Godslayer Mechs (Class 4). While the higher classed Mechs will be more advanced, the Raider (Class 1) Mechs will have a mobility advantage and be very cheap and quick to manufacture. This will ensure (I hope) the Raider's usefulness at all points in the game.

3 of the 4 Mech Classes

The Assault Raider is equipped with dual "Plas-Hammers" - rapid firing plasma guns, while the Assault Barbarian is armed with dual SDO Rifles (Super Dense Ordnance). The SDO Rifle will fire a super synthetic neutron pellet - a bullet with enough momentum to penetrate several meters of concrete.

If you have any suggestions for the Mech system, please make them known in the comments!

I've added a commenting system to the news, so now anyone interested in Mach can discuss with us new developments. Feel free to contribute your ideas :)

In the unit department, I've finished modeling and animating the small mech, which has been named the "Raider". It will come in a variety of flavors, including assault, artillery and support variants. Using "ELEVATION=seafloor" the mech follows the water bed, giving it a mobility advantage over other vehicles. Also completed is the new Titan tank, which is roughly twice the size of the old Titan (Now the "Paladin"). If you haven't browsed the units page recently, take a look - I’ve added a number of new units.

The new units
A Massive Army

02/01/2004 - Tom