Skip to Content
 

Textbased game? Lesser game mechanics

86 replies [Last post]
X3M
X3M's picture
Offline
Joined: 10/28/2013
I simplified the mechanic, everyone seems happy now

Health of units is no longer included.
Might apply this later on in a different way.

***

Units have a SSS, Self Supply System. Or Self Supply Storage. Either way, this starts on 100%. And each day, 10% upkeep is removed.

Once it reaches 0%. Upkeep is then removed from a saturation. This goes 2.5 times faster. Or 25% a day. And thus is empty after 4 days.

We get a total of 2 weeks before everything is empty.
Once entirely empty, the unit dies. Regardless of health.

In order to get the sss back up, you need to resupply the unit with the help of a supply truck or supply centre.

In order to get the saturation back up, you will need some sss. And upkeep is automatically removed twice from it.

If an unit dies by upkeep. 20% of its value is used to restock the sss of the rest of the force.

***

Ways that health can have influence.
Health low? You need more upkeep.
Health low? When dying by upkeep, only a portion of its value is reused to restock the sss.

***

What remains now is determining the sss value for those 10 days. Once new. It should start at 100%.
Probably it is 100% of its value as well. This can be changed of course if someone requests different values.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Update

We only use "rounds" in combat.
These "rounds" are only because an order issued is only received in intervals.

Everything else, is going to be in real time.

You order a force to go somewhere?
A round starts and takes 90 seconds.
During that round, upkeep is increased.

Personally, I think that a force should get orders for a prolonged time. Meaning that a player can.... here is an example:

A force is ordered to go to location A. The game returns an ETA. There it will guard a group of harvesters for a number of rounds. The number of rounds can be set by the player. 960 a day seems a nice round number.
And this number should be entered, right next to the order.
Maybe it is even better to have the player to simply enter a time.

Either way, the movement costs increased upkeep.
And the order for distracting any enemy from the harvesters, also costs increased upkeep.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Pre production balancing?

Made me decide that we have the following:

Sorry, vitality was too confusing for someone? We stick with Saturation.

Upkeep cost is 100% in 40 days.
This means that the SSS is 25% of its value.
The SSS and Saturation start at 100% for new units. Allowing players to increase the SSS and Saturation for the force through production.
(We might change this later for balance)

SSS is empty after 10 days. This equals 2.5% upkeep per day.
Saturation is empty after 4 days. This equals 10% upkeep in total.

In a sense, the total upkeep that is gifted through production. Is 35%.

When Saturation goes down. We might...not certain, add effects. Movement*Health and Damage go down. How exactly, not sure yet. But even walls should loose function.

An interesting strategy might occur.
Destroy the composite factories. And the composite walls loose upkeep. Wait 4 days, and voila. Of course, if you order your force to have composite walls for cover, the upkeep goes up for both the army and the composite walls. So, less days.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Revisiting the supplies again

Ok, Supply Truck should be the norm.
Costing 600 and having 1500 in storage. It is a mobile storage that can refill the SSS of units.

With the SSS of units being 25%. Or a 100% per 40 days.
1 Supply Truck can feed on itself for 100 days. Hmmmm, nice for a long term scout.

Riflemen is another mainstream for me. Costing 100, they cost 25 every 10 days. I guess that giving out supplies should be expressed in like per "time" as well. Having the Supply Truck being able to feed 30 to 50 of them should remain a norm for me.

50 riflemen cost 5,000. But 1,250 per 10 days. Or, in other words. 125 a day. 30 riflemen thus 75 a day.
Ok, if I express the Supplying into "a day". That would give a managable and understandable number. So, that 30 I once had, can be more. 75 sounds good. And 30 riflemen can thus survive 20 days longer on a Supply Truck.
Well, we already had something like a month in mind. Obviously, if you send 2 Supply Trucks, the ExtrA time doubles.

Keeping in mind, that the SSS is enough for 10 days. Only then the Saturation drops and who knows what happens in those 4 days. So, a Supply Truck having Supplying set to 75 can extend this by 20 days for 30 riflemen. Setting it to 30 days in total.

I could go deeper into the math.
The Supply Truck itself has 150 in SSS. This is 15 per day, that gets subtracted from that 75. Now we get to only 60 per day, for the rest. Or 24 riflemen?
Let's see, what options we get:

