Machinations now compiles on Linux (the version I was using, at least). Unfortunately, I couldn't get Machinations to link. I'm having problems with the makefile and I'm not sure how to link the libraries (OpenAL, DevIL, and GLFW). The new source code in on CVS. BTW, school starts next week, so I won't have as much time to work on Machinations in coming weeks.

I've posted some screenshots of the revised Phalanx and Rhino turrets as well as a new heavy turret, the Punisher. It was necessary to remodel the turrets since they didn't support ascension - an (awesome) ability which Jon's animation system now allows us. The Punisher will be a heavy offensive ranged-bombardment turret, much like the Guardian from TA. It would be cool if it's ascension could be controlled only manually using a command button, forcing a major case of trial and error and estimation when firing - for instance, each press of one command button would ascend the turret 5 degrees and a neighboring button the reverse of this. This would limit the effectiveness of the (powerful) turret and add some interactivity. The Rhino will now be a medium range defensive turret and the Phalanx a light ground and air defensive turret. The Phalanx will sport an unfolding animation on_creation similar to the old animated sprite units of C&C.

Also in the works is a mech unit. I'm currently having some difficulty with the walk animation. I plan to assign a dynamic translation to the entire mech, making it appear to bop up and down as it walks. Expect a screenshot soon!

Revised Phalanx
Revised Rhino
Punisher
Turret Scale

I'm nearly finished testing the model animations. I have created 26 test units, each of which has a unique animation and/or behavior. The production behavior allows a factory to manufacture units, one after another. I've added almost a dozen parameters to the production behavior to make it as versatile as possible. The factory controls its "product" using an invisible tractor beam. The tractor beam allows the production behavior to rotate the product while its under construction and eject the product through a door and down a ramp when it's finished. Today's screenshot depicts a factory that can do exactly that. The product remains under the influence of the tractor beam until it reaches the base of the ramp. Thus, although you can issue move orders to it while its still under construction, it won't respond to these orders until the factory releases the tractor beam. This prevents the unit from rolling off the edge of the platform (or worse, moving through a wall). The factory also animates the four pillars. The concentric cylinders extends upwards when construction commences.

View factory

I posted a screenshot showing the third type of transformation: a color transformation. You can use color transformations in conjunction with textures to achieve interesting effects such as flashing lights and thrusters that illuminate when the unit moves. In this example, the cube cycles through the colors: red, yellow, green, cyan, blue, and purple. The four lights flash in succession.

The model animations are now finished, but I have a lot of testing and polishing ahead of me. I posted two new screenshots. The first screenshot shows a model with two nested levels of rotation. The large spheres revolve around the cylinder horizontally and the smaller spheres revolve around the larger spheres vertically. The spheres slowly accelerate when the unit is born, and the spheres rapidly decelerate when the unit dies leaving a static wireframe. The second screenshot illustrates a texture coordinate translation. The message, "Milk. Get it. Got it? Good.", slowly revolves around the cube. This method relies on texture repetition (e.g. GL_REPEAT) to join the ends of the message together. Hopefully, I can devise some other nifty effects also. Check the screenshot section often for more goodies. =)

In other news, I discovered a reasonable method of clipping shadows cast by underground polys. It's almost impossible to use depth testing since depth testing operates on clip coordinates and my projection matrix flattens the polygons onto a plane. Instead, I set up a user-defined clipping plane that is parallel to the ground at the unit's base. A user-defined clipping plane is ideal since it works on eye coordinates.

It was two years ago today that I posted the first announcement on this website. Look how far we've come! Happy New Year's!

I'm making excellent progress on the unit animations. I've finished writing most of the code but I'm a long ways from testing it. The most challenging part will be writing a generic aiming routine that works for any combination of moving parts. Here is a sample script for a metal extractor. Similar to Total Annihilation, the metal extractor has a spinning top that accelerates. Merry Christmas!

MODELTYPE
	NAME collector
	DEFINE_VARIABLE
		NAME top_rotation # This variable determines the angular position of the top
		MAX_ACCELERATION 1
		CHANNEL
			NAME primary
			# We will change the target_velocity of the top.
			# The top will accelerate or decelerate until it reaches the velocity that we specify.
			ATTRIBUTE target_velocity
						
			INITIAL_VALUE 0
			INITIALLY_ACTIVE true
		END
	END

	# The top begins spinning once the unit is constructed.
	DEFINE_PROCEDURE
		NAME start_collection
		ASSIGN 10 TO primary OF top_rotation
	END

	# The top decelerates if the player shuts it off.
	DEFINE_PROCEDURE
		NAME stop_collection
		ASSIGN 0 TO primary OF top_rotation
	END

	REFERENCE_FRAME

		COMPONENT	
			MODEL cbase.mod	# The model containing the unit's base
			SKIN collector.png
		END

		REFERENCE_FRAME

			# We want this reference frame to rotate around the one above.
			# The vertex transform block ultimately calls glRotatef, glTranslatef, or glScalef.
			VERTEX_TRANSFORM
				KIND rotation
				AXIS 0 0 1
				VARIABLE top_rotation
			END

			COMPONENT
				MODEL ctop.mod # The model containing the unit's top
				SKIN collector.png
			END
		END
	END
END

UNITTYPE
	NAME collector
	MODEL_TYPE collector
	...
	SCRIPT
		NAME collection
		...
		# The script calls our procedures when collection begins or ends.
		ON_START_COLLECTION procedure start_collection
		ON_STOP_COLLECTION procedure stop_collection

		# This parameter lets our model communicate with the script.
		# The unit collects 5 resources/sec when it's first built, but
		# it collects 10 resources/sec after it reaches full velocity.
		COLLECTION_RATE DEFINE_FUNCTION
			VARIABLE velocity of top_rotation
			MAP 0 to 5
			MAP 10 to 10
		END
	END	
END

At last, we bring you Machinations 0.35! Enjoy!! Unfortunately, we haven't had much time to test or polish the release, so it's bound to have lots of bugs. I just uploaded the ZIP file to SourceForge, so it will be a few hours before you can download it. In the meantime, you can download it here. Double-click game1.exe to start the game. The game contains all of the features added since last January:

• Unit Scripts
• Help System
• Unit Models
• Automatic Repairs
• Turrets
• Armor Classes
• Terrain with spline surfaces, strata, waves, adaptive meshes, shadows, and decorations
• Perspective Projection
• Font Manager
• Texture Manager

I revamped Koom's old TEXture EDITor. The program worked well, but unfortunately, it only supported Windows bitmap files. I developed the new texture manager using a combination of Borland's Visual Component Library (VCL) and OpenGL for the central drawing area. The OpenGL drawing area allowed me to load images with DevIL and refresh the textures very quickly with double buffering.

The texture manager lets us arrange many images on an OpenGL texture. Each image has a unique identifier so that the game knows where to find it. The first screenshot below shows the texture containing all of the command icons.

Texture Manager
Font Manager

I'm finally finished with the shadow mapping. I spent the longest time tracking down a driver bug that was causing bright artifacts to sporadically cover the terrain. For some reason, the bug only appeared when I used a combination of glCopySubTexImage2D and multitexturing with at least three textures. In the end, I added a 20-line hack that seemed to resolve the problem, but I have no idea how.

I'm now turning my attention to some smaller tasks. Yesterday, I developed a system for caching terrain data in temporary files so that the game starts much faster. If you don't change any of the terrain variables, the game automatically loads terrain data from the cache instead of recalculating it. At the moment, I'm revamping the font manager to make it more versatile. The font manager lets you import any number of TrueType fonts into Machinations. The program automatically arranges the characters on a 256x256 texture for the best fit.

Tom posted a couple of new screenshots here and here. Enjoy!

I've added a units page you can check out here. I'll be adding unit descriptions soon, which will likely change over time, according to background/story alterations. I have a heavy field generator in the works, and I'm hoping to begin on a construction unit, artillery tank and a tank factory. Stay tuned!

Voila! A new look! This design was sitting dormant for some time and it's finally been given life. It won't be the last design to grace Machinations mind you, I forsee once we all have a clearer idea of what the Mach world will look like and how the background will operate a more appropriate and atmospheric design will appear (Probably similiar to the ingame interface in development). Over the last month or so I've been slowly discovering a style for the Mach units - let me tell you, the need for high performance is an enormous inhibitor on the exploration of good form!

Currently the working army includes a power plant, field generator, substation, several turrets and 2 tanks. With a few allowances this probably warrants a playable game! Woot! In other areas, the terrain is absolutely kickass, period. The interface on the other hand has been on hold for some time, and it will probably stay this way for some time yet.

The Guardian (Small) and Titan (Heavy) Tanks
All the units in a jumble
More units in a jumble
The Ion Distruptor (A super weapon)

Tom has been designing some decorations for the terrain. Decorations are small inanimate objects like trees and rocks. Meanwhile, I've been developing a new method of projecting shadows onto the terrain. I scrapped the old projection shadows since they were causing me a lot of grief. I'm now using an ad-hoc shadow map (see my post on the forum for more info). Enjoy the screenshot!

