D2TM Progress

[MrFlibble]

Yay! :D Congrats, Stefan! ;D

[stefanhendriks]

College starts today. I have made some changes yesterday though. Improvements here and there. I've broken the INI loading stuff, but I want to rewrite it anyway (the code is horrible).

I will finish the lists , so upgrading works and the evolving of the const yard list works as well. After that, INI loading is the next thing to do.

All in all it looks like it is going to be better and better. I am quite satisfied by seperating all the logic, even though it looks like there are a dozen more source files.

[Skrilax_CZ]

Do you know C&C 3? When you are playing with the sidebar, is it possible to have that multiple queues for the same type of units if you build multiple production buildings? Like two queues for tanks with two heavy factories etc.

Oh an in the DEMO 4 I believe there is a bug in the sidebar with Soldier and Infantry. I believe that it is "Soldier" (1 man) and Infantry "3 man". Also the soldier (1-man) icon was different ...

And with the Fremen, keep in mind that in skirmish when more players will be allowed and two of them will have atreides they will need to recognise the allied fremen from the enemy ones.

Also noticed Harverster cannot be sent to refinery manually and it's unloading is faster than the credits income seen in the bar.

Anyway excellent job.

[X3M]

Will the next version have a proper unit editor? This way a lot of people could give feedback on the balance.

[stefanhendriks]

Oh an in the DEMO 4 I believe there is a bug in the sidebar with Soldier and Infantry. I believe that it is "Soldier" (1 man) and Infantry "3 man". Also the soldier (1-man) icon was different ...

Yep, good find. It is fixed in the next version.

Will the next version have a proper unit editor? This way a lot of people could give feedback on the balance.

What do you mean with a proper unit editor? How can it improve feedback? (can you elaborate?)

[MrFlibble]

What do you mean with a proper unit editor? How can it improve feedback?

I suppose the players will be able to modify unit stats more easily, and thus experiment with the balance, thus helping to improve it.

[lord vernius of ix]

In my opinion, I think it's fairly easy to modify the units characteristics as it is. the system is plainly explained in the config file, and I edit it to my will already with ease. But, thats just one persons preference

[X3M]

I suppose the players will be able to modify unit stats more easily, and thus experiment with the balance, thus helping to improve it.

Yes, indeed, i am one of those players. But the game.ini file from D2TM-DEMO4 doesn't give all the data that's required for proper balancing. For example, i am missing out the damages done by units, which is the most important value. And further more, i don't even know if Stefan's version is based on 2 unit types (infantry/tanks), 3 unit types (infantry/vehicles/tanks) or even more.

Old Blizzard games can be open in unit types if you divide them into different classes of armor. (0, 24, 48, etc.) Resulting in C&C styled games.

Westwoord/ea games are fixed in this matter with percentages per weapon. (50%, 60%, 90%, 30% etc.)

Open sources like D2TM-DEMO4 has all possibilities?

I would like to know, ALL possible stats for every unit/structure in D2TM-DEMO4. So this way i know what i am allowed to change and go full force on the data. Can someone help me with giving me the full list of options?

Or should i just created my own list of options, resulting in Stefan changing the script?

I don't think that you want to change the script Stefan ;)

[stefanhendriks]

Just to give you an idea what properties are assigned to Units:

this is taken from the common.cpp

  units[i].bmp              = (BITMAP *)gfxdata[UNIT_QUAD].dat; // in case an invalid unit is choosen, it is a quad! :D
    units[i].top              = NULL;  // no top
    units[i].shadow           = NULL;  // no shadow (deliverd with picture itself)
    units[i].bmp_width        = 0;
    units[i].bmp_height       = 0;
    units[i].turnspeed        = 0;
    units[i].speed            = 0;
    units[i].icon             = -1;
    units[i].hp               = -1;
    units[i].bullets          = -1;
    units[i].attack_frequency = -1;
    units[i].build_time       = -1;
    units[i].airborn          = false;
    units[i].infantry         = false;
    units[i].free_roam        = false;
    units[i].second_shot      = false;
    units[i].squish           = true;     // most units can squish
    units[i].range            = -1;
    units[i].sight            = -1;

    // harvester properties
    units[i].harvesting_amount= 0;
    units[i].harvesting_speed = 0;
    units[i].credit_capacity  = 0;

    strcpy(units[i].name, "0");