75 Supplying, 60 for 24 Riflemen, +20.0 days
90 Supplying, 75 for 30 Riflemen, +16.7 days
(Oh, previous times 3?)
120 Supplying, 105 for 42 Riflemen, +12.5 days
135 Supplying, 120 for 48 Riflemen, +11.1 days
150 Supplying, 135 for 54 Riflemen, +10.0 days
165 Supplying, 150 for 60 Riflemen, +9.1 days

I like working with nice round numbers.
The 75 option is still a valid option. Although the number isn't that high. We do have to keep in mind, each unit starts with a 10 days countdown. The Supplying is simply extra support. And 1 Truck does increase the time by a factor 3. And maybe, we should keep it this way.

2nd option looks a lot like the previous setting. But I am not that fond of that +16.7 Still, the time increasement is more than double. And the number of riflemen is also higher.

3rd option gives oddly enough, nice round numbers. Personally, I don't like a 7. But perhaps I should just ignore that. I already got 7's in other parts of the game.

4th options has that +11.1. The other numbers feel nice to me.

5th option has the same deal as the 4th. But then we have 54 Riflemen, perhaps that should be acceptable as well.

6th option and beyond is just not worth it to be honest. The supplying is soooooo fast, that the players will not understand the function of the unit.

Ok, that was 1 truck for a squad of X Riflemen.

I should make a choice.
We go for the 2nd option. And change later on if nessesary.

questccg
questccg's picture
Offline
Joined: 04/16/2011
Can you do something more ROUNDED and BALANCED like this...?

questccg wrote:
??? Supplying, 100 for 40 Riflemen, +??.? days.

Does that MATH not work?

I did the math as FOLLOWS:

105 / 42 = 2.5

100 / 40 = 2.5

They are the SAME. Could be better too in terms of BALANCE, no!?

These numbers may be more ROUNDED numbers as opposed to the data supplied.

IDK... I'm just proposing. I don't understand the MATH, so this is just an OBSERVATION!

Cheers @X3M.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Supply Truck + Riflemen

I could make the Supply Truck more durable. And make it cost 800. Then it would cost 20 Upkeep per day.

Picking the 120 Supplying power too.
Then we get to 120 - 20 = 100 Supplies for the 40 Riflemen.

If I keep the storage the same, it would then be +12.5 days.
It would also mean, that the factor between Supplying and Storage should be tweaked a bit. That way I can keep the 1500 Storage. We can go in all directions. But one thing is certain: If we change a factor, all units using that factor will change balance wise.

I need to change this first. Then I can continue designing more units (tweaking new numbers that is)

X3M
X3M's picture
Offline
Joined: 10/28/2013
Does this even make sense?

I have 2 infantry units that can produce and repair things.

An Engineer, can produce any structure. Can help repair vehicles.

An Mechanic, can produce vehicles. Can help repair any structure.

I forgot to include that they can also repair the things they make.

questccg
questccg's picture
Offline
Joined: 04/16/2011
Wow that's GREAT!

X3M wrote:
I could make the Supply Truck more durable. And make it cost 800. Then it would cost 20 Upkeep per day.

Picking the 120 Supplying power too.
Then we get to 120 - 20 = 100 Supplies for the 40 Riflemen.

If I keep the storage the same, it would then be +12.5 days.

That's what I was trying to express but I could not fully explain it since I was not fully aware of all the MATH involved. But YEAH that's what I meant!

Cool beans! That sounds AMAZING... That MATH seems to be more balanced and easier to process (ROUND NUMBERS)... 120/100/40/+12.5 days.

Very cool indeed.

questccg
questccg's picture
Offline
Joined: 04/16/2011
Man I LIKE that... Sounds GREAT for your game!

X3M wrote:
I have 2 infantry units that can produce and repair things.

An Engineer, can produce any structure. Can help repair vehicles.

An Mechanic, can produce vehicles. Can help repair any structure.

I forgot to include that they can also repair the things they make.

That also sounds COOL too! Hmm... Seems like this little game of yours will be very FUN! I like these units ... Very neat. And do you still have your Medic which can turn into a Field Hospital???

Of course that works differently than your Engineer and Mechanic... But none the less ... The Medic does something EXTRA too.

X3M
X3M's picture
Offline
Joined: 10/28/2013
questccg wrote:X3M wrote:I

questccg wrote:
X3M wrote:
I have 2 infantry units that can produce and repair things.

An Engineer, can produce any structure. Can help repair vehicles.

An Mechanic, can produce vehicles. Can help repair any structure.

I forgot to include that they can also repair the things they make.