View image

I posted a new screenshot here. Tom is working wonders with the terrain strata.

I decided to calculate the strata using a secondary spline surface surface rather than basing the strata entirely on the elevation. Each control point now has a stratum index in addition to the elevation. The stratum index is a floating-point value that determines which strata are present. For example, 1 means stratum 1 dominates the area. 2 means stratum 2 dominates the area. 1.5 means that stratums 1 and 2 are blended 50/50. The screenshot shows an ordinary height map with a small random component added to the stratum spline surface.

View image

I posted a screenshot showing all of our textured units so far. Tom is doing a marvelous job (as always). Keep up the good work!

View units

I developed a neat way to achieve sharp transitions between strata. Rather than blending, I calculate the points at which the stratum boundary crosses each triangle. I then connect the points to form another triangle inside the original. The algorithm produces remarkably smooth curves with a reasonable number of polygons. Enjoy the screenshot!

View image

Excellent news! I discovered a brilliant way to vary the detail in the terrain using an adaptive mesh. The algorithm is remarkably simple. I start with two right triangles that cover the entire map. Then, I repeatedly break the triangles in half if the actual elevation at the center of the triangle varies by more than 0.01 from the expected elevation. I arrange all of the triangles in a binary tree so that I can control the detail level and I can quickly clip areas that are outside of the view. For anyone out there who is thinking of developing their own terrain, spline surfaces and adaptive meshes are definately the way to go.

View high detail mesh
View low detail mesh

I posted some more screenshots here.

Well, I've done it again. I discovered a neat way of making rivers using the cross-section of a spline surface. I also made the spline surface definition more versatile allowing for a huge assortment of effects. Enjoy the screenshots!

View icebergs
View frozen world

Today, I devised a system for defining up to eight strata. Each stratum definition looks like this:

	STRATUM
		TEXTURE red.bmp
		SCALE_X 1
		SCALE_Y 1
		MIN_ELEV 1
		MAX_ELEV 2
	END

The TEXTURE determines the texture associated with the stratum. The MIN_ELEV and MAX_ELEV determines the range of elevations in which the stratum is most prominent. I also devised a system for defining up to eight spline surfaces. The game superimposes all of the spline surfaces, allowing you to create some interesting effects. Each spline surface definition looks like this:

	SPLINE_SURFACE
		AMPLITUDE 20
		WAVELENGTH 5
		MODULATION_WAVELENGTH 16		
		MODULATION_SCALE 2
		MODULATION_BIAS -1
	END

You can think of the spline surface as a 3-D waveform. The amplitude determines the variation on the z-axis. The wavelength determines how closely the waves are packed on the x- and y-axis. The modulation parameters allow you to mask the spline surface in some areas.

Eight strata with three frequencies
Tropical islands

I am spending some time on special effects, mainly because it is fun an relaxing. I have replaced the main menu with a menu cube that spin freely while the mouse is elsewhere on the screen. When you move the mouse over the menu cube, it "comes to attention" and the current menu slowly wobbles in place. When you click one of the buttons, the cube spins to reveal another face with a submenu on it. Tom and I are also developing a shockwave using OpenGL blending. OpenGL offers an assortment of blending operations such as addition, multiplication, and even squaring. I produced the effect below using this statement:

glBlendFunc(GL_DST_COLOR, GL_ONE);

Tom is also doing an excellent job on the units. The third screenshot shows a small base with three new units. The gigantic structures are repair pads. The structures will automatically heal friendly units in the vicinity. The guns around the perimeter are light particle cannons. The small structure in between are substations. Enjoy!

View menu cube
View shockwave
View new units

I'm slowly making progress on the terrain. Today's screenshot shows a 512x512 map. The map uses an 8-bit 1024x1024 shade map, an 8-bit 1024x1024 water map, and 4 4-bit 512x512 alpha maps. Altogether, the six maps consume 2.62MB of video memory.

View 512x512 map

I'm making excellent progress with the terrain. Today, I implemented a 512x512 alpha map for the water. Formerly, I was relying on depth testing to clip the water plane at the water's edge. This works well for normal zoom, but as you reduce the number of polys, the resolution of the water's edge decreases drastically. Entire islands become submerged underwater and the ocean floor rises above the water in places. In the end, I decided to turn off depth testing and modulate the opacity of the water using an alpha map. With the help of multitexturing, I combined the alpha map with the water texture and drew the water plane all at once. The advantage of this method is the phenomenal resolution at low zoom. I produced the first image below using 256 quads for the land (not including the units and palm trees) and 1 quad for the water plane. The disadvantage of this method is an occasional artifact. Since I turn off depth testing, the water is sometimes visible through a mountain which is in front of it.

Low zoom
High zoom

This is going to be another announcement that starts with 'Hello, everyone'...

Hello, everyone! Just wanted to let you know that Machinations is still alive. I'm making excellent progress on the surf! Believe it or not, the image below is the product of four hours of programming! Seriously, if everything were this easy, the game would be finished by now. =) You have to see the waves in motion to fully appreciate the effect. Enjoy! Hopefully, I'll have some more news shortly...

View surf

Here is my latest screenshot. I'm really pleased with the water. Enjoy the palm trees! =)

View terrain

Well, I've done it again. Light maps are so cool! I produced the lightmap below with 20 lines of code. I simply calculated the dot product of the light vector with the spline surface's normal at each point. I saved the lightmap as a 1024x1024 texture and covered the mesh with it. Miraculously, I managed to reduce the number of polys 16-fold and the contours in the mountains still appeared sharp and crisp. I applied the grass, sand, and rock textures using the same method as I did for bump mapping. I use the OpenGL blend function to multiply the source color with the destination color at each point.

glBlendFunc(GL_DST_COLOR,GL_SRC_COLOR);

View light map
View light map over mesh
View terrain 1
View terrain 2

Hello, everyone! I just wanted to let you know that Machinations is still very much alive. I've been working on the graphics lately. I decided to replace my old isometric projection with a perspective projection. An isometric projection is only suitable for 2D games like Starcraft where all of the graphics are sprites. The perspective projection accentuates the contours of the terrain and adds realism to the scene. I am also experimenting with random terrain generation again. The maps from Bryce lacked the familiar realism of my earlier work with random terrain generation, mainly because bump mapping created a uniform texture over the whole map. It's hard to beat the realism of a rolling green pasture. I generated the images below using spline surfaces of varying frequency. For anyone interested in generating their own random terrain, spline surfaces are definately the way to go. The trick is to mask the spline surfaces so that certain frequences are more pronounced in different areas. You can also use spline surfaces to cover the mesh with a variety of seamless textures. The water is composed of transparent blue polygons (no texturing) that rise and fall in a sinusoidal manner.

In other news, Tom is doing an excellent job on the user-interface. The command-panel will have three rows for basic commands, advanced commands, and custom unit abilities. The build options will go in a separate palette, similar to Total Annihilation or Red Alert. The Stats windows will contain information about the current selection such as health, firepower, and armor. The player can close the windows when not needed, and quickly access them from the Panels menu.

View terrain 1
View terrain 2
View terrain 3
View terrain 4
View terrain 5
View interface

I'm sorry to disappoint everyone, but Machinations 0.35 will not be released until August. I haven't had the time or energy to work on it lately. Fortunately, I'll have plenty of time to work on it next month.

I added several new jobs to the Jobs section. If any of these interest, please let me know and I'll send you more information.

On Friday, I experimented with projection shadows. Projection shadows are easy to make. You just change the color to translucent black, multiply the modelview matrix by a shadow matrix, and draw the unit a second time. Projection shadows offer a number of advantages over static shadow models (which I was using before).

• The shadow changes shape as the unit rotates
• You can easily cast the shadows radially around a nearby light source (e.g. an explosion)
• The shadows permit transparent textures (see trees below)
• The shadows appear correctly beneath a unit under construction (see turret below)

The only drawback to projection shadows is that they can't cover other units (unless you disable depth testing and draw the shadows last). In other news, Tom designed some palm trees. Right now, we're treating the palm trees as units. This permits us to move the palm trees and even command the palm trees to attack. It's kinda cool, actually... Eventually, I'll design a simple terrain model class for trees, shrubs, rocks, etc. Enjoy the screenshots!!

View shadows
View trees

Today's screenshot shows a cloaked turret with transparent faces in its barrel and nozzle. This effect was easily achieved using blending and alpha testing. The alpha test is needed to ensure that a transparent polygon does not cover any polygons beneath it.

View cloaked turret

I'm making excellent progress on the terrain. I learned a simple algorithm for calculating a 3D spline (which I like to call a splane). Unlike a Bezier surface, you can calculate any point on the splane using a linear combination of 16 control points. If you calculate the linear coefficients ahead of time, the algorithm is very fast. The first screenshot shows a splane using the control points in the badlands map. I intentionally left out the diffuse texture so you could see how smooth the surface is. Splanes also provide an elegant method of calculating the normal at any point in constant time.

