So I have recently become interested in Real Time Strategy games, and seeing how there haven't been any major RTS's released I thought it might be interesting to design one.  Note that I am not actually thinking about coding one right now, just designing the game elements.  If this were to be coded, I think it might be a good candidate for a joint coding project.

    Now, for the concept, I set my game in a Medieval themed world, where each player owns a castle, and must destroy the opponent in typical RTS fashion.  There are no air units designed, partly because of the theming, and partly because I think it can get a bit difficult to see what is going on in a battle with flying units, considering the resolution of the screen.  The design sports a regular 8x8 building tilemap, but with a 4x4 movement tilemap.  Meaning all buildings will be constrained to an 8x8 grid, but actual units are 4x4 and have more freedom of movement.  This is simply so the player can see more of their army at any given time.  Now, with the 4x4 constraints, making unit sprites can be a bit tricky, as well as finding ways to designate between enemy and yourself.  This is where I think I could use some help from you guys the most, feel free to offer suggestions, sprites, or changes of the 8x8 4x4 system.

UNITS:
   Now for the units, there are 11 ingame units, each trainable at a specific building.  Each of them has specific stats such as damage, speed, and health, as well as types of armor, and damage type.  Each unit can have 1 of 4 armor types: Soft, Medium, Hard, and Fortified.  And each unit can have 1 of 4 damage types:  Blunt, Sharp, Explosive, or Magic.  These attack and armor types have specific advantages and disadvantages against each other, which can lead to certain units being more or less effective against other units.  The summary of these effectiveness of each damage type against each armor type.

Armor Type	|	Blunt	Sharp	Explosive	Magic
----------	|	----	-----	--------	-----
Soft	|	Good	Bad	Average	Good
Medium	|	Average	Average	Average	Good
Hard	|	Bad	Average	Average	Good
Fortefied	|	Average	Good	Good	Bad

    -Soft armor is flexible and strong, and is good at absorbing energy from ranged attacks, but is light and therefore vulnerable to blunt force.
    -Medium armor is good all around, does not give any extra bonuses against any physical attacks
    -Hard armor is heavy metal plates, extremely strong against blunt force, but weak against sharp penetrating attacks
    -Fortefied armor is usually only dealt to buildings, and is the strongest of all armors, but weak against explosive attacks

    -Blunt force is the kind of attacks dealt by swords and axes, effectively breaking through weaker armor
    -Sharp force is a ranged attack that penetrates armored units, but does less damage against flexible armor
    -Explosive force is good all round damage, and does extra damage against buildings
    -Magic force is very effective in bypassing most lower forms of armor, but has a hard time affecting non biological units such as buildings


Here is a summary of all the units i have designed, with their skills and info:



There are several categories of units.  Regular meele, which consist or soldiers and broadsmen.  Ranged units, which consist of archers ans crossbowsmen.  Siege units, which consist of stationary turrets and catapults.  1 Healing unit.  And magic units, which consist of the mage and the wizzard.   All units cost some amount of resources to create, and all require a house to live in.  1 House can hold 4 units, and some units take up more than 1 space.  To generate the resources to create units, farmland must be created.  Farmland draws in a certain amount of resources per second, and can be upgraded to produce more per second.  More farmland can be purchased for high amounts.  Farmland never stops producing resources, so each castle will never run out of resources to spend on units.  

The magical units are special, being able to cast spells.  The Wizzard is a defensive unit, which can cast non-damage spells that you can use to protect your troops and castle.  Mages are offensive spellcasters, and they have 2 paths of research, Fire and Ice.  You can only research one of these, and therefore only unlock 1 half of the Mage's abilities in a game.  Magical units also require dark crystal to create.  You cannot generate dark crystal on your own, but need to find it in the map somewhere and harvest it.  This both limits magical units to late game, and forces the player to leave the safety of their castle if they want to get magical units.  Players can hunt out and guard these crystal deposits to prevent their opponents from getting magical units.

BUILDINGS:
The player can and must construct many buildings during the game.  All buildings have fortified armor, and a good amount of health.  Different buildings need to be built to produce different types of units, and they are summarized below.  I have not included build time yet, but it should be soon.


The Keep is the most important building.  You can only ever have 1, and if it is destroyed, you lose the game.  All other buildings are either for producing units, or upgrading units strengths.  Upgrades are automatically applied to all units on the field and from there on out.  Even if an upgrade building is destroyed, upgrades already researched will persist.  Houses act as your 'supply limit' in the game.  Each house supports 4 units, with some units taking up more than one place.  There is going to be a supply cap, but it has not been determined yet.  The Sorcery Tower is unique in that it is the only building that needs dark crystal to manufacture, all others simply require resources.




That's it for now, I will likely edit this post as I figure out more information.  Feel free to post ideas and requests!  I am new to designing RTS's, so any and all advice is awesome

I have two coins in my hand.  I flip both of them secretly until I get a result that is not two tails.  I then turn to you and show you that one of the coins is heads, and ask what the probability of the other being heads.

Zedd Physics Library (BETA)
 Zedd is a physics library for Axe programs, allowing all Axe games access to amazing physics.  At its heart, Zedd is a collision solver, but its power lies in the fact that it is built to be expandable!  With 3 libraries already included with the Beta, Zedd is fully compatible with external libraries!  But most importantly, Zedd is Easy to Use!  Never once do you need to delve into the Zedd program to make things work; Everything is controllable via the simple and easy to use function included with the program.

