|
Post by Quintaxel on Jan 20, 2014 13:26:03 GMT 1
Storing values during the game is not the problem, as you said an array can be used for this. It's storing the data after you quit the game. I'll check the post for which you gave the link, thanks.
|
|
|
Post by Major Pain on Jan 20, 2014 21:03:45 GMT 1
As long as the values you wish to store are a Global Variable, they can be passed from game to game.
The game engine stores unit elements that are passed that pertain to core units and player performance. Those values are stored in a temp file in during the save. These are not global variables, but static or local variables.
Arrays must be storing Global Variables for the values to pass. That is done right after the Init when you declare the Array. Values within the Array can be changed as the game is played, then at the final win or lose function, all values are locked and passed. Care must be taken to trigger the array from the last game start if the player loses and replays. If the player wins, then values are passed.
Ok.. about turning on specific units in the next game that may carry over. We cannot know exactly where a unit need to be positioned unless the map has a direct route that the player must take. The array stores which of the units have been killed, so they are ignored. So when landing players units, we can use a couple of tricks to put the correct units where we want them.
The most common is to have the script units in various locations, but this can lead to errors when you have the same script unit in more than one or two places.
It is far easier to switch on the units you carry over from player 2, then move them to the players start location. This works well if the Command unit and a couple of support units will always be in the mission. The player is simply waiting for his units to arrive in the sector. We place all of the possible script units in a out of the way landing area, then perform the LandReinforcements for each we will use. Once they are turned on as player 2, then they are moved to the players sector one by one. As they arrive they are changed to player 0, and he can assign them for purpose or position. We can do this for tanks, spgs, trucks, and infantry. By this meathod, we can basically create a separtae level of core units outside of the game engine, and provide many kinds of enhancements, like increase veteran status, or skill. Clicking on a unit might display the Unit name and skill level if you wish.
If the unit is killed, it is not replaced unless you build in this function, by assigning another unit from the array. But this can be done easily. Player scoring remains in the hard coded section of the game engine, but the core units are handled differently since we are assigning core units from any kind of unit. You can virtually make every unit in the game a core unit, or just specific units.
You do not want to make more than one unit in a script unit. In other words, each unit has its own script id. This is easier to track, because if several units are part of a group, you lose the ability to track each unit individually. You can make the script quite simple or quite complex depending on what you are trying to accomplish.
It is a good idea to have a Command unit, or several command units. If the command unit on a map is lost, then the player loses. Although, having a couple of command units may allow the player to continue with a significant change in the behavior of the entire army. This is kind of a penalty sine the second leader may not have the same skill or leadership capability. But typically, if you lose the command unit on a map... then you lose that mission and must start over.
I'll add this... On map one you may have 5 tanks which is basically a platoon. A Armor Company usually consisted of three platoons, two with medium tanks and at times one light tank or recon platoon.
Typical US Armor Company
Example: 1st Platoon consists of FIVE M4A1(75) Shermans 2nd Platoon consists of FIVE M4A3(75) Shermans 3rd Platoon consists of FIVE M5A1(37) Stuarts
Not every Armor Company contained a Light Armor Platoon... much depended on available tanks and crews. Heavy loses of Sherman tanks many times might force a Platoon to accept the M5 Stuart or the M3 Lee. This varied greatly in different theaters.
We an easily replicate replacements or new units assigned to a platoon or company. We track each unit individually to maintain its individual statistics; HP, ammo, skill, etc... If a unit is killed, we can assign a new tank and crew, or we can leave the platoon in the current situation.
As we move between maps, we can remove a company from duty so it may re-fit in the rear and assign a new company, or simply replace a platoon. This happened all the time within a Tank Battalion. if we store the entire Armor Battalion, we can pick and choose which units will be used. We can even have a random function decide which units will be assigned. This adds a sense of the unknown each time the game is played. You might get all M3 Lees in Africa when you really need some M4 Shermans, but you must play the hand you are dealt until something inspires the HQ to send you M4s. So there is a lot of flexibility in how you script you missions.
About complex Scripts: When we write our scripts, we use the same functions over and over for all of the units. The function is written so it uses the Script id that is passed to it, and not specific Script ids. So if we are checking to see which unit is in a location, we can do a quick check and confirm the units script id, and its condition, and even display the units name; Tank 1, 1st Platoon, 4th Company... of what ever Battalion... We can make the name as long or short as we need to name the tank. Shorter names are better, but we can carry it out all the way if we want. The array stores the name, and all of the tanks stats. We can even store the tank commanders name if we wish. Then if we are felling especially froggy, we can make a separate unit file for each tank in the game... So each has its own marking as per its number or name. This makes it easier to spot the tanks by their designation. And it is easier to keep Platoon together. This might be key because a Platoon is a strong-fighting force and tanks by themselves, they are quite weak and dumb. They are easy prey for enemy platoons or well hidden guns. This is why Sherman tactics usually cost 3 of the 5 tanks to take out a Panther or Tiger. The basically surround the prey and try to get to the rear or sides before getting hit and taken out. Why should the game be any different if we are working toward historic aspects?
We can add any number of units as they are needed, but the game becomes more about strategy and less about rushes or lucky attacks. Objectives can be changed based on the players army strength, if his losses exceed what is allowed for the original objective.
I hope this explains a bit more about how we pass the variables and carry units over.
MP
|
|
|
Post by Quintaxel on Jan 21, 2014 14:34:22 GMT 1
Thanks for the explanation MP. I think I understand the principle of how information about (core)units and player performance can be passed from map to map. At least for now, I think I understand . I'm really looking forward how this will be worked out in the chapter project. However this is not what I had in mind. I do not want to pass information from one map to the next but "save" values so they can be retrieved when a saved game is loaded again. Such values are the result of a variable that was used in the script of the map (mapname .lua) and are not necessarily linked to units or player performance.
|
|