Tonight, I added four recoil parameters to the turret script: barrel_model, recoil_distance, recoil_rate, and return_rate. These parameters allow you to slide the barrel into the turret after each round. I also added a paramter called idle_speed that lets you rotate the turret at a constant speed when idle.

Tom finished the Rhino class heavy particle cannon tonight. It looks fabulous! (see below)

View splane
View cannon
View cannons engaging enemy
View idle cannon revolving

I finished bump mapping tonight. Once again, the results took me by surprise. Bump mapping truly makes the scene look three dimensional. I calculate the bump map offsets based on the light position and the surface normals. As a result, the bumps are naturally less pronounced on surfaces that face the light source (see image below). I also load the bump map from a bitmap file, so you can specify different bump maps for different landscapes. Unfortunately, I don't yet have any way of combining different bump maps in the same landscape, so if the landscape has a combination of rock, grass, sand, etc., you'll have to create a generic bump map for everything.

In other news, Tom is doing a phenomenal job on the units and buildings. Tom unveiled the Enforcer tonight (see below).

View bump mapping 1
View bump mapping 2
View Enforcer

No announcements to make today, but I wanted to post another screenshot. I achieved the water effect purely by accident while fooling around with color scaling.

View image

I added water to the terrain this weekend. Each tile has a flag that determines whether it is underwater. The terrain conversion utilty generates the water flags using a simple flood fill algorithm. First, it marks every tile that is below a certain depth (e.g. z < -1) as an underwater tile. Then, it marks every tile that is below sea level (e.g. z < 0) and adjacent to an underwater tile as an underwater tile. The algorithm continues until no more tiles meet the criteria. This process eliminates ugly pools that only span one or two tiles.

I'm also experimenting with two water planes that oscillate independently of each other. The water plane below is completely opaque, whereas the water plane above is partially transparent. The effect makes the water appear more fluid and dynamic.

This week, I'm hoping to add bump mapping to the terrain and draw the terrain as a NURBS suface of some sort.

View water
View our first building

This week, I successfully integrated the terrain into Machinations!! Tom and I produced the images below using a 1024x1024 diffuse texture and a 50x50 square mesh, both from Bryce. The units follow the contours of the terrain fairly well, but they have a tendency to bottom out (e.g. become partially submerged in the terrain) at the base of steep cliffs. The units also have also developed the uncanny ability to shoot through mountains. Enjoy!

View image 1
View image 2
View image 3
View image 4

This weekend, I implemented armor classes. Tom and I were discussing the comical situation where a dozen marines destroy a tank effortlessly with their machine guns. Certainly, the bullets would simply bounce off the tank's armor, leaving the tank unharmed. Thus, we decided to subtract the tank's armor from the damage inflicted. For example, if a marine inflicts 10 damage and the tank's armor is 8, then the tank sustains 2 damage. We also decided to assign unique armor values for each type of damage. For example, a tank might be nearly invulnerable to machine gun fire, but very weak against lasers. This will add a new dimension of strategy to the game because players will have to select the best combatants to attack enemy units. Also, it reduces the importance of firepower (e.g. in Starcraft, you were nearly assured victory if you had 20 battlecruisers. Perhaps some units are strong against air assaults but weak against hand-to-hand combat, making a combined air and land assault the most effective strategy).

I also thought of an interesting use for the "Evade" command. In Age of Empires, archers were annoying because they could harass your units from a safe distance, and when you tried to kill them, they retreated towards their base. In Machinations, you could order a unit to stay outside an enemy unit's range, but just close enough to continue firing at the enemy unit. Thus, you could dispatch a band of scouts to your enemy's base and harass their defenders. If any enemy units approached you, your scouts would automatically retreat to a safe distance and continue to harass their pursuers.

I'm sure many of you are anxiously awaiting the next release. I want to implement the new terrain and do some system testing, so you can expect Machinations 0.35 early next month. =)

Well, I've done it again. The turrets have exceeded my wildest expectations. Today's screenshot shows my tanks (top) beating up on some dumb computer tanks (bottom). Notice the red repair beams? These tanks automatically repair each other in battle. =)

View image

Today's screenshot shows the early stages of turrets. The medium tank's turret automatically tracks the heavy tank and fires when the heavy tank is within a 17 degree sector.

View image

It's been a while since I posted here. I'm currently revising the construction and combat scripts so that construction units automatically repair nearby damaged units, and tanks can have multiple weapons that operate independently of each other. This will permit tanks to fire at multiple targets simultaneously. I'm also implementing a turret script that will rotate a turret at a fixed velocity towards the current target.

Tom designed a new unit this week, the Patriot. Tom and I are also considering replacing the existing terrain with 3D landscapes from Bryce. Bryce exports the landscapes as 3DS models with a diffuse color map and a bump map. All I need to do is load the height map and textures from a file instead of generating them dynamically. Enjoy the screenshots!!!

The Patriot
Landscape 1
Landscape 2
Landscape 3

Last night, Tom developed some skins for the light tank and I imported them into Machinations. I'm really impressed with the results. See for yourself!

View image 1
View image 2
View image 3

I'm continuing to develop the models in my spare time. Tonight, I developed a simple construction animation using the individual triangles that compose the model. Sound familiar? Well, I didn't copy everything from Total Annihilation. =) Notice the red repair beam emanating from the tank on the right. The red repair beam focuses on the triangle currently under construction. A wire mesh will ultimately replace the old-fashioned blueprints in some shape or form. Perhaps a grey wire mesh could represent a blueprint (e.g. plans for a new building) whereas a green mesh could represent a building under construction. Anyway, enjoy the screenshot below!

Tank under construction

Ladies and gentlemen, the moment you've all been waiting for... I'm pleased to announce that I have successfully imported models into Machinations. I eventually decided on the Quake II MD2 format for simplicity. Rhino (the 3D modeling program that Tom Pittlik is using) exports models in 3DS format, and I downloaded a shareware program, 3DWin, that converts 3DS models to the Quake II format, so in the end, it worked out quite well. With a little extra modeling and programming, Tom and I placed shadows beneath the tanks. The results speak for themselves. The shadows truly lend a sense of depth and realism to the scene. Stay tuned for more exciting developments!

Tank 1 (No shadow)
Tank 2 (Shadow)
Tank 3 (Shadow)

I integrated GLFW with reasonable success today. The library installed fine, but the game occasionally crashes when switching to full screen mode or windowed mode. I'm hoping that this will not become a serious issue because the shift key works great! =) I also tinkered with the resources tonight. The sharp edges of the resource deposits were distracting, so I blurred them. I also reduced the opacity of the resource deposit as a player mines resources from it. The screenshot below depicts three deposits in varying states of excavation. The deposit on the top is nearly depleted whereas the deposit on the bottom is still fresh. The coloration appears equally well on any terrain, so it's quite possible to create underwater resource deposits.

Resource deposits

Tonight, I discovered a fabulous alternative to GLUT called GLFW. GLFW provides the same features as GLUT: window initialization, keyboard input, mouse input, buffer swapping, etc. It also provides a function for loading a .TGA picture file and saving it in memory as a texture. The GLFW API is simple, elegant, and best of all, it allows you to detect the shift key!!! This has always been a tremendous limitation of GLUT. When targetting multiple units or construction sites, you expect the mouse pointer to change when you press the shift key.

Today, I spent some time polishing the user-interface. I moved the scroll bars inside the text boxes and replaced one of the fonts. I also added a splash of color to each menu. Since I'm drawing all of the controls as textures, I want to glue all of the menus to a revolving menu cube. More on this later.

I also developed two convenient features for the game host. First, the game periodically inspects the time and size of the selected map and world. If the time or size changes, the game automatically reloads the files. It also transmits the files to the other computers. Second, the host can restart a game by pressing ALT+BACKSPACE. If the host has modified the selected map or world, the game automatically loads the new files, transmits them to the other players, and starts the game as soon as the other players have acknowledged the files.

The way cool setup game menu!

I'm continuing to make fabulous progress on Machinations. Today's screenshot shows the new help system in all of it's glory. The help appears in a resizeable dialog box, so you can position the help anywhere you like on the screen. Best of all, the game reads the help from a data file, so you can make changes to the help in real-time and instantly see the results! I'm also posting an example of the new world and map file format. Enjoy! =)

Screenshot of the day!
World file
Map file

School ended this week so I will have ample time to work on Machinations in coming weeks. I'm making excellent progress with unit scipts (e.g. custom command classes). I currently have ten classes: division, construction, production, storage, extraction, collection, levitation, cloaking, detection, and weapon. Each class has a variety of parameters that allow you to fully customize the ability. For instance, the extraction script lets you define the resource extracted, the extraction rate, and the maintenance cost (if any).

Right now, I'm decomissioning my old file parser and replacing it with a superior object-oriented parser. I'm also improving the format and structure of the game's data files. I have replaced all of the unit type files with world files. World files contain unit types in addition to resource definitions and eventually missile types. Missile types will allow you to customize the appearance and sound of a laser or cannonball. I've also developed an in-game help system that displays information about all of the shell commands, including a description of each parameter.

