Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[MirrorIrorriM]

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.) :

Spoiler (click to show/hide)

Build machines using a nonrestrictive editor!

Use your inventions in full 3D physics environments!

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.

[devek]

I don't really have much to add, but I <3 mechs. The worst part about the last mechwarrior was the waypoints navigation AI used. Your teammates were never where they were supposed to be, especially in a city! Use vector meshes and tweak that stuff so mechs position themselves correctly and people will love your game. The other stuff would just be icing on the cake.

[MirrorIrorriM]

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.

[Nadaka]

you do realize that walking body simulation is a doctoral level computer science thesis project or worse, right?

[Virex]

And that a self-balancing AI usually takes a computer and a half worth of processing power?


(I remember thinking for some time that simulating reactions for a game would be feasible. That is, until I learned that for those kind of simulations, the frame rate is measured in frames per minute. I've just ran a simple simulation of 125 butane molecules, not taking reaction into account. It ran on a comfortable rate of 4 frames per second. Each frame was a femtosecond...)

[MirrorIrorriM]

Oh no no no no no.  The auto balancing would mostly be stabilized by the legs "welding" themselves to the ground.  They would simply attach themselves to a surface making so the only thing left to do is keep the body upright.  The bottom of the foot is the most difficult part of walking and it is a miracle that it works as well as it does, welding the foot to the surface removes this factor all together.

Not to mention spider robots would work fine without complicated balancing algorithms, come to think of it.

Also I put it pretty far down the list for a good reason.  Getting it to work efficiently will be very difficult.  Also If it truly turns out to be impossible, there are always simple alternatives such as rigging a skeleton to a ragdoll and having physics be applied when a force is strong enough to knock it off kilter.

[Virex]

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). It should make things easier on joints and severing, because each vertex in a graph is a generalized connection between two parts of a mech and loss of connection in a graph can be checked easily. A joint would be a special kind of vertex that allows rotation. Furthermore, using graphs means you don't have to use blocks in the first place, since any kind of object can be part of the graph.

[MirrorIrorriM]

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.

[Virex]

Well, you could do it with blocks if you'd like. You could also use spheres, or tori, or bunny ears or whatever else you'd like. The graph itself doesn't care about the shape or size of it's components, it's just a data structure in which each element has a link to everything that is connected to it (in the simple case of an undirected graph). So you could have a head that has a link to the torso, the left eye and the right eye. The torso has a link to the head, the left arm, the right arm and a link to each of the legs et cetera. It would free you from the need to use blocks and it'd save you some space since each leaf of a node itself can be anything you like (assuming your implementation supports it).

[MirrorIrorriM]

Just released the first playable build.  There were a few before but they were too buggy to release.

[Hitty40]

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

[MirrorIrorriM]

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?

[Hitty40]

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?

Yeah, used WinRAR to extract it to my D drive, all the files are there and such, but no .exe.

[MirrorIrorriM]

Did you just extract the "Mech Combat_Data" folder?  The .exe, "Mech Combat.exe", is in the "MC 0.0.4" folder which the "Mech Combat_Data" folder is inside.  Try using "extract here" to preserve the top folder.  Or look in your D: drive to see if the .exe got lost among the other files.

This is probably my fault, I should have made a folder above the main one to prevent this from happening.  Definitely will remember to do that for the next build.

[metime00]

For those doubting the possibility of physics and walking I direct you to http://www.fun-motion.com/physics-games/sumotori-dreams/

I'm sure with a bit more cheating Mirror could make a walking system more complex than just gluing the feet to the ground if he thinks it's worth it.