That also sounds COOL too! Hmm... Seems like this little game of yours will be very FUN! I like these units ... Very neat. And do you still have your Medic which can turn into a Field Hospital???

Of course that works differently than your Engineer and Mechanic... But none the less ... The Medic does something EXTRA too.


The 2 infantry for building things, will be slightly nerved i think.

It doesn't make sense if they can produce 1 thing and only be able to repair the other. I was confused as of why i made the attributes red. Next time I need to add some context for myself.

The Field Medic that can turn into a Field Hospital is not implemented. We do that at a later stage when some testing has been done. Same goes for the Mortar Infantry. The normal Medic is still avaiable though.

Life and other hobbies took a lot of my time. It is only now that I return back to designing units and structures.
Still got a little list of things I want.

questccg
questccg's picture
Offline
Joined: 04/16/2011
All this WORK and ANALYSIS makes the game sound ...

SUPER KWEL! I don't know if the UPKEEP will detract players from getting into the game. Usually RTS don't have UPKEEP. Yeah there is a COST to produce but after that... You have HEALTH and NO UPKEEP for your units.

You can build UNITS based on how my SUPPLY DEPOTS you have to provide "Food" or "Supplies", meaning the MORE DEPOTS the more you can build in terms of units (in quantity).

That's the only bit of concern for me when it comes to YOUR game. UPKEEP forces players to THINK(?) about how to supply their armies. And UPKEEP makes it more challenging to keep track of the SSS to ensure army durability.

Don't get me wrong the SSS sounds cool too...

It's just that something like that requires more time to figure out when deciding what units you want for battle and how you choose to build them.

***

Humor me just a bit.

What if all this MATH and options were SIMPLIFIED "just a bit".

I know you are trying to have it all make sense. But UPKEEP is still a challenge to me and I think it will "RUIN" the game. Again this is ONLY MY OPINION... It's YOUR game, so do as you feel necessary. But...

What if instead of having SUPPLY TRUCKS and VEHICLES... You TRAIN your Riflemen and you supply them with enough SSS for "X" Days.

AFTER "X" Days expires... Instead of KILLING those units, they simply RETURN to your NEAREST "Supply Depot" and automatically RE-SUPPLY their SSS to 100% and a have yet again "X" Days to go out there.

Since this is like OGAME ... Your units just disappear when SSS reaches 0%.

***

Why do I propose this IDEA??? Well it's a bit BORING to REQUIRE you to BUILD SUPPLY TRUCKS and VEHICLE which can get destroyed in-battle when in REALITY what you want is a LIMITED lifetime of the unit given the SSS values. But WHY kill the unit??? Why not just RETREAT to the NEAREST "SUPPLY DEPOT".

This makes it more EXCITING and less of a concern because of UPKEEP. Sure eventually all UNITS get 0% SSS and need to RETREAT. But none of them DIE unless HEALTH reaches 0%.

***

Think about it. Maybe you like, maybe you don't. But this is more of REALITY than just UPKEEP and SSS. Why? Because if a TANK needs more SSS what will it do in REALITY??? Pull away from the Front Lines and go back to get RE-SUPPLIED and then return to the Front Lines when it's BACK to 100%.

Obviously this is not always TRUE. In some cases the SOLDIERS ABANDON the vehicles and flee for their OWN survival.

And while that is true, I would simplify this too:

questccg wrote:
When ANY Unit reaches 0% SSS, it returns to the NEAREST "Supply Depot" to get it's SSS back to 100%.

This means that you DON'T have to build "Supply Trucks" or "Air Supply", all you need is the "Supply Depot". And you could build them closer to the enemy or the Front Lines (as you see fit).

IDK if you will like this. Probably NOT! But I'm just proposing this as something to THINK(!) about.

Cheers @X3M!

X3M
X3M's picture
Offline
Joined: 10/28/2013
That would be a simpler idea, indeed

We are aiming for a game where players need to see the opponents weakness. And aim for that.

Supplies is just one of many.

But I agree on that certain things need to be simplified. I think we are going to cut when we are testing.

Another thing I am keeping my eye on for cutting. Is the propulsions. While I added ATV to the list. I don't think that the differences matter much.

Example:
One propulsion has a factor of 0,6 on going over sand.
Another propulsion has a factor of 0,5 going over that same sand.