Tom Pittlik (www.disfinite.com) is currently designing some preliminary models for the game. Here is an example of his work. Hopefully, I will have some screenshots showing the units inside the game shortly. =)

View models

I started a list of jobs here.

Machinations is basically on hold until summer break (late May). I simply don't have the time or motivation to work on it right now. =(

It's been a while since my last post. College occupies more and more of my time. Also, I'm in the process of renovating my old Spanish Conjugation Tutor. Hopefully, I can make up for lost time during Spring Break. Stay tuned for new exciting developments!

Aww...another weekend comes to an end. How sad =( I wanted to post one more screenshot before next weekend. This screenshot shows the early stages of resource collection.

View screenshot

Today, I put translucent white disks around the toruses (tori?) to indicate the area within which they can detect cloaked units. Although this may seem like a simple addition, it involved extensive changes to the main drawing function. For anyone who is thinking about designing their own 3D engine, use blending sparingly. Believe me, blending will drive you crazy. Ordinarily, the order in which you draw each polygon doesn't matter because OpenGL automatically clips invisible polygons. But, when you introduce one or more transparent polygons, the order becomes extremely important.

View screenshot

Lots of announcements to make... Yesterday, Jonas Jermann and Bernhard Kaindl helped me port the game to Debian and SuSE Linux. Thanks guys! Machinations also compiles on Dev-cpp (I tried it myself earlier this week). Today, I implemented two new units: the torus and the rounded cube. The torus detects cloaked units within a small radius. The rounded cube stores 1000 resources. Previously, the cube stored resources, but I decided to create a new building for greater diversity. Both units are fully functional, but I want to add a couple more frills. =)

Jonas commented that the terrain was too monotonous, so I experimented with neutral sprites. I downloaded some nice images from the Internet and positioned them on a screenshot with the help of Paintshop Pro. The results speak for themselves. Unfortunately, view rotation and tilting will complicate the implementation tremendously. In the end, I will probably have to design a simple 3D model for each neutral object. If you know of a better alternative, please let me know!

View screenshot

HALLELUJAH!! This weekend I squashed the nefarious freeze bug! Some of you may recall that I spent over a week in July trying to hunt down a bug that caused my computer to freeze at high frame rates. After commenting out 99% of my code, I concluded that the video driver was responsible. Last night, I downloaded the latest ATI Radeon driver and fiddled with the settings. At last, I discovered that "Wait for Vertical Sync" resolves the problem. With this option enabled, the frame rate never rises above 60 (my monitor's frequency) and the display no longer flickers. I also resolved several other problems. I discovered a serious network protocol mistake, and I added a routine that automatically detects the number of sound sources your system supports.

With the help of Jonas Jermann, I ported Machinations to Linux again. As of right now, the code is fully compatible with Borland, Visual C++, Linux. Hopefully, I can release a compiled Linux binary for all of you Linux users.

Nothing new to report today; however, I posted a couple of new screenshots. The first shows my base after three minutes. Notice how the spheres and tetrahedron cluster around each cube? This occurs naturally with steering behavior. If the cube produces enough units, they will eventually form two or three concentric circles around the cube. The second screenshot shows an intense battle. The tetrahedra now fire plasma balls that inflict four times as much damage as a laser.

View screenshot 1
View screenshot 2

College started on Tuesday, so I won't have as much time to work on Machinations in coming weeks. Today, I experimented with fog of war (the mysterious phenomenon common to almost every RTS game). First, I assigned each tile a visibility flag. True indicated that the tile was visible. False indicated that the tile was hidden. As I anticipated, this approach produced a jagged, blockish effect near the the edges (see screenshot below). So, I decided to replace the visibility flag with a floating-point visibility factor. A value of one indicated that the tile was fully visibile. A value of zero indicated that it was fully hidden. A value in between meant that it was partially obscured. I generated visibility factors using this equation:

visibility = MIN( MAX( (8-distance)/2, 0), 1)

The results speak for themselves. Hopefully, I can find a way to implement floating-point visibility factors without lowering performance too much.

View screenshot

Click here to download. As always, mach34_game_only.zip contains only the files need to run the game; whereas, mach34.zip also contains the source code. Extract the files to any directory and run game1.exe. This version contains all of the features added this year:

• Synchronized timing changes
• Reconnect
• Synchronized terrain
• Unit production
• Game speed adjustment
• Shared resources
• Cloaked tetrahedra

I also updated the manual. You can view it here.

Today, I implemented cloaking as a precursor to unit visibility and fog of war. Since cloaking interferes with the existing custom commands, I created a new unit... the TETRAHEDRON! You can order the tetrahedron to cloak or decloak by clicking the appropriate button in the command panel. Once cloaked, the tetrahedron becomes invisible to enemy players and cannot sustain damage. Cloaking last indefinately, so long as you maintain a steady flow of resources. If you run out, the tetrahedron becomes temporarily visible again. The first screenshot shows two tetrahedra--one cloaked and one decloaked. Cloaked units are slightly transparent and lack shadows.

College starts in a couple of days, so

View screenshot 1
View screenshot 2

Thanks to those of you who sent me feedback. I really appreciate it. =) I devoted another twelve hours to Machinations and accomplished a tremendous amount. I bring you... drumrole... Resource sharing!! I spent a long time pondering different approaches. In the end, I decided that allies should continue to manage their own resources while sending "foreign aid" to allies in need. For example, suppose that Ally A is consuming 25 metal/second and only producing 15 metal/second. When Ally A runs out of metal, Ally B will automatically give him 10 metal/second. On the flip side, suppose that a player produces so much metal that he exceeds his metal storage capacity. To eliminate waste, the game will automatically send the surplus metal metal to the player's allies. For instance, if Ally A produces 50 metal/second but only consumes 10 metal/second, he will supply his allies with 40 metal/second.

Some players may not like resource sharing, so I added a number of switches to the alliance menu. You can choose whether to share your resources with each player in the game (allies and enemies alike). I also added a switch for shared vision and shared control. I haven't implemented shared vision yet. Shared control allows another player (friend or foe) to control your units.

The first screenshot depicts the resource bar when one or more allies share their resources with you. NOTE: The blue number indicates the rate at which you are receiving foriegn aid (positive) or giving foreign aid (negative) The second screenshot shows the new and improved alliance menu. More to come soon!

View screenshot 1
View screenshot 2

Excellent news! I just added a feature that lets you increase or reduce the game speed by a factor of up to 10. You can either press -/= (same as Starcraft) or enter a new game speed in the timing menu. If you increase the game speed above 3x, you will need to reduce the game interval. The game interval controls the rate at which the engine updates each unit's acceleration.

Today's screenshot shows a factory and some cones concurrently producing a unit. Enjoy!

View screenshot

I haven't had much time to work on Machinations lately due to matters of the heart. Hopefully, I can put the finishing touches on Machinations 0.34 and release it before I start back to college next week. Machinations 0.34 will include synchronized terrain and unit production. Today's screenshot shows an explosion with alpha blending and anti-aliasing. If you're impressed by Machinations, please let me know. I appreciate hearing from you.

View screenshot

Today, I put the finishing touches on unit production. Enjoy the screenshot! =)

View screenshot

I'm continuing with unit production. I replaced the cube with a square frame (see below) and designed a simple construction animation for it. Eventually, the cube will spawn new units in its interior and build them with four red repair beams. When finished, the units will slide out one side, making room for the next unit.

View screenshot

BOO YAH!! Machinations now averages 50 pages views each day! Unfortunately, I can't monitor the downloads since our counter is broken. Today, I implemented the first half of unit production. After careful consideration, I decided on a variation of Total Annihiliation's build menu. When the user left clicks a build option, the game adds the unit to the build queue. When the user right clicks a build option, the game removes the unit from the build queue. This part is the same. When the user clicks both buttons on a build option, however, the factory produces the same unit over and over again indefinately. The build option becomes red and a number in parenthesis appears to indicate this alternate mode of operation. The screenshot below shows the result when selecting one factory that is continuously producing cones and another factory that is producing two spheres.

View screenshot

I achieved the impossible again. This time, I synchronized the terrain by changing less than 20 lines of code. "How did I accomplish this feat?" you ask. Random seed numbers! The game host transmits a series of terrain parameters (such as percent water and roughness) and a random seed to each client in the map file. Each peer generates an identical map from this seed. Simple, concise, and elegant! This method will also permit us to save terrain data in under 100 bytes. Our future map editor will prompt the user for a series of terrain parameters. Then, the user will repeatedly click "Generate Terrain" until he sees a map that suits his fancy. Once done, the map editor only needs to save the terrain parameters and the random seed.