and bullets:

    bullets[i].bmp = NULL; // in case an invalid bitmap; default is a small rocket
    bullets[i].deadbmp = NULL; // in case an invalid bitmap; default is a small rocket
    bullets[i].damage = 0;      // damage to vehicles
    bullets[i].damage_inf = 0;  // damage to infantry
    bullets[i].max_frames = 1;  // 1 frame animation
    bullets[i].max_deadframes = 4; // 4 frame animation
    bullets[i].bmp_width = 8*2;
    bullets[i].sound = -1;    // no sound

and structures:

    structures[i].bmp = (BITMAP *)gfxdata[BUILD_WINDTRAP].dat; // in case an invalid bitmap, we are a windtrap
	structures[i].shadow = NULL; // in case an invalid bitmap, we are a windtrap
    structures[i].sight = 1;
    structures[i].bmp_width = 32*2;
    structures[i].bmp_height = 32*2;
    structures[i].sight = 5;
    structures[i].hp = 1; // low health
	structures[i].fixhp = -1; // no fixing hp yet
    structures[i].fadecol = -1;
    structures[i].fademax = -1;
    structures[i].power_drain = 0;       // the power that this building drains...
    structures[i].power_give = 0;        // the power that this building gives...
    structures[i].cost = 0;
    structures[i].icon = -1; // stupid default icon
    structures[i].build_time = 0;
    structures[i].list = -1; // no list attached
    strcpy(structures[i].name,   "Unknown");

[X3M]

For other forummembers: I asked Stefan if i could help him balancing the game. He accepted, so i got work to do. Perhaps the discussions that will follow now, needs a sepperate thread? Of course it's up to him to decide.

Now for the questioning. This common.cpp, is it part of the programm itself? Can't find it in the demo as an ini file. By watching this information, I still don't understand everything. How does an unit know, which weapon to use? What are the choices of weapons? It would be more handy for me if you could email me the complete list of all units/weapons/structures and how the damage calculation takes place. It's obvious that this will be different then C&C tib wars, where range is included in the weapon itself instead of the unit.

Now for balancing. I know that i have to get the weapons seperated from the units themselves. Saying that an unit is infantry or not, is good. Saying that an unit is airborn or not, is good. Saying that a unit can squish or not, is good. Now i understand why the vehicles are so weak in comparison. It's a basic "the bigger, the better" prinicple with the infantry as exception.

And that there are only 2 weapon types possible: "Anti Infantry"/"Anti everything else". Not a big prob for me (yet). Yet i can't tell from this info how many different weapons you are allowing. Is it possible for me to ask you to create additional weapons when needed? And is it also possible to divide the "anti everything else" into light and heavy armored types? This way you simply don't have to relay on reducing the hp for "vehicles" and "support units". I simply could say that a quad is a vehicle and gets less damage from the rocket launcher then tanks. This also would mean that a quad could get even with troopers. Which is a common fact in C&C and great balancing material.

Anyway, i already had written explanations and suggestions in dutch for Stefan for about 9 pages long. But with the info given here i can rewrite 6 pages. No worries, that's normal work for a balancer ;). It's not a script but more of a rulebook to start with.

[stefanhendriks]

A different thread would be handy, I suggest you create a new one.

As for the common.cpp file, it is a piece of source code. You can grab it by using a SVN (Subversion) client to download the source code. You can find the source at http://code.google.com/p/dune2themaker/

Even without compiling the source code you can get an idea what is possible.

However, do not let your imagination be restricted by the source code. I'd say write your wanted situation. The source code can be adjusted to do what it is supposed to do :)

[stefanhendriks]

Now I am graduated, I can take my time and work on D2TM more often. And I will. I will try to work atleast one evening a week on it, perhaps even more ;)

If you somehow watch the SVN log, you'll see I have just committed a few things again. I'll take small steps.

My goal for the next version is deliver a version that has many rewritten parts under the hood. So , as a player, you might not notice differences (except the fact that you can use super weapons and have queuing within the sidebar), but under the hood things have changed greatly.

[stefanhendriks]

A lot of time has passed since this thread was created (over a year). Some things have changed:

- the sidebar queuing works now

- upgrade mechanism is rewritten

- money drain is westwood style (ie, you can always build item)

Since i'm rewriting, some things are broken now:

- starport functionality is broken

[stefanhendriks]

Today I've been working on the broken Starport. I have rewritten everything of the starport. The nice thing with this, is that all logic is in one place (opposed to the DEMO 4 (and older) approach where the AI has its own logic.. meaning duplicate code).

With the new code I can easily apply AI code and let it work with the same rules as the player would (so no cheating).

The Starport functionality has been restored. With that, i have eliminated a cheat. You can no longer get a higher (or lower) refund than the unit had cost before.

Also, I have capped the starport capacity to 8 units. I am not sure yet what the best maximum is, so this might change in the future. Perhaps it is even nice to expand the capacity with the amount of starports you have?

Speaking of amount of starports, this has also been fixed. Using multiple starports will give you the advantage to deploy units where you want (using the primary building flag). If such a flag is not set, then the first available (meaning, a starport which has some space to let units be deployed) will be taken. When none are having such space, the first will be used anyway (where carryall's will drop the units).

So, next things on my list are:

- make carryall smarter when dropping units (ie, no longer randomly roaming, but find in a radius an available drop cell)

- fix some bugs with the harvester

- fix a 'cancel action' when placing a structure (causing a crash)

- and so much more ;)

Oh, when I am ready rewriting all parts (so I have restored the functionality to at least DEMO 4) I am searching for people who want to beta test the new version. Any volunteers?

[X3M]

Also, I have capped the starport capacity to 8 units. I am not sure yet what the best maximum is, so this might change in the future. Perhaps it is even nice to expand the capacity with the amount of starports you have?

Oh, when I am ready rewriting all parts (so I have restored the functionality to at least DEMO 4) I am searching for people who want to beta test the new version. Any volunteers?

Perhaps usefull:

The original had a capacity of 6 units, and in dune 2000 they kept it on 6 due to balancing i guess. 8 is fine as well, but hardcore fans wanna see 6 :D. If you are going to increase the capacity with additional starports, just add 2 or 3 per starport. Or just as much as 2 factories increase the production rate.

How much faster gets a unit produced with 1 extra factory? Use this percentage for the starports for increasing the ammount of units.

Examples:

2 Factories produce 50% faster, Starport gives 6, then 9, then 12 etc.

2 Factories produce only 33% faster, Starport gives 6, then 8, then 10 etc.

Anyway, do not shorten the time for delivery :) but that would be logic.

Me volunteer for beta testing, although i use pen and paper to take note.

PS. You got my email? Perhaps we can discus the different balancing issues via MSN.

[MrFlibble]

The original had a capacity of 6 units, and in dune 2000 they kept it on 6 due to balancing i guess.

I'm positive you can order more than 6 units at a time via Starport in Dune II. I think it's about 8 units per unit type - I can clearly remember buying 8 trikes and 7 quads in a single purchase (this was a test mission, so I had the money to buy that much stuff).

[stefanhendriks]

For now the speed up formula (the more kind of structure you have, the faster you build) is:

int cItemBuilder::getTimerCap(cBuildingList *list, cBuildingListItem *item) {
	int iTimerCap = 35; // was 35 = ORIGINAL

	if (DEBUGGING) {
		iTimerCap = 3;
	}

	// when player has low power, produce twice as slow
	if (player->bEnoughPower() == false) {
		iTimerCap *= 6; // make painful
	} else {
		if (list->getType() != LIST_CONSTYARD) {
			// the given unit will get out of a specific structure. This type
			// is within the units properties.
			int structureTypeItLeavesFrom = units[item->getBuildId()].structureTypeItLeavesFrom;
			if (structureTypeItLeavesFrom > -1) {
				iTimerCap /= (1+(player->iStructures[structureTypeItLeavesFrom]/2));
			}
		}
	}

	cPlayerDifficultySettings *difficultySettings = player->getDifficultySettings();
	iTimerCap = difficultySettings->getBuildSpeed(iTimerCap);

	return iTimerCap;
}

(yay, finally showing off new code ;))

@X3M , I assume your mail adres at your profile is the correct one?

Also lets just see how it works out. I thought Dune II could order more as well, but I do find it too easy to order a whole army through the starport. It is kind of useless to build other structures (ie, heavy factory, light factory, etc) then. Finding the right balance is key ;)

[MrFlibble]