How does it work? A movement speed of 5 will be reduced to either 3 or 2.5.
If a distance is 300. Then the time needed to cross is then either 100 or 120 minutes. It doesn't matter much. Not even when going into combat and you close in the TD. Because when both are in range, they fight. It only matters when one is a micro unit. And that is so rare. It depends sooo much on my design capabilities. That I think it doesn't matter at all.

I need to increase the differences. Or add terrain types.

questccg
questccg's picture
Offline
Joined: 04/16/2011
And I would NOT propose this... UNLESS

It makes sense for your OGAME-Like Video Game. Why? Because it's not a classical RTS with "Real-Time" Units moving around. In this scenario it would be a bit STRANGE if all of a sudden your SSS reached 0% and all your TANKS just all of a sudden DISAPPEARED.

But YOUR game is like OGAME, right?

So you don't see the units ACTUALLY moving around. Is my understanding of OGAME correct???

If this is TRUE, making the units that get 0% SSS re-appear to the NEAREST "Supply Depot" kind of makes them pull out of BATTLE ... But they're not GONE forever. They get re-stocked and can REJOIN the Front Lines as soon as they are ready to go.

Anyhow this is just one POV. Do with this idea as you see fit. I just wanted to offer something which could SIMPLIFY UPKEEP (while having SSS and days to battle), they simply RETREAT to get re-supplied.

***

This means that the PLAYERS need to worry LESS about UPKEEP and FOCUS on the TIME TO BATTLE (+12.0 Days or example). It's much easier to focus on ONE VARIABLE at a time, rather than requiring to focus on several ones to be used for CALCULATIONS.

You HAVE UPKEEP, SSS, Days, etc.

But your players only need to focus on DAYS to battle.

That ONE (1) Variable makes it more CLEAN to be understood by the players and behind the scenes the CALCULATIONS are a bit more difficult. But it's OK you have simplified the Tracking for the PLAYERS to 2 VARIABLES: Health and TTB (Time to Battle).

Something like that for you to consider...

X3M
X3M's picture
Offline
Joined: 10/28/2013
Not really

The game is different than Ogame.

Ogame is 1 dimensional. And you only have a timer before arriving somewhere. Also, the location you go to has to have a player. The fleet can be infinitely big. The only limit is the number of fleets. Traveling costs 1 resource.

We have a 2 dimensional plan. Of course we can use a timer too. But now it will be an ETA. And you can go anywhere with a force. But the thing is, a player is limited in the size of a force on top of the number of forces. There will be intercepting too. Traveling can costs multiple resources.

As for when units run out of SSS. We got this covered ;)

questccg
questccg's picture
Offline
Joined: 04/16/2011
Days and recruit times

questccg wrote:
...But your players only need to focus on DAYS to battle.

That ONE (1) Variable makes it more CLEAN to be understood by the players and behind the scenes the CALCULATIONS are a bit more difficult. But it's OK you have simplified the Tracking for the PLAYERS to 2 VARIABLES: Health and TTB (Time to Battle)...

Then you could EASILY explore HOW(?) to make more "resistant" or "durable" units like "Marines" instead of "Riflemen".

Riflemen has 120/100/40/+12.0 days, Marines has 100/100/40/+15.0 days.

Meaning that "Marines" have a strong duration in terms of Combat Days that the normal "Riflemen". They have more "resilience". But the TIME TO TRAIN is like 1.2x the normal "Riflemen" which is 1.0x...

There are a LOT of variables you can play with that are all abstracted. But I think you get my point:

A> You can create units based on "Battle Time" (BT) and there can be levels:
1.0x, 1.2x, 1.5x (3 different kind of "Riflemen") with different Battle Time. Where the levels = Time to train/recruit).

B> This could help you create a PLETHORA of Units just with some MINOR tweaks to the Unit's STATS and recruit time.

***

Again these are just some ideas to help you along with your design. Some are BUILD TIME STATS; others are BATTLE TIME STATS.

I'm sure you've already got something like this. But I'm including it because I just wanted to explain further how you can focus on SIMPLICITY for the Gamer and still have the VARIABLE SET you plan on using.

Cheers.

questccg
questccg's picture
Offline
Joined: 04/16/2011
For sake of completeness

X3M wrote:
The game is different than Ogame...

...As for when units run out of SSS. We got this covered ;)

Good to know. Like I said, I shared some OTHER ideas because you like STATS and I figured if I'd throw at you some MORE STATS... You might have already thought of them before my post. Like I said, I just posted for "completeness". That was the end of my train of thought concerning SSS, Unit Counts and Days you supplied in the earlier post.