I have achieved the impossible. Oh yes, PERFECT SYNCHRONIZATION!! I designed a routine to flood the network with 100 random commands every second. It worked great! Then, I tested my new algorithm for adjusting timing parameters during gameplay: latency, network interval, game interval, or a combination of the three. I tried at least 30 successive timing changes from one extreme to the other. Oh my gosh! Not a single discrepancy! I was so happy! So, I'm throwing a sync party at my house. Everyone is invited...friends and fans alike. After the festivities get underway, we will all toast our glasses of champagne simultaneously to commemorate this achievement. =P

I have a quick announcement to make. I implemented a new feature that lets you reconnect from a new IP address and/or port. This feature is especially useful for those of you with dial-up connections. If you lose your connection in the middle of the game, you leave the game running, reconnect to your ISP, and select "Reconnect" from the game menu. This will automatically send a message to each peer, informing them that your address has changed. Best of all, no data loss will occur thanks to my super cool packet acknowledgment system. More to come soon!

At last, I bring you the official release of Machinations 0.33! Click here to download. As always, mach33_game_only.zip contains only the files need to run the game; whereas, mach33.zip also contains the source code. Extract the files to any directory and run game1.exe. This version contains all of the features added since August:

• Blueprints
• Terrain
• Shadows
• View rotation, zooming, and tilting (HOME, END, PAGE UP, PAGE DOWN, SHIFT+HOME, SHIFT+END)
• Unit construction
• and much more!

You should find the game user-friendly. Follow these instructions to setup a single-player game:

1. Select "Single Player" from the Main Menu
2. Select "Choose Map" from the Setup Menu and accept the default parameters
3. Click "Start Game"
4. Press ESC to access the game menu. From here, you can exit to the Setup Menu.

Please be aware that Machinations 0.33 is not playable yet. There is no objective nor winning condition. To setup a network game, you will need to elect one player to be the game host. The game host will select "Host Game" from the Main Menu and share his IP address with the other player. The other player will select "Connect" and enter the IP address on the subsequent screen. The host will need to load the client in the Player 1 slot (it defaults to Computer). The host should also set the latency in the Set Timing menu to a reasonable value (say, 400ms). Once ready, the host clicks Start Game, and the game commences. The example map only supports two players, but I can post a map with four players if anyone is interested.

I have been lax in thoroughly testing the game lately, so doubtlessly, a few bugs have slipped through my fingers. If the game crashes or behaves erratically, please send me a description of the problem with the output.txt file attached here. Thanks! I welcome suggestions and compliments also. =)

It was one year ago today that I posted the first announcement on this website. Look how much we've accomplished since then! Happy New Year's!

I'm so excited! Machinations is nearly playable! The only things left, now, are unit production, resource collection, terrain transmission (to other players), limited mobility (on different types of terrain), and possibly fog of war. With continued success, I can implement all of these features by the end of January (when I start back to school). So!! There's a light at the end of the tunnel! My dream is finally coming true! =)

Here is another screenshot showing some KILLER terrain! Just imagine spawning a player in each corner and letting them fight for control of the seas.

View screenshot

My thanks to Abe and Sebastian for trying a network game. From what I hear, the game performed admirably. =) Machinations 0.33 is currently bug free! I'm in the process of implementing a couple of new features, so I've decided to postpone the official release of 0.33 a little while longer. The first feature allows you to tilt the map using SHIFT+HOME and SHIFT+END. At one extreme, you see the units from above (see screenshot below). At the other extreme, you see the units from the side. HOME and END still spin the map about the z-axis while PAGE UP and PAGE DOWN scale the map. Second, I'm pleased to bring you the early stages of unit construction. The cone now has the ability to build cubes and cylinders. After a great deal of thought, I decided to treat unit construction as a custom command. Consequently, when you select a cone, four custom commands now appear: Repair, Disassemble, Build Cube, and Build Cylinder (see screenshot below). It works great! Best of all, the build orders are permanent. So, if your construction unit dies, you can assign another unit to resume construction with the click of a button!

View screenshot

Today, I put the finishing touches on Machinations 0.33. I added another custom command for the cube. This command controls the elevation of the cube. When you click Lift Off, the cube slowly ascends and gains mobility when it reaches its maximum altitude. When you click Land, the cube loses mobility and slowly descends. Confused? Just think of Terran buildings in Starcraft. I also spent a long time reorganizing the unit states and explosions. The game works like a charm on my computer, but I haven't tried a network game in a long time. True to my word, I'm releasing Machinations 0.33 on my website for testing. I will release it on SourceForge shortly.

I tinkered with shadows for a long time today. The screenshot below is the product of 10+ hours of careful analysis and experimentation. It's not perfect, but it will have to do... Notice that the second cube from the top actually has two shadows. The shadow on top bobs up an down on the water's surface. The shadow below lies flat on the ocean floor. The leftmost cube has two shadows also, but only one is visible. Overall, I'm very pleased with the results. The two cones on the left bring tears to my eyes! =P

Today, I also implemented a sound manager (100 lines, no less!) and improved my unit visibility algorithm. I plan to start the build menu shortly (how long have I been saying that?!), but before I do, I will probably release Machinations 0.33. This release will contain all of the features added since August -- namely, blueprints, zooming/rotating the view, and terrain. BTW, I would really appreciate some feedback... The more e-mails I receive, the sooner I will release Machinations 0.33. =)

View screenshot

I just finished a long line of changes to the terrain. First, I implemented preliminary support for different unit domains (e.g. land, sea, and air). The unit types file now lets you specify a unit's motion and elevation on different terrains. Currently, there are four types of motion:

• contours - a unit is always glued to the ground (even underwater)
• float - a unit hovers above water
• bob - a unit bobs up and down in water
• constant - a unit always levitates at a constant altitude on any terrain

Second, I improved the terrain's noise algorithm, making land masses larger and oceans deeper. Once again, the results exeeded my expectations (see first screenshot). You can clearly make out continents, oceans, lakes, islands, and even a penninsula. The distribution of sand (yellow), grass (green), and rock (brown) looks great, too! Last, I puttered with shadows since it was hard to tell that levitating units were, inded, levitating unless you rotated the view. The effect was quite realistic (see second screenshot). The shadows definately add a greater sense of dimension.

View screenshot 1
View screenshot 2

HAPPY HOLIDAYS!

I worked on sprites a long time tonight. Originally, I was drawing sprites (such as explosions) perpendicular to the z-axis...which worked fine until I allowed the player to rotate the view. This caused the sprites to virtually disappear when viewed edge-on. So, in the end, I rotated the sprites together with the view so that the sprites always face the viewer. Remarkably, it looks pretty good! Save for the lack of detail, the explosions look almost 3D. (As an aside, Sebastian tells me that old 3D games used to do the same thing). The first screenshot shows a battle from a 90 degree angle. The second screenshot shows a partially underwater explosion. I'm not sure how realistic it looks, but it's certainly an interesting effect.

View screenshot 1
View screenshot 2

My quest for the ideal memory manager continues. Today, I discovered a way to trap all memory operations using a global function and a global function. I also discovered a better way to record the line and file using a couple of macros:

#define mwNew new(__FILE__,__LINE__)
#define mwDelete (mwFile=__FILE__,mwLine=__LINE__),delete
extern void *operator new(size_t size); //System calls
extern void *operator new(size_t size, const char *file, int line); //User calls
extern void operator delete(void *ptr);


Trapping memory leaks presented a challenge since memory allocated by static objects isn't deallocated until after the program ends. In the end, I had to print out a tentative memory leak report when the program ended, and update it with each subsequent call to

. So far, the memory manager works great! Yesterday, it trapped a serious memory leak in message.h, which had hitherto gone unnoticed. I released all of the source code on CVS. The project now contains three new modules: terrain.cpp, noise.cpp, and memwatch.cpp. Please note that the first two modules are located in the terrain subdirectory.

BOO YAH! With the help of my custom memory manager, I managed to track down the bug responsible for many headaches and sleepless nights. The error was an access violation that only surfaced when I specified certain dimensions for the map. As usual, the mistake was blatantly obvious and I fixed it in a matter of minutes. Hopefully, my memory manager will alleviate future memory nightmares. The memory manager maintains a table of all dynamic memory blocks. It can detect invalid delete operations, access violations, and memory leaks.

I updated the Features section today. I will update CVS as soon I finish testing and debugging this line of changes. Expect the next file release at the end of January. Machinations 0.33 will tentatively contain terrain and a build menu.

No news today, but I posted another screenshot for your viewing pleasure. This screenshot shows the water partially obscuring the units.

View screenshot

Hello, everyone! I've finally returned from the void, so to speak. Fall semester ended this week, so I can now focus my full attention on Machinations till mid-January. I tinkered with the terrain for a few hours yesterday. As I was watching the grass and rocks undulate near the water's edge, it suddenly occurred to me that I should draw the land and water separately. The land should descend beneath the undulating water texture and gradually disappear. The results were impressive. You can actually see waves washing up on the beach and slowly receding. The screenshot below illustrates how I layered the textures. Enjoy!

View screenshot

I haven't had time to work on Machinations in weeks. I'm beginning to question the prudence of taking seven classes. I have homework coming out of my ears! I'm also a lil distracted by my signicant other. =) Hopefully, I'll have some news to post here shortly!

