MechCombat (Version 0.1.4) New Build! 6/5/12

[NineFourEightSeven]

A trojan is kind of a virus, right?

I'm not saying I caused it.

[Inconspicularity]

A trojan is kind of a virus, right?

I'm not saying I caused it.

I'd understand why you said that if someone posted any malware in this thread but I scoured the whole thing and didn't find any.

[NineFourEightSeven]

He said he wasn't updating because he had a trojan.

I was just asking the status of the project.

[Inconspicularity]

Whoops, misunderstood EVERYTHING. Thought you were implying mechcombat was a virus.

/ollies outy

[aggrievesTemulence]

Hey, +1 follower and interested party. A few notes and suggestions.

Placing treads facing the correct direction can kind of be a pain sometimes. A simple toggle box that changes the direction of the treads once placed would be might helpful.

I've also noticed that recoil seems a bit random. Firing from the same position 5 times, the first two shots just rocked my tank a little, the third moved me very dramatically, and the following two shots had no effect. I don't know what's up with that. Once you get joints figured out and working, hopefully that will open up the possibility of stabilizing arms, like you see on big construction machinery.

It would dramatically open up the realm of aesthetic possibilities in the editor, not to mention the possibility of more advanced mech designs, if you could move blocks in amounts less than one unit at a time (I'm defining a "unit" here as the length of one side of a block). Perhaps, pressing "o" will move the selected object up one unit, whereas hodling "Ctrl" and pressing "o" will move the selected object up one tenth of a unit. Something to think about.

This might just be my personal preference, but I don't like the way you currently have the camera rotate. I'm not so sure how to describe this very well, but at the moment, it's as if you have the camera on the inside of a sphere, and by holding down the middle mouse button you move the focus point of the camera which rests somewhere on the surface of that sphere. My preferred way of working with first-person camera views is by having the camera on the surface of the sphere with the focus in the center, and by holding down the middle mouse button you move the camera's position on the sphere, leaving its focus point in the center.

Still on the subject of camera controls, it would significantly improve the usability for me if pressing "w" and "a" moved the camera forwards and backwards instead of zooming in and out. You could move the zoom controls to the middle mouse wheel. I know you said you wanted to leave the mouse wheel open for quick item select or something else, but you could have it so that when the mouse is outside of a menu then the mouse wheel zooms. Then, if you have the mouse inside of a menu it scrolls up and down. Something to think about, anyway. Either way, I would really like camera controls for moving forwards and backwards.

On the subject of increased difficulty or complexity in the builder: I am all for it! However, it should be noted that increased complexity for its own sake is never a good thing. I think, however, that placing limits on the builder encourages creativity, as long as you keep those limits from being too stifling. A system I would like would focus on two stats: Build Points (which would be a gaming abstraction and have no effect on the mech's in-game performance) and Power. Build Points would be the balancing factor keeping two different mechs from being on approximately the same level; you could have competitions with a max Build Points of 500, for example. Power, on the other hand, would be produced by Engines or other power plants (purchased with Build Points) and would be necessary to power weapons, locomotion, and defenses(?). In this way, a builder would have to split their allocated Build Points between acquiring more Power, or building the things that Power is used for. Just these two stats alone provide you with a lot of opportunity for balancing and fine tuning, and the more parts you add which interact with them (having 3 different power plant sizes that have correspondingly different Build Point to Power output ratios, for example) increases the complexity many-fold, so you might want to be careful.

Finally (for now ), I have an idea about a sort of secondary stat to be kept in mind when building mechs: Mass. You already mentioned that Mass plays a part in keeping Hover mechs stabilized, but I haven't really played around with that all that much. Presumably higher Mass mechs move more slowly as well? Anyways, I very much like asymmetrical designs, but it would be very annoying if said designs were inherently less stable. I suggest, therefore, that we also be able to change the Mass of the blocks we add. For example, if I had a mech with one block on the left side but three on the right I could have the right blocks have a mass of 100 each, whereas the one on the left would have a mass of 300. This could be explained away as making the different blocks out of materials of differing density, or more massive blocks could have a higher armor rating, and thus a correspondingly higher Build Point cost.


Anyways, there's a whole bunch of stuff for you to think about! Good luck with your ventures, I'll be following this thread for sure. Now, time to go play around with hover mechs...

[MirrorIrorriM]

How goes the computer virus?

The virus is completely removed from my computer, I actually had it fixed within a week of posting that I acquired the virus. Thanks for asking!

The current reason I haven't made a new release goes deeper down than simply having work to do, because I have almost finished everything people suggested. No the problem I have is not lack of ideas or lack of things to do, it is lack of direction.

Mech Combat's title alone is an indicator of an unfinished product. Mech Combat is kinda like saying "Jumping Platformer" or "First Person Shooter", or at least that is what it is intended to convey. If you really want to get deeper into the concept of the game, you can see a lot of information in the detail of the blocks.

Or lack thereof.

You see, all the parts in mech combat are blank slates with no real detail, this isn't because that is a style I am going for, it is because I have no idea what I want the end product of this game to look like. I have drawn out countless stories and possibilities that the game could pursue, but nothing really seems good enough. I have made many game projects in the past with ease, but for some reason the more I care about a project, the harder it is to come up with a good idea for it. So me not updating has nothing to do with programming speed or computer problems, it has to do with a lack of direction of the project. My idea going into this project was to create a game where you could build your own mech and fight with them, but the project has become much more personal to me than that. I am beginning to just ramble now, but my point is that when I find a direction I would like the game to pursue I will be able to come back full steam.

...Steam...maybe a steam punk theme? I'll get back to you guys on that.


And it looks like I got a ton of stuff to think about from aggrievesTemulence. So lets get cracking!

Placing treads facing the correct direction can kind of be a pain sometimes. A simple toggle box that changes the direction of the treads once placed would be might helpful.

Pressing R twice rotates a block 180 degrees. That should be all that is needed to make it face the correct direction. Before I go adding a toggle button that flips the direction of a solid object (something the engine isn't designed to handle) I will need more clarification on the exact problem you are describing.

It would dramatically open up the realm of aesthetic possibilities in the editor, not to mention the possibility of more advanced mech designs, if you could move blocks in amounts less than one unit at a time (I'm defining a "unit" here as the length of one side of a block). Perhaps, pressing "o" will move the selected object up one unit, whereas hodling "Ctrl" and pressing "o" will move the selected object up one tenth of a unit. Something to think about.

It would be almost no effort to add that, but I must warn you that it wouldn't work with the current system. You see, whenever a block checks to see if it is connected to another object, it has to check its "connection points" to see if anything is there. Even if you slid them only 1/10th off their offset points, they would no longer connect and your mech would fall apart as soon as it spawns.

On the other hand, the system in place allows you to have sliding plates that interlock in complex ways while not actually connecting. Something I have used for my own personal russian nesting doll robots.

I'll have to chew on that topic before I make any decisions.

I've also noticed that recoil seems a bit random. Firing from the same position 5 times, the first two shots just rocked my tank a little, the third moved me very dramatically, and the following two shots had no effect. I don't know what's up with that. Once you get joints figured out and working, hopefully that will open up the possibility of stabilizing arms, like you see on big construction machinery.

The first two shots sound like they did the desired effect and the third shot you were closer to the explosion and caught some of the shockwave. Otherwise it is possible you were already tilted upward and the recoil had less resistance from gravity so you moved back more drastically. The following shots probably had no effect because you had a downward rotational velocity which canceled their force. If you can get back to me with a more detailed description of the events at hand I could see if I can replicate the problem. Try posting a copy of your mech on the forum for me to check out.

This might just be my personal preference, but I don't like the way you currently have the camera rotate. I'm not so sure how to describe this very well, but at the moment, it's as if you have the camera on the inside of a sphere, and by holding down the middle mouse button you move the focus point of the camera which rests somewhere on the surface of that sphere. My preferred way of working with first-person camera views is by having the camera on the surface of the sphere with the focus in the center, and by holding down the middle mouse button you move the camera's position on the sphere, leaving its focus point in the center.

Ah yes, the classic rotational camera versus my current first person camera. To tell the truth, my original camera from a long time ago did exactly what you suggested. It had a serious problem, however, in that it could not see in tighter spaces around the machine. Many designs require you to move your camera in very right positions and sometimes even go inside the machine, through the blocks, to place something correctly. Because of this, a first person camera is required to be able to build as many things as possible. However, your request hasn't gone unheard and I will definitely consider adding camera options in the future. Perhaps even multiple camera modes to make building easier.

Still on the subject of camera controls, it would significantly improve the usability for me if pressing "w" and "a" moved the camera forwards and backwards instead of zooming in and out. You could move the zoom controls to the middle mouse wheel. I know you said you wanted to leave the mouse wheel open for quick item select or something else, but you could have it so that when the mouse is outside of a menu then the mouse wheel zooms. Then, if you have the mouse inside of a menu it scrolls up and down. Something to think about, anyway. Either way, I would really like camera controls for moving forwards and backwards.

I will probably make that an "Absolute Camera" mode and have what is currently in game be a "Localized Camera" mode.

On the subject of increased difficulty or complexity in the builder: I am all for it! However, it should be noted that increased complexity for its own sake is never a good thing. I think, however, that placing limits on the builder encourages creativity, as long as you keep those limits from being too stifling. A system I would like would focus on two stats: Build Points (which would be a gaming abstraction and have no effect on the mech's in-game performance) and Power.

A swell idea that can be easily expanded upon. A globalized power system shouldn't be that hard to add. And a system that keeps track of how many points you have spent shouldn't be that hard either. For now though, I will not add the build point system for a while for 2 reasons.

1) There is no reason for it currently, there are no enemies and there is no multiplayer, so adding a limit in that regard would just keep people from building whatever they want.

2) People pushing the limits of the builder at this stage is important. Say there is some memory overflow I know nothing about that happens when someone fills every last space with a block or something like that. Unless someone does that, I will never learn about it. Until the game is more finalized, I won't have need for a point system. But I like your idea nonetheless.

Finally (for now ), I have an idea about a sort of secondary stat to be kept in mind when building mechs: Mass. You already mentioned that Mass plays a part in keeping Hover mechs stabilized, but I haven't really played around with that all that much. Presumably higher Mass mechs move more slowly as well? Anyways, I very much like asymmetrical designs, but it would be very annoying if said designs were inherently less stable. I suggest, therefore, that we also be able to change the Mass of the blocks we add. For example, if I had a mech with one block on the left side but three on the right I could have the right blocks have a mass of 100 each, whereas the one on the left would have a mass of 300. This could be explained away as making the different blocks out of materials of differing density, or more massive blocks could have a higher armor rating, and thus a correspondingly higher Build Point cost.

As is mass makes things move much slower and more sluggishly while providing increased stability and (eventually) durability. As for asymmetrical designs and balancing them, I have a material system planned for parts. That should solve your problem with weight.

I know this has been a crazy long post, but I would like to spur up some discussion by asking you guys for advice on some story settings I came up with. I will put them in a new post once I formulate my ideas ( I might even have some concept art ready! )

[Didero]

On the topic of Build Points, can't you just have an increasing counter without a limit, instead of the suggested decreasing counter with a set starting point?
I don't think I phrased that very clearly, so let me elaborate:
I think the system being suggested here is that you start with, say, 500 points. Every piece you place reduces the available points with a certain amount, with more complex pieces having a higher cost. When you reach 0 points, you can't place any more pieces
My suggestion is that you start with 0 points. For every piece you place, that number increases, again with more complex pieces increasing the number more. There wouldn't be any real limit to this counter. That way you can have informal limits ('Guys, let's just use a maximum of 500 points this time, see what we can build') while still allowing unlimited creativity by just ignoring the build points.

[Inconspicularity]

My idea for an end product is where everything is manually built. Not even motors are pre-built items. The building scheme is first-person building (think minecraft), and things are limited in quantities. Want to build a wheel? build one with bent sticks. Want to have that wheel powered? Create a motor using electromagnets. Want to control the motor? Create an electric circuit that toggles electricity direction depending on inputs.

Okay maybe not that deep down. But I do want circuitry instead of scripting. And I have yet to see anything that has good wiring systems.

Basically the end product is a machine creator where masterful builders can spend weeks working on perfecting their creations.

And I mentioned it being first-person; that has an element of its own. I want the line between "building mode" and "fight mode" to be almost non-existent. You are always first person, and you start off in a smallish garage with a small amount of basic building materials. Once you've created a vehicle that's actually controllable (yes, you need to make your own cockpit and wire it up) you can go outside through the door (this door being openable even if you don't have a vehicle). The door leads to a moderately peaceful area (no forced pvp), where small AI-critters drive around (like bugs). You can use those for practice or disable one and collect its parts. The further away you get from your garage the more powerful critters become.

A factor I find very important is that there is no health points. Your vehicle is a vehicle. You have built it and you know how it works. For an enemy to "kill" you they could either straight-up kill your character, or they could disarm/demobilise your vehicle (breaking supply lines or wires), and kill you then. Getting "damage" is still a thing, but it isn't fixed by finding some batch of magical nanobots or something. You have to actually get out of your vehicle and replace sheets of metal, repair circuitry, fix piping, etc. And because you can repair your ship even without being in your garage, you can get out in a moderately peaceful area and repair stuff. Later on with more advanced stuff you could make repair drones, etc.

And seeing as things you make don't specifically have to be things for your vehicle, you could even make smaller vehicles designed for making building your bigger vehicles easier. You could even make a fucking ketpack if you get the right tools.

On the netcode sides of things I imagine a thing like this would either be MMO or long-lasting multiplayer. A group of 20 people could make a private server that only "resumes" when most of them are online, where the server is not a permanent world but a competitive match with two or more teams with their own bases (YES EVEN BUILDINGS CAN BE CONSTRUCTED (you could make a building that can mobilise itself, if you have enough tech))



This is my idea for an end product. I seriously doubt a single developer could make something so intricate (hell, I doubt an entire team can). I just really want to see something like minecraft but off the scales when it comes to sheer detail.

[Inconspicularity]

My idea for an end product is where everything is manually built. Not even motors are pre-built items. The building scheme is first-person building (think minecraft), and things are limited in quantities. Want to build a wheel? build one with bent sticks. Want to have that wheel powered? Create a motor using electromagnets. Want to control the motor? Create an electric circuit that toggles electricity direction depending on inputs.

Okay maybe not that deep down. But I do want circuitry instead of scripting. And I have yet to see anything that has good wiring systems.

Basically the end product is a machine creator where masterful builders can spend weeks working on perfecting their creations.

And I mentioned it being first-person; that has an element of its own. I want the line between "building mode" and "fight mode" to be almost non-existent. You are always first person, and you start off in a smallish garage with a small amount of basic building materials. Once you've created a vehicle that's actually controllable (yes, you need to make your own cockpit and wire it up) you can go outside through the door (this door being openable even if you don't have a vehicle). The door leads to a moderately peaceful area (no forced pvp), where small AI-critters drive around (like bugs). You can use those for practice or disable one and collect its parts. The further away you get from your garage the more powerful critters become.

A factor I find very important is that there is no health points. Your vehicle is a vehicle. You have built it and you know how it works. For an enemy to "kill" you they could either straight-up kill your character, or they could disarm/demobilise your vehicle (breaking supply lines or wires), and kill you then. Getting "damage" is still a thing, but it isn't fixed by finding some batch of magical nanobots or something. You have to actually get out of your vehicle and replace sheets of metal, repair circuitry, fix piping, etc. And because you can repair your ship even without being in your garage, you can get out in a moderately peaceful area and repair stuff. Later on with more advanced stuff you could make repair drones, etc.

And seeing as things you make don't specifically have to be things for your vehicle, you could even make smaller vehicles designed for making building your bigger vehicles easier. You could even make a fucking ketpack if you get the right tools.

On the netcode sides of things I imagine a thing like this would either be MMO or long-lasting multiplayer. A group of 20 people could make a private server that only "resumes" when most of them are online, where the server is not a permanent world but a competitive match with two or more teams with their own bases (YES EVEN BUILDINGS CAN BE CONSTRUCTED (you could make a building that can mobilise itself, if you have enough tech))



This is my idea for an end product. I seriously doubt a single developer could make something so intricate (hell, I doubt an entire team can). I just really want to see something like minecraft but off the scales when it comes to sheer detail.

[MirrorIrorriM]

My idea for an end product is where everything is manually built. Not even motors are pre-built items. The building scheme is first-person building (think minecraft), and things are limited in quantities. Want to build a wheel? build one with bent sticks. Want to have that wheel powered? Create a motor using electromagnets. Want to control the motor? Create an electric circuit that toggles electricity direction depending on inputs.

And I mentioned it being first-person; that has an element of its own. I want the line between "building mode" and "fight mode" to be almost non-existent. You are always first person, and you start off in a smallish garage with a small amount of basic building materials. Once you've created a vehicle that's actually controllable (yes, you need to make your own cockpit and wire it up) you can go outside through the door (this door being openable even if you don't have a vehicle). The door leads to a moderately peaceful area (no forced pvp), where small AI-critters drive around (like bugs). You can use those for practice or disable one and collect its parts. The further away you get from your garage the more powerful critters become.

Basically the end product is a machine creator where masterful builders can spend weeks working on perfecting their creations.

The closest I have seen any "game" get to that was wiremod for g-mod. Yes, a mod, for a mod; and it was amazing. You had to have chips for literally everything, which was the appeal. Wanna make so pressing A and Z makes your robot go twice as fast? Gotta make a chip to add their values together. You also need a chip to decide what their values are.

However, I'm not saying I plan to go that route for one very important reason, curve of interest. Remember when you first started playing minecraft how you had troubles getting on your feet for the first 1 or 2 nights, and then you got the hang of making buildings to live in? Well the problem is, imagine if those 2 days you are getting used to the game, you also need to figure out HOW to make a building. And if it just so happens that all the concepts required to make said building require 4 years of civil engineering, well that just shuts out almost everyone trying to immerse themselves in the game. Well I don't plan for mech combat to be some easy game where constructing a mech is just a waste of time, I do need to make the game accessible to as many people as possible. Although, your idea of a firstperson mech construction system is easily put into a "scavenger" mode. Something which sounds very exciting to make and play. I will definitely consider it. (I know I say I'll "consider stuff a lot" but trust me, I actually put it on a list that I look at whenever I plan a new feature, so don't think I'm just trying to get you to be quiet or anything.)

A factor I find very important is that there is no health points. Your vehicle is a vehicle. You have built it and you know how it works. For an enemy to "kill" you they could either straight-up kill your character, or they could disarm/demobilise your vehicle (breaking supply lines or wires), and kill you then. Getting "damage" is still a thing, but it isn't fixed by finding some batch of magical nanobots or something. You have to actually get out of your vehicle and replace sheets of metal, repair circuitry, fix piping, etc. And because you can repair your ship even without being in your garage, you can get out in a moderately peaceful area and repair stuff. Later on with more advanced stuff you could make repair drones, etc.

How I plan to do damage (and I would like everyone's opinion on this) is to make so you have a "chassis" which is more or less invincible and cannot be broken apart. The rest of your machine, however, such as guns, tracks, and things like that can be destroyed or disabled. To prevent the chassis from blocking too many shots, I will make them able to be "destroyed" but remain to hold your mech together. Basically, you turn the block into swiss cheese and shots now go freely through it (or are blocked a % of the time or something like that), but it still is there to hold your mech together (because having block by block severing code takes too much processing power.)

And seeing as things you make don't specifically have to be things for your vehicle, you could even make smaller vehicles designed for making building your bigger vehicles easier. You could even make a fucking ketpack if you get the right tools.

It sounds like you want pilots to have just as much role as the mech they drive. That is definitely a potential route to go with this project.

On the netcode sides of things I imagine a thing like this would either be MMO or long-lasting multiplayer. A group of 20 people could make a private server that only "resumes" when most of them are online, where the server is not a permanent world but a competitive match with two or more teams with their own bases (YES EVEN BUILDINGS CAN BE CONSTRUCTED (you could make a building that can mobilise itself, if you have enough tech))

Oh man, MMO mech fighting, hah. As fun as that sounds, the processing required for a server to hold everyones mechs and their ever changing data, especially when I'm not using a basic grid system, would be a nightmare! Long-lasting multiplayer on the other hand sounds delightful. Although I like the idea of teams making their own bases, the question is WHO gets to design it and would griefing come into play? If each team had a randomly selected or voted on commander, than that would solve that problem.

This is my idea for an end product. I seriously doubt a single developer could make something so intricate (hell, I doubt an entire team can). I just really want to see something like minecraft but off the scales when it comes to sheer detail.

Actually, you haven't suggested anything complicated that a single developer cannot due. Personally, with all of the money he had for the project, Notch disappointed me greatly with the end product for Minecraft. He could have done so much more with it but just left it in (what I consider to be) a half finished state. Although, personally, I'm the kind of guy who thinks all games should never be "finished" and always expanded till there is literally nothing left to do development wise, but enough of that.

Creating a game where the user does all the building and construction is a very easy thing for me to do as a developer because 'I' don't have to do as much! It is actually a really simple thing to create a game like minecraft and have all the pieces move (as long as you already have an engine you made to do it, like me) and expanding the system to accomplish that wouldn't be an overwhelming amount of work. But the question is whether or not a system like that is desirable, or whether it is just too much work to construct a mech.

So let me address this question to everyone. How do you think the game should fare when it comes to the builder vs the game? Would the emphasis on the game be more about building a mech and duking it out to best your opponents? Or would the game be about besting your opponents with a customized mech? It is Construction vs Destruction and I want everyone's opinion on it.

Also people's ideas for end products would also be nice.

[Inconspicularity]

With the buildings, I think having a starting "shack" (scaling size to the amount of people on the team) is a good idea. My concept for building is very similar to Garry's Mod; you can carry, move, rotate, etc things. I think all players should start off with a Gmod-style super-gravgun, but with an added ability to cast a "stasis field" on objects that lasts for around 20 seconds (this is for anchoring pieces together more effectively). Because there is no "block grid", it allows for less minecraft-like shapes, and it has the added effect of making quality structures look a lot better than something someone built in 5 minutes. Since building blocks can't just be placed in some sort of magic item-condensing inventory like minecraft, you have to add some sort of scrap-collecting device to your vehicle itself. Or you could make a big bucket, and just manually pick it up and move stuff into it.

For gamemodes: I have 3 ideas.
1: Survival: Survival is pretty much like minecraft; not on rails but with some eventual end-goals that are randomly generated. For example, there could be a giant volcano a few hundred kilometres away that has a very big AI structure inside with giant tentacles waving out the top of the volcano.
2: Sandbox: Infinite of every resource, this is just for straight-up designing stuff. Things here can be saved into blueprints and used in other worlds (if you have enough materials of course), and make a sort of "grid" where putting required items roughly where they should be will snap them into location. If you're boss enough, you could make a machine that automatically places things in the right places.
3: Multiplayer: You already know this one.

The reason I didn't list some sort of campaign mode there is because I don't think it is necessary. If you have done Survival mode well enough, it will essentially be infinite campaign mode.

With the chassis: I don't think having a fixed chassis is a good idea. Maybe having some sort of ultra-tough material good for a central spine (could stuff wires and piping in there too) seem decent, and I know that coding physics objects without a "root" object is really damn hard, but I still think it should be possible for things to be cut entirely in half but still be functional (if built by a genius). Coding an AI module to activate when its disconnected from the pilot? Boss. Coding it to pick its parts back up and head back home? Son, ye gonna survive a long time in these wastelands.

[Traikan]

I'll toss my two cents in.

I think it's very easy, when playing games like this, to get stuck in a design rut. Keeping to a few favorite weapons, movement systems, basic layout, that kind of thing. So when I think about an end product, I think about missions/scenarios, or at the very least different maps that heavily favor certain setups over others. Something to encourage (but ideally not force) players to experiment.

I'm not particularly interested in the on foot, out-of-mech aspect. For me, a game like this is about building and piloting awesome mechs, and I feel like adding an on-foot thing to it would just get in the way. The builder as it is now is streamlined and largely transparent, it's very intuitive and lets me get right to the fun part: coming up with and then implementing cool ideas.

So let me address this question to everyone. How do you think the game should fare when it comes to the builder vs the game? Would the emphasis on the game be more about building a mech and duking it out to best your opponents? Or would the game be about besting your opponents with a customized mech? It is Construction vs Destruction and I want everyone's opinion on it.

Part of why I like the mission/scenario approach is that it provides many opportunities for building new mechs while still keeping lots to do. If there's some kind of mission editor available to the public, even better. On top of that, missions mean text, text means stories, and I like stories.

I don't know if you're thinking about audio at all yet, but consider me interested in helping out when you get there.

[MirrorIrorriM]

Just updated to build 0.1.3! This build is mostly user suggestions and some graphical changes. All the user suggestions from before 3/15/12 SHOULD have gotten in. (assuming I said I would put them in of course) so if I missed someone, please speak up!

As always suggestions are greatly appreciated. If you wish to spark a discussion regarding anything about the game, even if you just want to talk about what YOU would like to see the game become, I am all ears.

[Inconspicularity]

Protip: Nobody uses an FoV under 70. NOBODY.

Some people are insane like me and use FoVs of 120, but up to 110 is the standard. 70 to 110 with 90 being default works in most places.

[MirrorIrorriM]

Heh, I don't really play very many competitive games, so I wouldn't actually know that. Thanks for pointing that out, I'll make the change in the code and have it updated next build.

[NineFourEightSeven]

I actually meant something different when I suggested the thing for turntables.
I meant making it keep sweeping back and forth along the arc as long as you hold the button.
For legs and stuff.

[MirrorIrorriM]

So while bashing my head into the wall thinking of what to do for the next build I came across a few ideas.

First off I know AI is important to add, but in all the programming I have done, I never really worked with much artificial intelligence and am kinda dreading making AI opponents. I might, MIGHT, make some simple AI enemies for this build. These enemies would probably be nothing more than turrets but nonetheless you would have something to shoot at.

Second I realized a greatly untapped potential for part generation. Weapons.

I playing mech combat earlier when I realized that mechs are designed using primitive pieces that you can put into almost any situation and have them perform, yet their weapons are very set in stone with little range for customization. Now why is that? Why must the mech be tailored to the gun and not vice versa? Should there just be hundreds of guns to fit every situation? That is when I realized that something as critical to a war machine as its guns ideally should not be simply generic parts selected from a list and slapped on a vehicle with little forethought. They should all be unique and tailored to a players desires to better fulfill whatever goal they need to fill. So basically, I have been pondering making a weapon customization system.

Now when I say weapon customization, I don't mean you place a gatling gun and change it to be your favorite color. I mean you place a "base weapon" and a window would pop up asking you questions (not literally, more like a stat window with you giving parameters). Questions like whether or not the shots are explosive, and if so how explosive? How many barrels does it have? Do the barrels spin, and if so how fast? What is the muzzle velocity? If multiple barrels, what formation? Do the barrel(s) slide back to decrease recoil on fire? Do the multiple barrels each fire their own shot, or do they just revolve to decrease overheat? How long is(are) the barrel(s)? What is the caliber of the shot(s) fired? Questions like that.

However, adding weapon customization isn't a minor feat to be taken lightly. Although it has potential to be a very good way to add firepower to a design, it does come with some flaws. Flaws which I as the developer mainly have to face.

I will now cover some advantages and cons to procedurally generated weapons.

Pros:
-Procedurally generated customizable weapons allow for deeper customization of mechs. Players would be able to fine tune their weapons to fit their needs.
-Procedurally generated weapons open new windows of opportunity for mech design and allow players to put weapons where they would not fit before. Allowing for more design styles.
-Programming 1 procedural weapon generation system is more efficient than programming 100 weapons.
-Programming a procedural weapon generator would allow for literally thousands of weapons.
-Weapons would be far less predictable and allow users to better surprise each other with their inventions.

Cons:
-Either requires an unholy amount of models and skins, or it would require a procedural mesh generator. Neither of which are fun to make/code.
-It would take a very long time to code and perfect.
-Balancing weapon stats would be extremely difficult and some combinations could easily have unfair advantages if I don't pay close enough attention to everyone's play-styles.
-Customizable weapons would drastically complicate the process of just slapping on a simple weapon for testing. (This could be solved by allowing users to save "presets" and also including a list of built in presets.)
-It would make weapons less "recognizable". You wouldn't be able to look at a weapon on the battlefield and instantly know exactly what it does which could lead to frustrating surprises.

A few other pros and cons exist but I can't think of them now. I would like to hear everyone's opinion on the customizable weapon idea. And if you have any ideas for enemies, that could be nice too.

Edit : forgot to reply to this comment.

I actually meant something different when I suggested the thing for turntables.
I meant making it keep sweeping back and forth along the arc as long as you hold the button.
For legs and stuff.

The reason I didn't add it was because it turned out to be surprisingly hard. After making the ability for a joint to return to 0 degrees after a delay, I was fed up with joints enough already and didn't feel like working on them anymore at the time. I remember saying that it would be a simple thing to add, but after looking into the physics joints, I realized just how hard it is to determine what angle it is currently at (I am using custom joints based off Unity's, not their directly). The only reason I got the 0 degree thing to work is I had a reference of what 0 degrees looked like (the rotation of your joints at start). Doing the same thing for a ping-pong system would be a lot of effort for a very specific task. But fear not! I have added it to my to-do list, so whenever I get a convenient time to add it to the joint system, I won't hesitate.

[Gilo000]

That weapon idea sounds brilliant. I'm totally for that one. Also, I was thinking, while turntable joints are pretty versatile as they are, is there any way of making a "ball and socket" joint with them?

[NineFourEightSeven]

Currently you can put a plate or block on top of the turntable, then place another turntable on the side.
Be sure to use the rounded corner block or it will drag and spaz out.

[MirrorIrorriM]

Currently you can put a plate or block on top of the turntable, then place another turntable on the side.
Be sure to use the rounded corner block or it will drag and spaz out.

Speaking of spazing out; that is what I am fixing currently. I managed to fix the problem of joints coming off of their base, but sadly the objects connected to joints are far harder to keep from coming out of their sockets.

[darkRenegade]

+1 fans.
First of all, let me say that this is incredible. I mean, I have never seen anything like this before. (Except in a roguelike, but roguelikes are turn-based, so that doesn't count.)
I will definitely be watching this in the near future.

I've been playing around with the builder, and I like pushing things to the limits. This is what I came up with.
(Spoilered for massive.)

show spoiler

hide spoiler

This is my mech. It fills up the entire floor, minus the last row.
It took about 1 minute to save, load, or enter the testing field.
It can move, but there are huge amounts of lag. I don't think multiplayer is possible with something this huge.


This is what happens when you try to shoot.
It doesn't render the trails, and I can only see the shots that shoot forwards. (I couldn't get a turntable under my brain, it just spun around like crazy.)


And finally, this is what happens when you try to move.
It's probably just that having 20 tracks moving at once creates huge momentum and pushes the front upwards.
Also, I can turn fine.

Overall, it was pretty good. I was able to play relatively well with a mech that fills the entire building area (laterally.)
There really isn't anything I dislike about the demo. It has a clean interface, (just a little hard to figure out the controls at first) and it really is fun to play around.
The only really bad thing about it is the lack of parts, and you've made it clear that you plan to fix this.
A suggestion I have about the idea to have player-made weapons: There could just be a couple models at first for guns. What I mean by this is have the player select a model for their weapon along with the other choices.
Also, being able to somehow resize blocks would be nice. just being able to change the height and width of the standard block would make larger creations easier to make, and you would have less parts to keep track of.

Sir MirrorIrorriM, you are a gentleman and a scholar, and you should be proud of having created such an ingenious game.
I hope to see more added to this, and you can add me to the list of people who are willing to help you out.

[MirrorIrorriM]

Just released a new build! This one features destroyable blocks, a massive improvement in the builder engine (not really easy to see in this version, but I did add a barrel object which was before impossible!), ricocheting bullets, and a few other more minor things. Since I still don't have AI yet (I know I know) You will have to build a chunk of blocks in front of your machine to test it. Currently how damage works is each block contributes a certain amount of health to the section it is attached to. So if you had ten blocks with 1 hp each, the entire thing would take 10 damage to destroy. If you shot a big cannon at it that did 25 damage, the entire section would be destroyed instantly. Each individual block, however, has its own hp. That way you cant just shoot one block and make the entire mech explode, you have to spread your fire! In the future when I add engines and other critical components this will become far more important.

So far only bullets cause damage to blocks, impacts and explosions do nothing to harm them. When I decide how I want explosions to damage blocks, I'll add it in. In the meantime suggestions are, as always, welcome.

[darkRenegade]

Awesome!
I didn't see this before because for some reason the forum didn't alert me to your post after I followed the thread.

I tried the block hp feature, and it works great. It just seems that the blocks have very small amounts of hp, but I guess that's just me.
I hope you haven't given up on your project because no one posted.

[w3vnzoom]

I'm downloading i love combat