Keep us posted about how the DESIGN evolves!

X3M
X3M's picture
Offline
Joined: 10/28/2013
Convergence

While I didn't read the last 2 posts. I just so happened to think of having differences for the SSS per units as well.

I could even add units that hardly have any SSS.

But how to do it "fair"? By default, all have an SSS that is 25% of their value. If I want to give them more, they also want to start to share. Just like the Supply Truck. The Supply Truck in theory, has +100 days for itself.

Allowing less is even more troublesome.

I think I know of a way. But I will only look into it after we did some testing. Then I could apply a factor that is similar to Sizes. Units that rely more heavily on Suppliers would cost less. Units that rely less on Suppliers will be more expensive.

***

As for the propulsion systems:
Structure
Wstructure
SubMersible
SubTerrain
Legged
Wheeled
Tracked
Climber
ATV
Naval
Amphibious
Hoover
Air

They all got different movement speeds on the following terrain types:
Plains/Grass
Sand/Dunes
Forest
Snow(s)
Ice
Mountain
Water

I rather see this more simplified. Because that will increase the differences. It should be made such, that players make a valid choice for when dealing with certain terrain.

Not sure how, yet.
But as said before, 0,5 or 0,6 hardly makes a difference. Especially in combat. This is simply due to the fact on how the combat mechanics work.

In theory, we should have situations where long ranged units have no problems, or have difficulty hitting their targets.
And then to increase the RPS effect, the target has an easy time or hard time, even reaching the long ranged unit.

The player that approaches should make a clear choice in which units to choose. And the player with the long ranged unit should have picked the right units that can easily fire in that terrain.

For the projectiles, it was a bit easier and clearer for me:
Normal
Air to Air
Anti-Air
Torpedo
MineSweep
Res.Swap (ignore)
Artillery
Spray

I will come back to this later.

X3M
X3M's picture
Offline
Joined: 10/28/2013
I asked the AI again

Seems that the AI grinded propulsion factors down to 0, 0.33, 0.5, 0.67 and 1.0.

0.16 and 0.83 seems to be missing. That is ok.
I asked to have steps of 0.1 to be increased. And initially, the AI went for 0, 0.5, 0.75, 1 and 1.5. Well.... that is an interesting way. But yeah, I should have considered having the common divider being less than 10.

As for projectiles. I don't mind much. It didn't include air. It ignored the resources-swap as instructed (also "air"). But it also forgot to include a minesweep.

The most interesting comment the AI made was that the ATV is going to be a middle ground. And has reduced movement everywhere. If the AI is based on what humanity thinks. Then humanity considers plains to be smooth? Since Wheels would get maximum movement on plains. O well, I should put its findings in the same table. But.... I will put both tables side by side, so I can see the differences between the AI and myself. I think....that this particular AI has more common sense.

questccg
questccg's picture
Offline
Joined: 04/16/2011
AI is very "unreliable". Don't bash on me... Let me explain!

While AI is useful ... You MUST proof "everything" it does. Why? Because just like MidJourney making people waving with six (6) Fingers, OpenAI (Copilot, Gemini, Claude, et. al.) all take certain liberties with HOW(?) they respond to a prompt. One of the clearest examples is that AI never returns the SAME result. And so when you ask it to write a Conclusion and then ask it TO EDIT it... The end result is often VERY DIFFERENT than the initial Conclusion which just needed some minor fixing.

So those are two (2) KEY issues:

1> Takes liberties that make for illogical results.

2> Never responds the same way to the identical prompt.

Same goes with EDITING. Sure you can ASK AI to edit itself and it may do a better job... But like I explained with Point #2, it will probably just RE-WRITE what it had previously responded with.

***

I've watched a guy online ASKING for ChatGPT to count to 200. And believe it or not, ChatGPT CANNOT count to 200. It gets lost and counts the wrong numbers, etc. etc.

But at the same time I cannot complain about HOW(?) AI took my Kickstarter Page for Dual Dice 2.0 and transformed into "the bones" of a SOLID Guidebook for the dice. I was going to HATE that task and AI made it very easy. Yes it took a whole 2 minutes to pump out the results. But it took me 4-Hours to EDIT what it had written since it did NOT include Chart Data as I was using the FREE Version. 4-Hours vs. 2-Weeks of effort... Miraculous.