This is going to be another one of those announcements that starts with OMG...

OMG! I prepared a terrain texture for the minimap and it looks fabulous. The screenshot below shows the minimap dramatically enlarged for effect. The balance between land and water is brilliant. I couldn't design a better map by hand! =P Also, notice that the terrain wraps around on all four sides. This will allow us to implement a Civ2 style map someday. Once the minimap was finished, I turned my attention to unit elevation and orientation. With a little interpolation, I managed to calculate the elevation and normal vector at any point on the map. The result were, once again, incredible. Perhaps most incredible was the motion of units in water. The units bobbed up and down in a sinuisoidal motion gently tilting from one side to the other.

View screenshot

I accomplished a lot this weekend. First and foremost, check out our new webpage!! Many thanks to Sebastian for his help and suggestions. The hardest part was organizing all of the thumbnails and screenshots and cross-referencing them with the announcments. The rest was mainly copying and pasting from the former webpage. Hope you like it! Send your feedback here. =) Second, I implemented two way cool new features. The user now has the option of zooming the view with PAGE UP and PAGE DOWN and rotating the view with HOME and END. The view pivots at the screen center allowing you to "survey" your army from 360°! The minimap also rotates, shrinking or growing for the best fit. Last, I bring you... Terrain!! (see screenshots below) I spent several hours polishing the terrain package and adapting it to the new isometric projection. The terrain now zooms and rotates with the rest of the map. OMG! Rotating the terrain looks SO COOL! It's like circling around the map in a plane! The mountain ranges, especially, look so real!

Next, I will display the terrain in the minimap and draw the units at the correct elevation.

View screenshot 1
View screenshot 2
View screenshot 3

College. That pretty much sums up my absence of late. Between classes, homework, and my significant other =), I haven't had an ounce of time to work on Machinations since August. Nonetheless, I haven't forgotten about it! Stay tuned for exciting developments in weeks to come!

College started this week and my hard-drive crashed on Monday, so development has slowed somewhat. This week, I implemented the early stages of building construction. Building construction is similar to TA, except that your queued building orders are always visible. What's more, your building orders exist as autonomous objects, so you can select them or order other construction units to begin building them. A building order gains "substance" when a construction unit approaches and begins repairing it. (I use the same command for repair and build for the sake of simplicity.) A nascent building begins as a thin wafer on the ground that gradually becomes taller until it reaches its full height. During its incubation period, a building has no functionality, although you can queue orders to it. When a building dies, the engine replaces it with a building order, allowing you to quickly reconstruct it.

I also implemented a few new commands. The squiggle (Delete) lets you delete build orders. The skull (Self Destruct) orders a unit to self destruct. (...Maybe you better think twice about letting an ally control your units :-) ) The dynamite (Disassemble) is the opposite of Repair. It lets you scrap old units and recover resources from them (think TA). Enjoy the screenshot!!

View screenshot

It is with great pleasure that I release the latest version of Machinations. As always, machinations32_game_only.zip contains only the files need to run the game; whereas, machinations32.zip also contains the source code. Extract the files to any directory and run game1.exe. This release contains all of the features contained in these announcements:

• Text messaging system
• Groups
• Alliance and Game Options menu
• Repair, divide, and an on/off switch for the cylinder (you'll see what I mean)
• Hidden players
• Resources
• Sound
• Unit health bars

In addition, the file release contains two bonus applications: my font conversion utility and Koom's texture manager. The texture manager probably won't be of much value to you, but you can play with the font conversion utility. =) Without going into too much detail, select three fonts from the left and click 'Convert' after each selection. The program will complain if there isn't enough space left on the canvas for all of the characters. You can select a subset of characters in the bottom-left corner (e.g. 32,65-90). The default fonts are:

0. Arial 10 (characters 32-255)
1. Newell 18 (characters 32-126)
2. Logan 36 (characters 32,65-90)

You should attempt to match the font sizes and character subsets. As usual, I have done my best to test the game thoroughly, but undoubtedly some bugs have gone unnoticed. Send gripes and complaints here. I appreciate compliments also. =)

• The computer occassionally crashes when switching to full-screen mode. (It's GLUT's fault! Honest!)
• The game outputs a list of "error creating sound source" messages during large battles. (OpenAL only supports 32 sound sources on some systems, tsk tsk)

Lots of announcements to make. First, I improved the in-game text messaging system. Players now have the option of sending messages to allies, enemies, or a single player. Pressing <ENTER> prompts you for a global message (as before). Pressing the period or comma keys prompts you for a message to your allies or enemies. Pressing the apostrophe key prompts you for the name of the message's recipient. Once entered, the game prompts you for your message.

Second, I implemented groups! It was much easier than expected. The system behaves the same as Starcraft except for the key combinations. The player presses ALT+number to assign the selection to a group and the number alone to select the group. The player can also selected multiple groups by holding down shift (e.g. 1 <SHIFT>+2 <SHIFT>+3). In addition, the player can assign enemy units to groups, making it easier to target commands. For instance, if group one contains your army and group two contains your enemy's army, they you can type '1a2'. In fact, the possibilities are unlimited! You could type '1 <SHIFT>+2 a 3 r <SHIFT>+1 <SHIFT>+2'. This tells groups one and two to attack group three, then repair themselves. Finally (yes, there's more!!), I added Disband to the command panel. Disband removes the selected units from the groups to which they belong. NOTE: Groups exist in the user-interface, meaning other players will never see your groups and vice versa.

Third, I implemented the in-game options menu! The menu (accessed by pressing <ESCAPE> and clicking Options) permits you to change the resolution, switch to full screen mode, and adjust the pan rate. Your settings will take effect immediately and the game will automatically rearrange the windows to utilitize the new resolution. You may also set the resolution/full-screen-mode in the shell or game initialization file. That's all for now. I hope you enjoy the screenshots! =)

View screenshot 1
View screenshot 2

Today, I designed a divide command, inspired by the movie Evolution. Spheres have the uncanny ability to undergo mitosis. =) The unit splits in half producing two clones of the original unit. By repeatedly clicking on Divide, you can amass a huge army after five or six generations (see screen shots below). Unlike the movie Evolution, however, the spheres need an abundance of nutrients (resources) to divide, effectively limiting their reproduction rate.

I chose to implement this ability for two reasons. First, I was bored. =P Second, I wanted to see if the existing code could support such an exotic action. =) To my relief, the new code went in smoothly and the synchronization is still rock solid. YIPPEE! Now, I'm going to turn my attention to unit construction. I have some ideas...but I don't want to spoil the surprise just yet. =) You'll just have to wait and see! By the way, I added support for hidden players. Hidden players own all of the resources and critters on the map (think Starcraft). They are not visible on the Game Setup/Alliance menus, and they are always neutral.

View screenshot 1
View screenshot 2

As the month drags on, my motivation is ebbing away. Nonetheless, I'm continuing to make progress on Machinations. This week, I implemented player resources in the spirit of Total Annihilation. The close resemblance is no accident. =P As they say, "immitation is the highest form of flattery." Naturally, the resources are fully customizeable. The engine supports up to eight types of resources with integer identifiers ranging from 0 to 7. I achieved the following screenshot by adding the following lines to the map file.

RESOURCE 0 Beans
RESOURCE 1 Tomatoes

View screenshot

In case you're wondering, beans and tomatoes have no bearing on our game. This was an inside joke. =) (Koom should understand the humor =) ) While I was fiddling with the formatting, I discovered a brilliant way to draw boldface text by shifting the characters one pixel to the right. I don't know why I didn't think of it earlier, but the effect is very impressive. I also spent some time pondering the unfortunate situation where a player runs out of resources. In Starcraft, this never becomes an issue because the game deducts the cost right away. I pondered a variety of approaches, ranging from deactivating a few units to a consumption multiplier. Finally, I decided on... Yep! You guessed it. The same approach that Total Annihilation takes. When a player runs out of resources, a three second "black-out" occurs during which time most units temporarily stop operating. Then, I got to thinking, "it sure would suck to lose power to your defense cannons and radar towers during an invasion." So, I decided to limit the "black-out" to expansion and construction operations. Radar towers, defense cannons, cloaking devices, etc. will continue to receive a constant supply of resources except in dire shortages.

Oh yeah...

I haven't forgotten about pathfinding. =) I've devised a ten-step solution (approx.) to the age-old problem. But, I simply don't have the motivation to implement it just now.

Terrific news! I successfully implemented sound today using OpenAL! Once I managed to compile the OpenAL utility library (ALUT) with Borland and download the latest OpenAL libraries, the rest was quick and painless. I integrated OpenAL into the game in less than an hour. Unfortunately, OpenAL only supports 32 sound sources (on some systems), however I can probably find a way around this limitation. The game has two sounds right now: a laser when a unit fires and an explosion when a unit dies. Overall, I'm satisfied with OpenAL. It's extremely easy to use, and the stereo volume attenuation sounds fantastic!