Also lets just see how it works out. I thought Dune II could order more as well, but I do find it too easy to order a whole army through the starport. It is kind of useless to build other structures (ie, heavy factory, light factory, etc) then. Finding the right balance is key ;)

Sure, I just pointed out that Dune II allowed more units to be purchased. Powerful units were still less available anyway because there were less of them in stock, and after the initial stockpiles (which can't be more than 10 units per type) were depleted, they would be slowly and randomly replenished by one unit at a time.

[stefanhendriks]

Actually the current starport logic does not use a stock or anything. Meaning, you could order 8 units of any type over and over again. Using a stock would be even more realistic then. Is the price influenced by the availability of a unit? (ie, for now I determine the price by taking the original price, and randomize half of it. For example: 800 credits, half is 400, meaning it can range from 400 (800-400) till 1200 (800 + 400)).

[X3M]

50% - 150% is nice. No maximum like 999 is nice.

I have checked my version. It's V1.0 on a "386". Yes, the very first version of DuneII :D.

In this version: The starport allowed a maximum of 6 units total and a maximum of 6 if there aren't much of that unit on the battlefield. Where the price could vary between 60% - 140% with steps of 10% and with a maximum of 999 credits per unit. Starport was the only way to get beyond the 25 to get to 100 units total. I always had 22 sonic tanks or devastators before ordering siege. Yip, that was my version.

Sometimes it bugged somehow, then i could order all i wanted, but i got notching. Then, save, exit game, restart pc, start game, load, order last time, and i got it all :D.

I don't understand this programming completely. All i see is a divided by 2 when on low power, but when having more then 1 factory. What will happen then?

And yes, the email is one of the correct ones. :)

[stefanhendriks]

This piece is what is interesting:

if (structureTypeItLeavesFrom > -1) {
				iTimerCap /= (1+(player->iStructures[structureTypeItLeavesFrom]/2));
			}

Meaning, the timer (the higher the longer it takes) will be divided by ( 1 + (amount of structures / 2)).

This means:

0 structures of type:

timer = 10 , 10 / 1 , result timer is 10

1  structure of type

timer = 10 , 10 / (1 + (1 / 2 = 0.5)) 1.5, result timer is 6,7

2 structures of type

timer = 10, 10 / (1 + (2 / 2 = 1)) 2, result timer is 5

[X3M]

So when you have no structures, it will cost 10 seconds to produce a unit? Given a fact that it wont :)

Sounds weird, so when you go from 1 to 2 structures, you can produce 33% faster. 1 to 3 structures means 67% faster etc.

For the starports:

1 starport gives 6

2 starports gives 8

3 starports gives 10 etc.

Right?

[stefanhendriks]

Well, weird.. i found it weird to construct twice as fast, just because you have twice as many buildings. Its like, you can't bare a child in 1 month with 9 women neither ;)...

meh, thats a bad example.

Perhaps with more starports, you can influence the stock market. So, lets say with one starport, and the stock is limited you could order 3 of some kind of unit. But, with 2 starports you could buy 4 or perhaps 5. (so there is a longer stretch). While the maximum you can order is still the same, you just have more access to 'hard to get' units?

It even would be interesting to have all starports in the game (of all players) be taken into account. So if player X has 4 starports, it has more chance of getting a certain unit than player Y who has one starport..

[athanasios]

But we should consider a balanced game-play. There should also be a small penalty for the more starports you built: Higher prices for the extra units you purchase.

[stefanhendriks]

Agreed, so there should be some kind of "Stock" (like CHOAM is a real party) which all players have access too. Anyone has a proposal for that?

Ie, roughly I can see this. The stock has for each item a certain amount. The price is randomized a bit, but , the less there is, the higher the price will be. With each order you take, the unit is guarenteed to be yours. However, the price is also driven up for each unit you take as it makes the unit harder to get.

So how do we replenish these units in the stock?  Would it be timer based? (ie, randomly after X seconds add one to the stock?). And how would this work with the amount of starports? Would 1 starport only give access to the first 6/8/whatever amount of easier to get units? In that case a stock would have 2 or 3 layers, like:

layer 1 -> easy to get units (for all players with 1 starport)

layer 2 -> medium to get (2 starports)

layer 3 -> hard to get  (3 starports)

and limit the amount of starports to be built by 3?

Thoughts! :)