Now I need to TRANSLATE to French. The GOOD NEWS is that it'll take me like 2-Days to do that. Because the vernacular that Gemini uses is sometimes too "French" and not sufficiently "Quebecois". So I need to get options and mix-and-match the options to get something reasonable in the end.

In any event. AI is helpful. But you've got to be on TOP of those "liberties" and FIX THEM YOURSELF. You're probably better off with the AI as a person trying to write a document or asking for some ideas given some input... But you'll need to be sure that you correct the errors that AI makes because TRUST ME: AI MAKES MISTAKES!

Enough said! Cheers all.

Note #1: Also what CAN matter is PAID vs. FREE Editions. For things like CODING or HOW TOs, a PAID Subscription can yield BETTER results. IDK why this is like that... But I made an experiment with FREE Versions of SEVERAL AIs and they all gave me a VERY SIMILAR CODE result. When I implemented that CODE... It DID NOT WORK! So I asked a Friend who has a PAID account because the company he WORKS FOR ... Uses AI. And within a hour, he had a RESPONSE that worked while my FREE Results did not work even with 4-Hours of time invested by myself to TRY to get it to work.

What does this mean? Simple. AI is very "unreliable".

And if you PAY the AI may be trained on different sets of Data and have different ANSWERS based on FREE vs. PAID Editions. If you don't believe that PAID vs. FREE is an issue, You simply need to experiment and with both and you can try to get snippets for code in both versions... And you might get completely DIFFERENT results.

Note #2: And believe me... I'm good at "Hacking code". Like I said I spent 4-Hours with the AI's solution and could NEVER get it to work. My Ex-Boss took him 20 minutes with a Paid Subscription to Microsoft's Copilot and had a working solution. He sent me HIS code and I tried it and it worked.

That's a bit infuriating: you spend 4-Hours TRYING to get a snippet of code to work and all AIs (FREE Editions) agree that the code is CORRECT. And you waste 4-Hours thinking eventually it WILL WORK. But it does NOT...

I'd rather google Forums to get similar answers than trust AI which produces a false-positive result. And what's more is that SEVERAL AIs gave me the SAME (almost identical solution) which NEVER worked. Waste of time and total frustration because in the END... Nothing came of my AI code.

Note #3: And if you are CURIOUS about WHAT I was trying to do ... Let me explain.

Basically I asked the AI to produce CODE to open a Mobile App in LANDSCAPE MODE versus PORTRAIT MODE. Not as an option to rotate... I WANTED the APP TO DISPLAY in LANDSCAPE MODE ONLY. That's all I wanted to TEST. Simple, right??? Well not for the 4-Hours of wasted time on two (2) different sets of code, one had me edit a PROPERTIES document and specify "LANDSCAPE" and another code snippet had me LOAD into "LANDSCAPE" mode. Neither worked. FYI.

Like I said, I was NOT asking the WORLD. Just how to LOCK and LOAD into "LANDSCAPE" mode on a Mobile Android Phone App. Heh.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Meanwhile

We played Factorio...

We clearly are bothered by the 20% or 40% increase in movement speed while running. It doesn't matter much.
I often also didn't notice if I used 100% or 150% laser power (8 or 12 personal lasers). The boost was simply too little to make a real choice.

Hence I decided that we should have some harder factors.
The AI was using a set of 6. Meaning that the factors where 1/6, 2/6, etc.
I decided to check tomorrow if I can make my own table again. (I saved a copy). And then change all "odd" fractions (0.1, 0.3 etc.) into even ones. Small adjustments. Oh, the "even" fractions are 0, 0.2, 0.4 etc.

Also, the AI didn't include the properties of certain terrain. For example, Ice.... This will be a layer on top of water. This water is deep enough for a submarine. And strong enough for a huge tank on top. The extra property that this terrain gives would be that if the submarine has a weapon effective for land units. It simply can shoot them from below. Period. We need to have something special here.

Also, if the ice breaks...it immediately freezes over. Special planet property is the excuse. :)

X3M
X3M's picture
Offline
Joined: 10/28/2013
Keep an eye on the mechanics

It didn't feel right when I was observing the propulsion systems (Legged included, what is the correct word, if it is not propulsion?).

I considered that they all had a basic maximum movement somewhere. And the rest is by choice. Thus +50% on whatever the unit could do. This lead to slightly imbalances. Like for example.... 0 placement possible is still a factor 0.5. Yeah, no, lets remove that. Because it is unfair.

I also considered giving certain terrain types a heavier weight, based on how well movement would take place. Let's, not consider this for now. Because the next explanation is more complicated.