More good news! With the help of Brian Rose, Machinations now compiles on Linux!! (V 2.4.18) I placed a Linux makefile on CVS in the linux subdirectory. Since I have received so many e-mails from people trying to compile the game, I will probably write some detailed directions for Borland, Visual C++, and Linux. In the meantime, here is some important information:

• I strongly encourage you to download the latest source code from CVS. We have made countless changes since the file release last month.
• The root CVS directory contains all of the source files belonging to the main project. The data, maps, and units directories contain data files used by the game. The borland and linux directories contain OS-specific project files. The remaining directories contain various subprojects.
• Machinations now links to three dynamic link libraries, opengl32.dll, glut32.dll, and openal32.dll. You will probably need to include opengl32.lib, glut32.lib, openal32.lib, and alut.lib in your project file unless your compiler automatically includes them for you. You can obtain these from a variety of sites on the internet.
• types.h contains a complete list of compiler switches. You will always want to define DEBUG and LOG. You will also need to define LINUX, VISUALC, or BORLAND depending on your OS/compiler.
• If you run into problems, drop me a line! I'll be glad to help.

One last order of business before I call it quits for the night. I drew a rough estimate of our progress on different aspects of the game. As you can see, we have a long ways to go yet!

View image

This week, I implemented the repair command. Certain units have the ability to restore hitpoints using an eerie red beam (see top image). Ok, ok, so it looks really lame, but it was the best I could do in 20 minutes. :-P I also made the explosions appear more realistic by drawing them at the logical point of impact. So, for instance, if a laser beams strikes a unit from behind, the explosion appears behind the unit (see middle image). Finally, I included the screen shot on the bottom just for fun. By some freak accident, a band of unit encounters a wrinkle in the space-time continuum and breaches the third dimension.

View screenshot 1
View screenshot 2
View screenshot 3

I am continuing to polish Machinations 0.31. I finally implemented the texture manager, and it works great! Each image has texture pack that defines the name, location, and dimensions of each texture within the image. The texture pack has the same name as a the graphic but with a .TPK extension. Koom created a very nice Delphi application for creating texture packs. Thanks, Koom! Once you create a texture pack for each image, drawing a texture couldn't be easier. Simply retrieve a reference to the desired texture with getTexture, then, draw the texture at the desired location with drawTexture. Loading animations couldn't be easier, either! Simply give an animation's frames the same prefix followed the frame number (e.g. Pointer0, Pointer1, etc.) The animation class automatically detects the number of frames and loads them sequentially.

I also optimized the target acquisition system with a unit hash, implemented the alliance menu, and displayed health bars above selected units. Finally, last but not least, a new screen shot! Here the blue and green armies are taking down some red cubes. Enjoy!

View screenshot

Fantastic news! The Machinations code now compiles and runs under Visual C++. I spent the whole morning at my school's computer lab sorting through well over two hundred gripes and complaints. Not fun. Visual C++ nuances accounted for most of the errors, although I did catch a few of my own mistakes. You can download the latest source code from CVS. In other news, I spent countless hours trying to determine what causes the computer to freeze. After commenting out 99% of my program to no effect, I eventually concluded that the video driver was responsible. Since the problem seems to occur when the application is running at peak performance, I clamped the frame rate at 100 and said 'to hell with it'. :-)

Ladies and Gentlemen, the long-awaited day has finally arrived. With no further adeu, You can download it here. As always, machinations_game_only.zip contains just the files needed to run the game; whereas, machinations.zip contains the source code as well. Extract the files to any directory and copy glut32.dll to the windows/system directory (if you don't already have it.) Run game1.exe. I have done my best to thoroughly test the application. However, despite my efforts, I am sure a few bugs have slipped through my fingers. I would appreciate it if you would report these to me, along with the output.txt file that the game generates. We have done our best to make the source code compile on Visual C++ and Linux; however, it may need some additional tweaks. See types.h for a list of compiler switches. You will also need to add the GLUT library to the project and place the include files in the proper directory. Again, if you run into problems, send me an e-mail.

My goodness! Three days since my last post already?! Where has all the time gone? *sighs* Anyway, I'm continuing to make excellent progress on Machinations. Today, I overhauled the protocol for sending unit commands across the network. Before, I was sending one message per source per target. So, for instance, if you highlighted 30 units, clicked 'Attack', and dragged a box around 30 enemy units, the engine would generate 900 messages! When you consider that each message consists of 12 bytes, this yields 10.8 KB of painfully redundant data. So, I said, "Nuts to this! Time for a new approach." The new approach allows a command message to have multiple sources and multiple targets. This protocol replaces a O(n*m) size complexity with O(n+m), reducing bandwidth by up to 98%.

I also developed a tool for ensuring perfect synchronization between peers. At regular intervals, the host broadcasts a synchronization query across the network. The clients respond by sending the position and health of each unit back to the host. The host compares its data with the peers' data and writes an entry in the output file if it finds any discrepancies. The tool proved invaluable for hunting down two pesky sychronization bugs. In the first case, I wasn't executing commands at the same time. In the second case, I was not resetting a variable to the same value. Long story :-) I'll spare you the gory details. But! After hours and hours of hard work and perseverance, I achieved my ultimate goal. Perfect synchronization!

I'm making extraordinary progress on Machinations. This week, I implemented and tested the Patrol command. A player can add any number of waypoints to a patrol route by pressing 'P', left-clicking the first waypoint, holding down SHIFT, and left-clicking additional waypoints. Patrol is essentially a move command, except that the unit cycles through the waypoints over and over again. For this purpose, I added a repeat flag to the command table, which determines whether the engine should discard the command or set it aside for subsequent executions.

I also made the user-interface more versatile. Starcraft lets you select all units of the same type within the view by holding down CTRL. Total Annihilation lets you select all units of the same type in the whole world by pressing CTRL+Z. So, I thought, "why not combine the best of both worlds?" The result: Two unique key combinations. Holding down CTRL and clicking imitates Starcraft. Holding down ALT and clicking imitates Total Annihilation. The same applies for targeting unit. Finally, I unveil our new, fully-functional control panel! Can you guess what all the icons mean? :-P

View screenshot
Top row: Move, Attack, Follow, Patrol, Hold Position
Bottom row: Stop, Evade, Defend, Pursue, Hold Fire

I have a few announcements to make. John Carter has joined us once again and volunteered to continue my work with terrain generation. Eventually, he will organize the code into a package or class that interfaces with the engine. The package will contain public functions, such as generateTerrain, drawTerrain, and getTileInfo. We have also given some thought to the fog of war. The engine will provide the terrain package with one or more arrays containing the visibility status of each tile (i.e. invisible, explored, or visible). The drawTerrain function will then fade invisible tiles to black and reduce the intensity of explored tile (creative, huh?). In other news, I implemented the unit command system that I mentioned last week. The system accomodates the following features:

• Four modes of aggression: Evade, Defend, Pursue, and Hold Fire
• Unit spells/affects such as freeze, invincibility, and blindness
• Ranged bombarment (think of the Guardian in Total Annihilation)
• Nearly any unit action including build, repair, and demolish
• Automatic target acquisition