Now with Zedd, your games can feature realistic physics across all objects, and advanced effects such as ropes, springs, moving platforms, and much much more!
Download Link

So I have already started work on my contest entry, which is as of now still unnamed, but progress on the engine goes rather rapidly.  I've already implemented full rigid body physics onto my 4x4 tilemap, and I have also implemented springs, although they are not present in the screenshot.  You will also notice the screenshot is rather explosive

The premise of my game is a puzzle platformer where you are a quite small little person using comically large guns and explosive devices to progress through each level and eventually complete an objective or something.  Right now i'm just focusing on getting the engine working, but so far everything is looking great I'll post progress as it comes ^^

The screenie below isn't really a puzzle, as its pretty simple But it has the basis for becoming a puzzle and right now is just a testing area for testing the various aspects of the game engine.

      So recently me and my friends made a movie featuring Nerf Guns as the main weapons, but the twist was that although they still fired foam, the bullets did the same damage as real guns!  So there is muzzle flare and blood everywhere and quite a fun filled movie :] I am still working on the effects, but this movie also increased me and my friends interest in Nerf Guns, and just the other Saturday my friends (I was working) participated in a Zombie vs Human large scale game at our college that took place for the whole day, in which the humans had to locate information caches, rescue scientists and technicians, all the while fighting off the growing zombie hoard with a wide arsenal of Nerf Guns! 

Anyway, my interest has also been peeked, so I have decided to buy this gun, the Nerf CS35 Raider!



Its got a 35 bullet barrel style magazine, with pump action and awesomeness ^^ I was debating on whether to get this gun or the Stampede, which has automatic fire but takes 6D batteries, and only has an 18 bullet clip.  In the end I decided on this one :]  Me and my friends are already planning to have a few battles of our own!

So what about you?  Do anything with Nerf?  Airsoft?  General battle games around your college?

Do you want your title screens to look like this?


If so, go no further because in this tutorial, I will be discussing how to get epic fire effects into your games and title screens using Axe.  This is applicable to either white fire or black fire, with, or without objects in the fire.

The rules of the fire are simple.  Take each pixel, move that pixel up, then also randomly erase pixels.  Since each pixel on the screen has an equal probability of being erased, pixels near the top have a lower probability of being set, because the pixels would have had to travel all the way from the bottom to the top without getting erased.  But thats a lot of mumbo jumbo, lets get straight to the code:

.Axe
ClrDraw
[FEFDFBF7EFDFBD7F]->Str1  //Each Byte here has 7 bits set and 1 bit not set (like FE is 11111110 in binary)
                      //This is so that we can erase a random pixel, since Axe has no built in way to do that
Line(0,63,95,63       //the pixels to catch fire, explained a little later

Repeat getKey(15)    //until we press clear

For(F,L6+12,L6+767       //loop through all of the screen pixels except the last 12
{F} and {rand^8+Str1}->{F-12}   //take the byte, use AND to erase a single bit from it, and then store it into the byte directly *above* it
End                     //this makes it so that as the byte rises, each frame a pixel is erased from it

DispGraph

End
So why do we need the line command?  Well because this routine needs fuel.  What that means is that if you draw a sprite onto the screen while this routine is running, that sprite will catch fire automatically.  If you stop drawing the sprite, it will rise and vanish like smoke.  Anything you draw onto the part of the screen that is being 'flamed' will automatically catch fire, and will continue to be on fire until you stop drawing it, at which point it will vanish like smoke.  Go ahead try it out!

Also, some of you may want to try a black background with white smoke.  the principles are exactly the same, but everything is inverted.  Instead of FE (11111110), you would use 01 (00000001), and instead of using AND, you would use OR.  Its that simple

So with the recent influx of physics related games, as well as a recent increase in the interest of ball physics, I have become a bit more interested in it myself, and so I spent all of Bio the other day and a considerable amount of time out of class writing this pinball physics engine for pixel based collision.  It uses the onscreen pixels only for collision, although it could easily be changed to a backbuffer or alternative buffer.  This is developed for pinball games in mind, and has several changeable variables which can change the way the ball behaves:

Collision Elasticity: from 0% to 100% How much energy the ball retains after a collision with a wall or object
Rolling Angle Threshold: from 0 to 90 degrees, this value changes how small of an angle the ball has to hit the wall to switch to rolling physics.  If this number is very small, the ball will bound around a lot, if this number is very large, the ball will tend to 'stick' to walls.

These values are currently hardcoded into the code, but in the future I hope to release a flexible engine with a large number of changeable parameters.  As for the engine itself, this is how it works:

The balls position is first backed up, and then incremented by the velocity.  If the ball collides with anything, we enter the collision test segment.  The ball checks the pixels around it to determine the surface normal vector of the wall it collided with.  It then normalizes that vector and uses it to move the ball backwards out of the wall.  If the vector is not accurate enough to get the ball out of the wall, the balls backed up position value is used instead.  We then find the dot product of the balls velocity and the surface normal vector, resulting in a value from -M to M, where M is the magnitude of the velocity of the ball.  If this value is greater than the Rolling angle threshold, perform the vector transformations to subtract the perpendicular vector component from the velocity of the ball.  If the value is less than the Rolling angle threshold, the perpendicular vector is negated, and then multiplied by the Collision Elasticity value.  

Thats a lot of technical mumbo jumbo, lets just get to the screenshots, enjoy!  The screenshot it running with a collision elasticity of 0.5 and a rolling angle threshold of 22.5 degrees