The factor given to a propulsion system for on a certain terrain type. Is also given to structures.
A side effect would be that the squad moving through a certain terrain type. Would slow down by that same factor...?
I do remember having a basic factor for placement. And a factor for the actual movement at the beginning. But the mechanics kinda changed over time and it got removed asap.
I think, this one needs to return first. Which will make things more complicated. It isn't like the projectiles. Where the factor is simply a hard accuracy change.

No, we need a placement AND movement factor. If we want the movement to be changed as well.

3 options for me now:
1. I balance each propulsion, including the stationairy/immobile. Into the same factor.
2. I only balance the stationairy/immobile into the same factor as the "default" propulsion (which is probably tracked).
3. I separate the 2, but will face a change in the factor. But perhaps it is a good thing. I could include that moving objects can go over ice. But stationairy cannot. But this overcomplicate things.

***

I need to think about it for now.

questccg
questccg's picture
Offline
Joined: 04/16/2011
Another term...

X3M wrote:
It didn't feel right when I was observing the propulsion systems (Legged included, what is the correct word, if it is not propulsion?)...

Is "Mobility". If you don't like "Movement". When units are READY, they can "mobilize" and are ready to be moved to a destination.

That's all I got for now.

If you don't like this term, that's perfectly acceptable. I just wanted to offer you an alternative to "Propulsion" which is generally for units that have some kind of MOTOR or are MOTORIZED (the act of driving, flying, etc. etc.)

Kind regards.

Note #1: "Mobility" comes from the "Act of Moving". So basically it is applicable to ANYTHING that can "Move". But TBH I (personally) think "Movement" is the more UNIVERSAL term for "Moving". No fanciness just plain facts.

X3M
X3M's picture
Offline
Joined: 10/28/2013
Mobility

It is then.

X3M
X3M's picture
Offline
Joined: 10/28/2013
We had a 1 minute talk.

And after I had a 1 hour brainstorm.

I am overcomplicating things.

What I need to think of now is how to see things.

Mobility has influence on the unit size.
0 means the size being divided by 0. Aka, it doesn't fit in the next terrain type. Also, the movement multiplied by 0 means it cannot move there.

The weight is a hard factor in the formula.
2 is times 2, 3 is times 3 etc.

But if mobility also has influence on the unit movement speed. How to calculate this then? Using the same weight factor on the movement speed?

What I get is this:

WFM = Weight Factor Mobility
S = (Movement) Speed
DH = Default Health (aka 0 Movement Speed or 0 S), always 8
MW = Mobility Weight

MW = WFM * (DH + S * WFM) / DH
MW = WFM * (8 + S * WFM) / 8

Tracked could get:
WFM = 1, S = 1
MW = 1 * (8 + 1 * 1) / 8 = 1.125

Tracked could get:
WFM = 1, S = 2
MW = 1 * (8 + 2 * 1) / 8 = 1.25

Air could get:
WFM = 2, S = 1
MW = 2 * (8 + 1 * 2) / 8 = 2.5

Air could get:
WFM = 2, S = 2
MW = 2 * (8 + 2 * 2) / 8 = 3

Tracked gets +0.125 per S
Air gets +0.5 per S, that is 4 times as much?
I don't know yet if this is correct.

1 thing is certain. Air can go everywhere. And move at a maximum speed anywhere as well.

I need a more practical example for myself.
A tracked unit with 12 S has the same MW of 2.5 as an air unit with 1 S.
The air unit can move over water and mountains. The tracked unit cannot.
The tracked unit also has a penalty factor of 0.6 or 0.4 for some other terrain types. Even 0.2 for swamps at the current design.

0.6 means the size would be 167% and the movement speed is then 7.2.
0.4 means the size would be 250% and the movement speed is then 4.8.
0.2 means the size would be 500% and the movement speed is then 2.4.

The movement speed has an awesome reduction here. Although, a tank moving with 12 over plains is weird.
Ah yes, this 12 is synonym to 27 miles per hour. I think that it should be faster too. Since this is supposed to be on "pavement".
Then again, it is just a game. Balance has priority on realism.

Speaking of realism. An air unit that has a movement speed of 12 (like in RTS games). Would now have the weight factor of:
WFM = 2, S = 12
MW = 2 * (8 + 2 * 12) / 8 = 8

Oddly disturbing. No wonder most RTS games have super weak air units or super slow.... yes, super slow air units.