Now, I've turned my attention to other subprojects. I spent some time researching OpenAL on Sunday. It shows great promise. In addition to being platform independent, it supports volume attenuation, stereo sound, the doppler effect, and sound mixing. OpenAL is the perfect companion to OpenGL, as it uses the same coventions and coordinate system. The OpenAL utility library appears to support .WAV and .MP3 files, but I don't know for sure. I also spent some time revisiting steering behavior. (For more information, visit http://www.red3d.com/cwr/steer/.) I successfully implemented obstacle avoidance behavior but haven't been able to combine it with other behaviors. Consequently, a unit expertly avoids obstacles, but wanders around aimlessly.

BTW, this page may get a facelift soon. My friend, Sebastian, has volunteered to organize this mess into a professional-looking website. Let's hear it for Sebastian! *cheers*

Today, I present to you a sneak peek of my target acquisition system. Click here to see it. Look complicated? It is. And this is only the first page! The flow chart spans five pages.

My imagination continues to soar with no end in sight. Today, I conceived an interesting idea for rendering units on different types of terrain. Wouldn't it look cool if lush vegetation obscured the bottom of a unit or a pond nearly concealed a unit? To illustate my point, I've included another screen shot. I used Paintbrush to carve away the bottom of a tank and paste it in different locations. (Yes, yes, that's cheating, I know!) The effect lends a greater sense of realism to the scene. The viewer feels that the tanks are truly united with the ground, and not just floating over it. The realization of this effect presents a formidable challenge. Ideally, I can partially lower a unit beneath the terrain's surface, and OpenGL depth sorting will do the rest!

View screenshot

Well, I've done it again. My frivolous idea has grown into an entire algorithm for terrain generation. Yesterday, I expressed a desire to introduce unique texture combinations independent of elevation. Today, I achieved just that. I generated a contour map for each texture representing the texture's concentration at each vertex. This yielded a blurry muddle, so I "purified" the strongest texture in the region and eliminated weaker textures. Once again, the results exceeded my expectations. I produced a beautiful collage with stunning transitions between each region. The only remaining hurdle was elevation. In the end, I decided to base the elevation (and consequently, the placement of water) on the raw data from the first contour map. The image below depicts an outcropping of rock amid a patch of vegetation. This effect was not possible with the former algorithm.

View screenshot

OMG! I'm brilliant! I tested my theory this afternoon and the results exceeded my wildest expectations! I used a simple noise algorithm (courtesy John Carter) to generate a contour map. The contour map controls the elevation and texture "mix" of each tile. I've included another terrain sample for your viewing pleasure. This picture consists of four distinct textures with 30 horizontal tiles and 20 vertical tiles. In the future, I plan to animate the water and introduce unique texture combinations. Currently, the terrain varies with the elevation alone making the scene appear artificial and monotonous. I want to modify the noise algorithm so I can generate different terrain types at the same elevation. Anyway, that's all for now! If I've piqued your interest, let me know! I welcome your comments and suggestions. :-)

View screenshot

My goodness!! It's been one month since my last post already?! My, how time flies when you're having fun! I fear I will be lamenting the end of summer and the beginning of a new school year in my next post. I'm devoting more and more time to Machinations as the days rush past. Unfortunately, I don't have any new features to announce just yet. I do have a terrain sample for your viewing pleasure, however. I downloaded a dozen "seamless" textures from the Internet and faded from one to another. I'm experimenting with realistic transitions from one type of terrain to another. The results speak for themselves. :-) Just imagine one of those bad boys down below there rolling across the beach firing cannon balls! WAY COOL!

View screenshot

Hello! I just wanted to let my loyal fans know that Machinations hasn't died. I still intend to finish Machinations, although it may not have all the bells and whistles that I once envisioned. I finished the spring semester about three weeks ago. Since then, I've been taking a long, well-deserved break. Anyone heard of Nexus: The Kingdom of the Winds? Great game, but highly addictive. Don't register your character unless you have at least three weeks of spare time to play. =) Here is the website: http://www.nexustk.com. It's worth a look. Hopefully, I will have more news to post here shortly.

I decided to spend some time improving the user-interface. Koom remarked that there should be a friendlier interface for people who downloaded our game, so I moved all of junk on the control panel to separate menus (see below). Once the game starts, the user will press ENTER to send a text message and ESCAPE to view the game menu. I want to minimize the clutter while the game is running. By the way, I was just curious, does anyone ever read these announcements? If so, please take a moment to send me your feedback here. I would appreciate hearing from you :-)

View screenshot 1
View screenshot 2

With four people working on Machinations, development has picked up considerably. Our mailing list now averages four e-mails a day and we hold discussions on ICQ almost daily. At last, there is a glimmer of hope that we might actually finish this monstrosity someday. :-) Currently, I'm pursuing yet another approach to unit movement and collision avoidance, which shows great promise. This approach relies on three vectors: position, velocity, and acceleration. Given a constant acceleration and an initial position/velocity, one can quickly calculate the position and velocity at any point in time. The challenge is finding a good acceleration vector to realize different behaviors. For more information, visit http://www.red3d.com/cwr/steer/.

In other news, Petr has turned his attention to scripting. After a lengthy discussion, we decided to design our own scripter so that we can tailor it to suit our needs. The scripting language will support dynamic variables, inheritance, and a wide range of events. Our goal is to provide the end user with the tools to implement almost any custom command. Petr has drafted a proposal describing the interface between the engine and the scripts. He will begin implementing the scripter shortly.

Finally, here is a preview of our tank arsenal. Imagine a dozen of these bad boys rolling into your base. You best run for cover!!

View screenshot 1
View screenshot 2
Courtesy John Carter

A warm welcome to our newest developer, Petr Tuma, who has generously volunteered to port our source code to UNIX. Since most of the code is already platform-independent, Petr suggested GLUT for window creation and OpenGL initialization. GLUT is a platform-independent OpenGL extension which wraps (and usually simplifies) operating system calls. Despite the sacrifice in freedom, I hope GLUT will be a worthwhile addition to our project. Here is a preliminary screenshot of the game running under Linux:

View screenshot

I haven't had much time to work on Machinations recently since college has occupied much of my time. I'm continuing to explore alternative pathfinding and collision avoidance algorithms. So far, I've had reasonable success with collision avoidance, but I still have a long way to go. In other news, John Carter has returned and volunteered to work on terrain and unit models. So... Hopefully sometime soon I will replace that icky star field with some WAY COOL mountains and those icky 3D shapes with some BAD ASS tanks! :-) Well, I can always hope... Anyway, stay tuned for more exciting developments!

This week, I decided to revisit an earlier pathfinding algorithm I was developing. I forget why I abandoned the idea now, but it's worth pursuing further. Unlike the traditional A*, this algorithm uses a point-to-point approach. It generates a graph consisting of a minimal set of vertices and edges. Then, it uses A* (Djakstra's shortest distance formula plus a heuristic) to find a path from start to finish. The point-to-point A* algorithm (as I will refer to it henceforth) offers several significant advantages over the traditional A* algorithm. Here are a few:

• There is no limit to detail: obstacles can be as small and concentrated as you like
• Units are not restricted to movement in eight directions
• The graph is typically much smaller
• Edges can be precalculated and stored in the map file
• The same graph will work for any path

Unfortunately, the algorithm has a few drawbacks as well. It doesn't support movement costs or variable unit sizes. Hopefully, I can find a clever way to factor in movement costs without too much grief. Variable unit sizes presents a greater challenge which I'm still struggling with. I'm including another screenshot which shows another Borland GUI I put together. The dark gray rectangles are obstacles; the blue dots are vertices; the grey lines are edges; and the bold red line is shortest path.

View screenshot

Development has slowed considerably in recent weeks, but I assure you, it hasn't stopped. Sadly, the fun has ended (at least temporarily), and now the real grunt work begins. There's no two ways about it: unit pathfinding and collision avoidance can be a real bit** :-) I've pondered a variety of approaches (both discrete and continuous), but none satisfy my high standards. It appears I will need to make some sacrifices (starting with realistic turning radius) if I intend to make any headway. I'm currently pursuing a discrete hierarchical approach using the A* algorithm. Unlike other methods, the A* algorithm lends itself well to movement modifiers (i.e. terrain slope) and tile weights (i.e. terrain type and enemy proximity). I'm including a including a screenshot from a quick Borland GUI I wrote to test my algorithm.

View screenshot

Well, I just put in another ten hours on the game, and I feel like I accomplished very little. Maintaining this monstrosity is becoming a greater challenge than I imagined. Just maintaining the files on CVS and documenting my changes has become a chore in itself. I've added a few more features since the 6th, but certainly nothing as exciting as unit combat. :-) The game loads an initiation file on startup (game.ini) which contains three environment variables at the moment: fullscreen, quitmessage, and username. Also, I added a shell for administrating a game. The player types a front slash (/) followed by the shell command in the chat box. For instance, typing "/create 0 warrior 1000 1000" creates a warrior unit for player 0 at the location (1000,1000).

Machinations charges forward with new features added each day. This week, I developed a routine for loading unit types from a text file. The format closely resembles mob templates, for those of you familiar with MUDs. Once selected, the engine automatically transmits the unit type file to each client. This lets the game host modify the unit properties and see the results in seconds. 'Tis cool :-) I attached another screenshot for your viewing pleasure. Tonight, I was messing around with a friend and we discovered you can form loops by stringing units together and ordering the first unit to follow the last. Surprisingly, the units eventually form a perfect circle. I don't know that this has anything to do with developing an RTS game, but it's fun anyway.

View screenshot

I'm so excited! Today, I finished my unit combat and persuit algorithm and it far exceeds my expectations. The phasers and explosions look so cool! What's more, my sychronization algorithm works beautifully. The unit positions and properties are identical on each computer. I present to you another screenshot from the game. Here, I'm slaughtering the computer (green) with my lean and mean spheres and cones (blue). The computer isn't smart enough to fight back yet :-)

View screenshot

This week, I finally learned how to use the CVS (mostly by trial and error). It's confusing at first, but once mastered, it's an invaluable tool. I uploaded all of my source code to the CVS, and I've begun (reluctantly) documenting my changes. Configuration management is a pain. :-) In other news, I finally mastered file packages on Source Forge. ...Well sorta. You will notice that the first link (machinations - game only.zip) doesn't work properly. Hopefully, my friend will fix it shortly (Has anybody experiences a similar problem with file releases?). It's my pleasure to include the first screenshot from the game here:

View screenshot

In case you're wondering, the 3D shapes are units and that yellow triangle is the mouse pointer. As you can see, we didn't outdo ourselves on the graphics :-). Eventually, textured 3D models will replace the shapes and textured tiles will replace the starfield. I'm focusing on the unit commands and movement for the moment.

Maintained by Jon Sargeant and Tom Pittlik