Bay 12 Games Forum

Overall a great job for starting out.  But since we're going for criticism I will have to sing its shortcomings.

The first song the drum sounds a little too clear, almost like your sitting RIGHT next to the drum set but listening to the dubstep in another room.  Drums need to have some sort of a lowpass filter or something, maybe just a little touch with an equalizer would clear it up.  Also the song seems to consist of 4 parts and 4 parts only.  There is little variance in each of the four parts which almost makes you feel bored half way through a part.  Varying the parts up, even repeating some parts works just fine.  Many songs repeat their chorus and verse 2 maybe even 3 times in one song; if they just put it all in one stretch it would be boring to listen to.

For the second song it sounds...too happy?  Too many major keys and not enough minor.  The spoken words also seem to kill the momentum of the song, but they do add some flavor that I think would be lost if they were not there.  I've never worked with music with words so I can't really give much advice on that.

So that is all the criticism I have for it, besides that a fine job.

Do you have an .exe or so to start it up? It seems the one downloaded from Filefront doesn't have one.

There should be one.  I just downloaded it myself and it was there.  Did you use WinRAR to extract it?

I was just playing space station 13 as an engineer setting up the singularity (a giant black hole engine that WILL explode if you mess up).  I was just about done setting up the containment field when some a-hole turns it on without asking if I was done releasing the blackhole and blowing up half the station.  I die and of course Mr switch-flips-alot goes on a rant about how I "set it up wrong" and the whole server gets mad at me.

I've got one suggestion: You might want to use a hierarchical graph instead of a grid (with a tree being the most trivial case in which no cycles are allowed).

Sounds like a nice way to save CPU, but how would a build system work with that?  My original plan was to have the player just place blocks 1 by 1 via mouse picking.  (For those who don't know what the term means, mouse picking is basically selection on an object.  Click the side of a block and it puts a block connected to that side of the block you just clicked etc.)  With a hierarchical graph, it would be more based on selecting bars for arms and such, or at the very least, it would resemble rigging a skeleton for 3D animation by placing vertex points and connecting them.  Is there a better way to make a robot with that sort of system?

Edit : Wait, do you mean have it be built in the 3 Dimensional grid system, but then have the JOINTS be placed in a hierarchy?  That would allow for a hybrid between both extremes.

I don't see AI being added for a while.  Difference between MechWarrior and this is the physics involved.  MechWarrior didn't really have walking physics, it was just an animation.  For this I want full physics with the mech's legs incorporating full autobalance.  AI would be harder to implement with this.

Mech Combat

    This is a game project with a simple goal.  To achieve large battles between completely custom machines build out of lego like pieces in an easy to use and intuitive editor.  To accomplish this task the player will be given many decisions regarding mobility, sensors, weapons, and other miscellaneous tools needed to achieve dominance on the battlefield.  I intend to use insight from users of the game to help shape the final product.

For now, however, I have an editor and a little field for you to try out mobility with.

You can find the game here :
http://www.gamefront.com/files/21800016/MechCombat_Build_0_1_4_rar

-------------Due to a lot of stat changes and interface overhauls, save files from 0.1.3 are incompatible with 0.1.4-------------

Changes from 0.1.3 to 0.1.4 :
   --Improved the respawning on the field to allow robots to be destroyed.  (Before the system merely relocated your machine, it didn't create a new one and delete the old.)
   --Made a basic framework for destroying blocks with weapons.
   --Made a basic framework for destroying sections with weapons.
   --Added ricocheting to bullets.  Although every bullet technically has a very slim chance to ricochet of any surface (even dirt) it gets slimmer the softer the surface and the heavier the round.
   --Made so recoil is now directly linked to the mass and velocity of the fired rounds.
   --Added a very basic material system that controls the hardness and "bounciness" of a material.  This effect how bullets collide with it.
   --Improved the builder engine to allow placement of parts with more tilted attachment points.
   --Added an attachment point to the Inverted Three Sided Corner on the tilted side (made possible by engine improvement).
   --Added a death sequence for when a section takes enough damage to be destroyed.
   --Slightly changed dimensions of corner pieces.  I am working on making blocks stretchable and their current dimension had no rhyme or reason to it, so I changed the size to be a little bit easier to work with.
   --Bullets should no longer fly through objects even when experiencing lag spikes.
   --Added a barrel part.

**Some notes about damage :
   Currently how damage works is each individual part placed contributes a certain amount of health to a larger health "pool".  This pool is the health of the chunk the block belongs to.  Damaging any block damages the chunk it is connected to, but if an individual block is destroyed, you can no longer shoot it to damage the chunk.  With the current system, you need to destroy roughly half the blocks to make the entire chunk explode.
   Destroyed block still offer structural integrity to the chunk they are connected to.  This means you cannot defeat someone by "chopping them in half".
   When an individual part is destroyed, if it has a use (such as tracks, guns, hover, etc.) it will be permanently disabled.
   Destroying the brain, or the chunk that the brain belongs to, defeats an entire mech, no matter how large or complex it may be.
   Currently explosions do no damage.

**Some notes about ricocheting :
   Rounds are more likely to ricochet the more parallel to the surface they are.  This means that using 45 degree angles on the mechs can drastically decrease the chance of bullets actually penetrating your blocks.
   Certain rounds (like the tank cannon's shot) are explosive and will be set off when they collide going at a particular velocity.  This means that they will be set off no matter the hardness of the surface.  If the angle between the shot and the surface is shallow enough, however, then it is still possible for the explosive to ricochet.
   If a round explodes on impact instead of going through the target (like the tank shot) then it is possible for the round to be stopped without actually exploding.  Think a round impacting soft sand at a very shallow angle and being stopped by it.

**Some notes about builder improvement :
   Although this improvement doesn't actually show up to the player very much, it was a rather jarring flaw with the system I had programmed until now.  You see, with parts such as the corner, the player is able to place other parts at a tilted angle.  The engine, however, only supported having parts which have a tilted attachment point along the z and y axis (forward and up), it did not allow angles along a combination of x and y, or x and z.  Now that the engine supports this it should allow me to make some more complex parts.  Such as a sphere.

Bug fixes :
   --Further improved the stability of joints and decreased their wobble.  Large machines still experience some issues.

Known Bugs :
   --You can't enter negative values in the parameter boxes.
   --Bullet trails sometimes go past the bullet when it collides with an object.  This does not effect the bullet itself, however.

Screenshots (These are old and need to be replaced.) :


The game's controls are in the included readme file.

I also apologize that there isn't too much to do at the present moment besides try out designs.  Any suggestions for filling in the content are encouraged.

Suggestions and comments are very much appreciated.

One interesting technique to try for an AI with no hardcoded knowledge is a trial and error system.  Have the AI face off against an opponent with a certain set of units and record how successful it was.  Document this knowledge in an .ini file or something of that sort for future reference.  The ai could then build knowledge, like look at how pikes fared against swords at different distances and average the success rates to get a general idea of how good a particular set up is.  Throw some random moves in there to keep it interesting and to help the ai keep documenting various tactics.