Although, they don't work with sizes. And perhaps.... I should NOT include size factors for terrain then? Simply say that an unit cannot move into it?

This would mean that I removed the "mobility" from structures. Or....I make a separate table for Size factors for certain terrain types... Yikes...

X3M
X3M's picture
Offline
Joined: 10/28/2013
O noes

I found a loophole.

Tracked has a WFM of 1.
Air has a WFM of 2.
And we will test a rebalanced air that gets WFM of 1. This rebalanced air has always a double size. And the given movement is always cut in 2.

If Tracked has a movement of S 2. MW will be 1.25
If Air has a movement of S 2. MW will be 3.
If we want MW of 3 for tracked, the movement will be S 16. We also get this S 16 for the rebalanced air. But in a sense, it is always S 8 due to that 0.5 for all terrain.

Now then, if we want the size to be less. The MW has to be 1.5. And this rebalanced air would get S 8, or readjusted, S 4.

S 4 is still twice that of the normal air.
While the cost is half. And the size is equal.

In other words, an imbalanced calculation!

X3M
X3M's picture
Offline
Joined: 10/28/2013
Right! What is left?

Decided to take some steps backwards first.

Cutting in how terrain has influence on mobility and projectiles.

Keeping it super simple now? Let's observe mobility for this.

The terrain and thus mobility and projectile attributes come in duo's:
Ground/Water
Free/Obstruction
Hard/Soft
Flat/Elevated

One of the 2 attributes for mobility is always 100%. From all 4 duo's, we have 100%. The other one can be added as a choice. And thus will add at most 50% for each.

Air units have 100% on all. And thus end up with 100% + 4 times 50% = 300%.
However, I am planning to have a 150% as default. And recalculated to 100%, this means that air will be 200% instead of 300%.

As for terrain, they divide the 100% per duo.

Elevated and Obstruction are similar. However, most units can move through elevated to some extend. While others have it better through obstructed terrain.

With obstruction, think of tree's and rocks etc.
With elevated, think of hills and...waves etc.

Yes, we are going to have 2 types of ships eventually. 1 that can only go through calm waters. And 1 that can take the roughest sea.

Still need to set up a new table and see the results.

As for comparing mobility to the terrain attributes?
Not sure yet what the best way is.

***

As for the weight factor of mobility. I still want to include structures, despite them having no movement speed. And one particular braincell just announced we had an idea for reduced movement speed. But I never noted it anywhere? (I guess we where both drinking that evening)

And I think Questccg kinda suggested something similar on Discord(?)

The effect we get from the attributes will make the "size" of objects bigger/smaller for particular terrain types. Then, if the total force is too big for the avaiable space, the minimal movement of the slowest unit will now be reduced.

How?
Most logical would be that we have a buffer of no problems.
Then, if the size of the force exceeds the space. It gets too crowded.
Perhaps, we allow a second buffer that allows the space to be crowded. And the percentage here, will reduce the movement by that same percentage. Thus, if we have 100% crowded, then all movement stops within that space. Obviously, we can still move to another region. For that, we should take both regions for the space, and take an average reduction for the movement.

Yeah, that makes sense, right?

Region 1 has 100% crowded. Thus no movement possible anymore.
Region 2 has 50% crowded. 50% movement is possible there.
If we go from 1 to 2, then the average is 75% crowded. Thus the movement is now 25%. This doesn't change during the migration either. Since -10% for one crowded is +10% for another. Unless....the 2 terrains have different attributes. Ok, so each tick should be reconsidered.

If region 1 goes to an empty region. The average crowded is 50%. This is 50% movement now. But, since the crowded weight only goes up after the buffer of space is filled. It means the migration goes faster and faster. Overall, an average of 75% is possible when you cut a force in half.
Then again, if you move all of them to the next region?

200% and 0% is an average of 100%. Ok, that is then 0% crowded. We have to be carefull how we set up this mechanic. If we want it to be fair and logical.

As for structures, they will receive the weight factor as well. Because this will determine their size in certain territories. And also the space that is being filled.

Obviously, if there is no room. A structure cannot be placed. Thus division by 0 would trigger such an event.
Obviously, if you have a base that makes things 100% crowded. You cannot move into this terrain anymore...

Ah yes, we should not take the crowded factor of a terrain where we move out of. But only the ones we move into.
So, from a 100% crowded terrain, going into open terrain. Is a 100% movement then.

I need to think more on this.

Syndicate content


forum | by Dr. Radut