This game could be very fun without worrying about such complex things. At the same time, without a challenge there isn't much of a game, and managing such things would be an interesting one. I'd suggest adding those parts, but not making them mandatory. So if you put a couple of fuel tanks on your mech, it can run out of fuel, but if you skip them it will run indefinitely.
Moving parts are definitely a must. Another little thing I'd like is more precise control of where to put plates; currently they always go in the middle of a given cube on the grid, but I'd like to be able to put them on the top or bottom.
Hovercraft are prone to flipping, and flying with thrusters seems nigh-impossible. One idea, which would admittedly take a lot of time, would be to create some system to automate them, so that the whole construct stays up. I dunno how hard it would be to include auto-balancing, but another idea would be to include some rudimentary 'if-then' programming. In fact, including some rudimentary programming seems to be the only truly viable method to create truly large and complex mechs.
Ah, but maybe I'm getting a bit ahead of myself. Say, have you created any kind of design document? Planning things out before you do them is surprisingly useful.
A lot to talk about here, so I will cover the material in paragraphs.
The problem with making the things like fuel not necessary and having machines that use it now have the disadvantage of running out of fuel, is that it is not very fair in a multiplayer environment. There are two solutions I see, however. The first one is to have different "leagues" of multiplayer, one complex and one simplified. Another solution would be to have something like Solar plating that essentially makes you never run out of power, but you have far less power output. While if you used something like nuclear fuel rods, or hydrogen fuel cells, you would get much more power, but your fuel would be limited. Balancing this would be interesting to work out, but I think either solution is a viable one.
Moving parts (I interpret this to be stuff like turn tables) are being worked on now. I already have a basic turn table that I am programming and works almost perfectly so far. It still has one major bug, however, and I need to iron it out before release. For those of you who care to know, the bug stems from the problem of how collisions are managed between the base and top of the turntable. Long story short, the two rigidbodies the turn table connects don't collide with each other. Meaning you can make parts of your robot phase through itself! Once I get that bug fixed, I see no reason why it won't be ready for release.
I have thought a lot about how to make objects not be centered on a surface all the time, and I find it to be a difficult problem. The problem stems from exactly how to go about the problem. Would a cube have 9 snap points on each face for objects to grab onto? Would it have 5 on each side, 4 for each corner, and one for the center? Would you be able to just hold a button and freely slide the object around on the surface of the part you are placing onto? The problem with adding one is that it complicates the process of just normally placing a block. How the system currently works is every block has "points" on the surface of it. These points hold position data, and they also hold rotation data (this rotation is orthogonal to the surface). This data is then compared between two objects, the one you are placing and the one you are placing onto, and then it calculates the position and rotation needed. This system was the hardest thing to code in the entire program, and is why it took me almost a year to go between build 0.0.4 and 0.1.0. I need a very solid gameplan before I try and change the system. If you have any suggestions on how it should work, I would be very pleased to hear them.
Hovercrafts flip a lot, this is true, but they do have an automation that keeps them stabilized. The problem with this stabilization, is it only compares the rotation of the machine to the rotation of the ground. They form a "mesh" from points they collect by projecting a "laser range finder" to the ground. When they get the data, they all try to align themselves in a way that is the most stable. The problem is, they sometimes exert too much force in balancing because they do not take the crafts current momentum into account. I will incorporate it eventually (I definitely should). I have made some incredibly stable designs with hover when I was testing them, they key is to give them wide bases and center the weight of the machine properly. Although this makes them a lot harder to build with because you are now managing center of gravity whereas you can almost (almost) ignore it with tracks, they payoff for a well designed hover craft is monumental.
As for flying, helicopter blades are something on my ever growing to-do list. Gunships would be tons of fun I think.
Ultimately though, mechs are kinda wobbly and unstable and I acknowledge this as a pressing issue. It took a very long time to get them as stable as they are now. You may not even notice it when you casually play, but the individual links on the treads are all accommodated for, with 3 points each (for sideways tilt) to properly calculate how to apply forces when moving; even then they still flip on smaller designs. The hover drives are all trying to apply forces to keep off the ground while at the same time trying to make sure the craft doesn't move into a strange angle. Sadly with problems like these, I find the only way to solve them is slow adjustments and fine-tuning over time.
Edit : Just wanted to say this before it gets suggested. In the next build, I have added the ability to place stuff like tracks and hover drives directly onto the ground without them being sideways or facing upwards. This should make constructing a mech easier for now you can just place the movement components and go from there.
Author
Topic: Mech combat (Version 0.1.4) New build as of 6/5/12 (Read 3793 times)