Topics

1

Mods / Evolution faction

« on: 6 May 2018, 13:27:16 »

It's been a good while since I wanted to finish and share this... several years to be precise. A discussion on the ZetaGlest Discord group reminded me about it last night, so I thought to myself "why not pack and share that old thing already"?

This is the Evolution tech. It's a little something I created based on a game I played briefly in my childhood called Rise of Nations: It's a RTS in which you start in the stone age then make upgrades until you work yourself up to modern day. My mod tries to achieve a similar goal in Glest: You start with a group of people living in huts, reach the medieval age, work your way up to modern day technology, then even go beyond into a futuristic space age. The system relies heavily on unit upgrading, as once you upgrade your base to the next age your objective is to morph every existing unit into its evolved equivalent. I achieved this by combining assets from various MG factions created by the Glest developers or community, typically using an unique faction to represent each age... more precisely I used the following faction packs:

Code: [Select]

Age 1: Megapack - Indians, Egypt, Persian
Age 2: Megapack - Romans
Age 3: Magitech - Tech, Magic
Age 4: Imperial - Imperial, Warlords
Age 5: Enemies & Allies - Enemies & Allies
Age 6: Annex - Alliance, Shadow
Age 7: Scifi Pack - Industrators, Martians
Right now this mod is still very unpolished and unfinished: There are missing textures, inconsistent icons, and reaching the last age takes over 2 hours of playing (much more than a typical game lasts). Worst of all, the AI cannot play it yet: They won't get past the first age due to a bug that makes the AI not morph buildings, as it doesn't analyze the advantages of production but only those of attacking when morphing to another unit. I should be able to fix this later by adding a fake attack skill to each unit.

You can try this tech out by cloning it from its Github repository into your user_settings/megaglest/techs directory, then renaming the cloned folder to just "evolution". The tech is available here:

https://github.com/MirceaKitsune/glest_techs_evolution

2

Feature requests / Spawn on death

« on: 5 October 2016, 22:36:55 »

Another basic feature I would like to suggest, which I also plan to use personally. Would it be possible to let units spawn other units upon death please? I'm imagining a definition among the lines of:

Code: [Select]

<spawn-on-deaths>
<spawn-on-death>
<unit type="my-unit"/>
<count value="5"/>
<health value="25%"/>
<probability value="50%"/>
</spawn-on-death>
</spawn-on-deaths>

This would allow useful mechanics such as: A technician emerging out of every catapult / ballista / battle machine that's destroyed (the operator walks out of the wrecked device), drake riders turning into summoners (implying the drake died but the rider survived), workers emerging from castles that have crumbled, and more types of logical unit conversions.

3

Mods / Unit capturing

« on: 5 October 2016, 22:23:49 »

This is a feature I want to use in one of my techtrees, so it would be appreciated if it could please be considered for inclusion. I remembered I made a thread about it long ago, but it seems I never actually have.

I'd like to suggest a simple way of implementing unit capturing: A system to allow specific units to be converted by their attacker instead of being destroyed. This would allow enemy troops to surrender to their attackers and join them when killed, or for enemy buildings of interest to be conquered instead of getting leveled to the ground.

Example: Suppose I want to make the worker from Tech an unit that can be captured. I define an xml block in the following form:

Code: [Select]

<captures>
<capture>
<faction type="tech"/>
<unit type="worker"/>
<health-threshold value="10%"/>
<health value="25%"/>
<probability value="50%"/>
</capture>

<capture>
<faction type="magic"/>
<unit type="acolyte"/>
<health-threshold value="0%"/>
<health value="50%"/>
<probability value="25%"/>
</capture>
</captures>

This says the following: If the unit is hit by an enemy that's part of the Tech faction while its health is below 10%, there's a 50% probability that it will become an unit of type worker (same unit in this case) for the attacker, with 25% of the unit's normal health. Whereas if the unit is damaged by an enemy from the Magic faction while its health is 0% (the unit died), there's a 25% possibility that it becomes an acolyte for the attacker, with 50% of the acolyte's normal health.

The feature would make it possible to create strategic techs in which players can capture each others units, grabbing them for themselves (if part of the same tech) or turning them into compatible versions of an own unit (if part of another tech). I can't imagine much difficulty in implementing this... since all the code would need to do is check the conditions and the attacker's identity when an unit is damaged, then erase the unit and spawn one for the attacker at the same position.

4

Feature requests / Randomly generated maps

« on: 1 October 2016, 13:00:31 »

Kind of an obvious feature to suggest, but surprisingly I'm not seeing other threads about it so might as well make one: Considering Megaglest maps use simple heightmap terrain and real unit positions are always 2D. Would it be difficult to allow automatically generated maps, computed by the engine before the game starts?

When setting up a match, the user would have two options: Select one of the existing maps like you do currently, or have the engine generate a map for you. When choosing the second option, you may optionally edit a few extra fields such as: The X and Y size of the map, how extreme the terrain should be (smooth plains vs. rough mountains), the frequency of trees and other resources, decoration density, etc.

I imagine this should be easy to achieve using perlin noise: Use a random seed for the terrain and for each resource, then scale its brightness to determine height / frequency and its contrast to determine concentration. Then place each player's starting point in the areas which are most open and closest to all resources, and there you have it! This would be fun for people who are bored of the existing maps, and just want something new each time they click the start button.

5

Feature requests / GUI based unit editor

« on: 1 October 2016, 12:25:26 »

This is something I've been meaning to ask about for some time. I make custom Megaglest factions, usually based on the existing art and assets. Although I can't complain too much, I do find that it's ultimately time consuming and problematic to edit the xml files of units manually, even in text editors with syntax highlighting and other helpful tools. For one thing you must find the correct code blocks and lines to make corrections based on what you notice in-game, whereas you're also bound to cause errors that only appear when you try starting a new game in Megaglest.

Has anyone considered creating a simple GUI for editing tech trees, and including it alongside the Map Editor and g3d Viewer? I'm thinking a basic program that lets you select a tech tree, lists all of its techs and units, and offers editable fields for every variable... allowing you to delete or create units and skills and attacks, and browse for g3d files or icon graphics or sounds to be included. The program would essentially read existing xml files and update them when you save your changes, offering visual fields for what you currently have to dig up in the xml's yourself. Later on it could have extra features too... like using the g3d viewer to show 3D previews of each unit, graphs for skills, even predicting the balance between techs and letting you know how overpowered they are from one another! The editors in RPG Maker are a good example of how I'm generally imagining such a visual interface.



I understand that making this program would be a bit of work, and the developers have limited time to spend on new features. I won't complain if it can't be considered or happen anytime soon. But I will say that as a developer, I'd find it extremely helpful and useful, and consider the effort totally worth it! People would find it a lot easier to create new tech trees, we should see more content of even better quality in MG. Let me know what you think please.

6

Feature requests / Changing the appearance of units when an upgrade is researched

« on: 10 April 2015, 18:53:11 »

One thing I liked in some RTS games I've played in the past is that some upgrades had visual effects on units. For example: If you researched an upgrade that increased the shield of your base, the visual appearance of all your bases would change (different model and texture) to feature a more solid appearance for the building. In Megaglest, upgrades can be used to boost the traits of certain units or enable the usage of certain skills, but they cannot change the visual appearance of existing units.This is something I would really love to see fixed!

Since skills define the g3d file and animation speed, I think the easiest way would be swapping skills for a command based on when an upgrade has been researched. For example: A soldier can have the normal stop_skill / move_skill / attack_skill, but also a stop_skill_armored / move_skill_armored / attack_skill_armored. Normally the stop command uses stop_skill and so on... but once the blacksmith researches the armor upgrade, the same stop command will use stop_skill_armored. The *_skill_armored skills point to a different set of 3D models which includes the same unit dressed in armor.

Apart from the visual effect, this approach could also be used to completely replace an unit's attack with a whole different attack when an upgrade is researched, which could be an alternative to unit morphing. This is probably less important since you can already make certain commands only become available when an upgrade was researched, but I'm still interested in changing the visual aspect of units.

7

Feature requests / Limiting skills and structure placement to the vicinity of certain units

« on: 10 April 2015, 18:29:57 »

This is a common feature in many RTS games, which I think the MegaGlest engine didn't implement yet. In some cases, faction designers might want to limit the creation of certain units as well as units preforming given actions to the vicinity of some structures. In other words, some buildings should only be possible to build within a given radius from other buildings, whereas certain units should only be able to preform certain skills when close enough to a specific unit.

Practical example 1: Limiting houses to the vicinity of the castle. The faction cannot place a house in the middle of nowhere, and may only create houses within a distance of eg: 15 tiles from a castle (and potentially other houses). When trying to place the house too far from a compatible structure, the hologram representation should turn red to indicate the action isn't possible.

Practical example 2: For some factions, we might want the summoner to only summon some units when standing close enough to a summoner tower (presumably to draw energy from it). Summoners can therefore wander anywhere around the map, but can only summon when they are standing at most 10 tiles away from the tower.

Practical example 3: The blacksmith can only research certain upgrades if a technodrome is located right next to it (eg: 5 tiles), otherwise the button is gray.

Note that the engine already supports boosting, so certain units gain a mana or health bonus when close enough to other units. But as far as I'm aware, there's no support for limiting the construction of some buildings to the vicinity of others, nor limiting specific actions this way. There should be a workaround to the second issue, by giving the unit 0 max mana by default and only allowing that to be enhanced by boosting... but you still can't limit the availability of specific actions.

Also: If the feature will be considered, it could be implemented to support the reverse effect as well. For example, mages could build towers that disrupt the energy of other mages, so when an enemy mage is too close it cannot preform any energy attacks. Or you cannot build houses too close to farms, because people don't like the smell or something

8

Feature requests / AI lacks understanding of building / worker / summoner morphing

« on: 6 April 2014, 20:07:52 »

At this moment, the AI is only interested to morph units when the unit it's morphing to has a better attack. Due to this, things like upgradable buildings or summoners / builders which can ascend and offer new units are difficult to add, because they're not fully understood by the AI. Please extend the understanding of the CPU on unit morphing to encompass buildings builders and summoners, not just warriors.

For example, you cannot make a faction where the Blacksmith you build offers a set of upgrades, but can be morphed into an Advanced Blacksmith which offers new upgrades. The AI never morphs to the Advanced Blacksmith because it doesn't attack, which is currently its only criteria for morphing, so it doesn't care about the upgrades it has to offer. The only workaround is to give the Advanced Blacksmith an attack... which tricks the AI into morphing to it eventually, though it's only for the attack as far as its concerned. Enemies & Allies is a popular tech tree which uses building upgrading, and where the AI never upgrades anything due to this... I also plan on using the feature in most tech trees I will make.

The only thing that probably needs changing is having the CPU also scan for buildings, unit production and upgrades when deciding whether to morph something, apart from only the new unit's attack. It already does this when it decides what workers or buildings to produce, so maybe the same code can simply be piped into morphing. I hope someone can look into this... the current AI's understanding of morphing is very limited and causes factions to require workarounds such as fake attack skills for some unit upgrades.

9

Bug reports / MG crashes when creation time of an unit is zero

« on: 30 March 2014, 01:03:12 »

If the creation time of an unit is set to zero (<time value="0" />) Megaglest will crash with a "floating point exception" error when the AI (CPU Mega) attempts to build it, although nothing bad seems to happen if the player builds it in a local match. Can be solved by setting it to a higher value, but I don't think it's normal for it to actually crash the engine so I still thought to report.

10

Bug reports / AI breaks when a morphed unit produces units with negative resource requirements

« on: 29 March 2014, 22:01:09 »

I noticed this less obvious bug while working on my tech tree: The AI will refuse to build or produce anything if an unit can morph into another unit which is able to produce an unit that has a negative resource requirement. I preformed various tests and this is a certain conclusion.

To offer an example with the Tech faction: Currently, the farm can produce cows, and cows take -100 food. However, if the farm wasn't an unit which was built directly, but say the Blacksmith could be morphed into a farm, the AI would refuse to do anything.

11

Feature requests / Enable land units to deposit to air units

« on: 27 March 2014, 12:51:34 »

I'm working on creating a faction, and noticed a very problematic bug yesterday: If an air unit stores a resource, harvesting units won't be able to deliver it to them, and will just sit there and do nothing. This happens both if the harvesting unit is land or air itself. The opposite doesn't happen however, and air miners can deliver to land units.

Say you make a flying saucer which can store 100 metal. You move it next to a metal deposit, then assign a worker to mine from that deposit. Once the worker is loaded, it will look for the nearest unit to take the metal to... in this case it finds the saucer. It will walk next to it, but instead of depositing the metal then returning to the mine to continue, it will just sit there and follow the unit around... as if it's trying to unload but can't.

When both the unit which deposits and the unit which harvests are air units, the miner should definitely be able to unload. If the unit who stores is air and the unit who mines is land (or the other way around), whatever the developers believe makes most sense: Either the miner can still deposit, or the miner should ignore the air unit and look for the other nearest deposit... considering they are at different heights logically.

12

Closed feature requests / [done] Looting

« on: 25 March 2014, 20:38:47 »

I was surprised to hear this doesn't exist yet, since it's a rather basic feature and needed for many ideas. If it's not too difficult, please consider adding it soon!

I'd like a new function in the faction XML to specify a list of resources that destroying an unit will give the attacker. If a value is specified, that amount of the resource is given, whereas specifying a percentage gives that amount from what the faction which owns it has. If specifying a negative value, the attacker would actually lose that resource when destroying an enemy building, although that would make little sense. A flag should specify if to also deduct that amount from the owner faction and how much, or if to just make those resources appear to the attacker. If the attacking faction does not use the resource or have where to store it, there's no effect. The function I have in mind would be something like this:

Code: [Select]

<resources-death><resource name, amount, loss/></resources-death>
Example 1: A faction has a building which can be looted of half of the resources it was build with. It costs 100 gold and 50 stone to build. When it comes to the gold, the owning faction will also lose half of what's being looted. Also, 5% of the faction's entire wood stock will be taken away entirely. The code would be:

Code: [Select]

<resources-death>
<resource name="gold" amount="50" loss="50%"/>
<resource name="stone" amount="25" loss="0%"/>
<resource name="wood" amount="5%" loss="100%"/>
</resources-death>
Example 2: The attacking faction uses an unique resource called X, which is optional and can only be extracted by destroying a certain building from another faction. That faction however doesn't use the X resource in any way itself. Implicitly, the resource can only be obtained if the attacker is playing against this faction so they have the building to destroy. The victim faction's building would have this code:

Code: [Select]

<resources-death>
<resource name="X" amount="50" loss="0%"/>
</resources-death>
Before anyone asks, yes, I'm aware this is already possible in Lua for scenarios. To properly do it as part of a faction however, it must also be possible within the XML files of units, otherwise it will not be consistent and won't work in normal battles.

13

Feature requests / Anaglyph stereo support

« on: 30 September 2013, 19:33:37 »

This is probably a more uncommon feature for a RTS game, as visuals tend to matter less from a distant top view. But could support for anaglyph stereo be added to the engine? I have red & cyan glasses, and use them for many games that have stereo support. I think it would look nice for Glest too to see the environments and units in realistic depth

14

Feature requests / Continuous mode (dead factions replaced by new ones)

« on: 30 September 2013, 17:48:08 »

Someone close once told me that a reason they don't like RTS games is because you always build everything just to start over again. I remembered that as I was thinking of an idea for MG earlier today. I doubt this would be possible to do in practice, but still wanted to comment the idea.

When you destroy all enemy players, you get a message saying "You have won, press OK to quit". But what if there was a way to have a game that never ends? Whenever you defeat your enemies, new ones appear, who also develop and eventually fight you. This could be achieved by having each defeated player start over again instead of being booted from the game, with the default units and resources. In single player, people could save such games and play them for as long as they want like a story. In multiplayer, people could fight over conquering a map for weeks, each defeated player having the ability to return and build a new nation which will fight the victorious player again. Unfortunately there are at least two major issues which likely make this impossible:

First one is that a new player would be severely underpowered on a map where an evolved player already exists. We couldn't simply have a faction with one castle & 3 workers appear, when a player which has an army of hundreds could simply walk to them and wipe them out in a second. There would need to be some way to keep the victorious player from harming a newly created player until they're strong enough, but any way I can imagine would be an ugly hack.

Second issue is resources. Supposing the defeated player already mined all the gold at his spawn location, the new nation taking his place wouldn't have any gold to mine. So the only way would be all resources getting reset whenever a new faction "arrives" to the map. But what if a building or unit is standing where a forest that was harvested used to be, when attempting to place the trees back? Once again, likely impossible since any solution would be weird.

Still, I'm hoping the idea might be inspiring and someone could think of a system for a "continuous mode". In real life, every empire that fell had another taking its place. Either a larger empire divided itself, or new people came and made their own. Being able to simulate this in Glest games would be pretty neat

15

Maps, tilesets and scenarios / Map - Control Points

« on: 29 September 2013, 21:50:51 »

I decided to make a MG map, based on a concept I had in mind for some time. It is a 3 x 3 player, 64 x 64 size map, mirrored on the X and Y axes. Each team's mainland is separated by a river. In order to get from one base to another, you can go through two paths. Each of those paths has a clearing with resources on it, 3 per path / 6 in total. Each team should conquer those spots in order to make it harder for the enemy to get to their base. The idea is similar to Onslaught mode in FPS games, hence the name

Links: source 1, source 2. Once again I forgot how to take a top-view screenshot, so here's a picture from the map editor:

16

Feature requests / Defecting units and conquering buildings

« on: 12 August 2013, 13:41:55 »

Here's a nice feature I was thinking of: What if there was a way to convert enemy units to own units, instead of always having to destroy them? In other words having units that defect to an enemy team under some circumstances. Obviously the golden rule is that both you and the enemy must be of the same faction.

I can think of two ways in which this could take place. One is having enemy units automatically become yours if they're low on health and underpowered, as a way of surrendering so you spare their lives. This could be done by having each unit detect the count + attack + defense of enemy and allied units in their view range. If the unit determines there's no chance to win that battle, they might offer themselves to the faction they're fighting. After all, no army has soldiers that wouldn't be betray to stay alive Predisposition to betrayal could be influenced by certain factors. An idea might be the amount of resources you have... so if you're low on food for instance, your units might have a lower moral and turn over to enemies more easily.

The other way is making enemy conversion an attack type, and having special units do this (priests for example). When a priest approaches an enemy and begins preaching to it, that unit won't attack but stay there and listen. If the priest is allowed to talk to the enemy units for too long, that unit is convinced to join their faction. I remember seeing exactly this in another RTS years ago (I think it was Populous) and it worked nicely. But this ability should require limited mana, and certain units should be immune to preaching. Only problem is such units would be useless if you don't have an enemy of the same faction as you, unless they also have other abilities like healing.

Buildings might be a different matter since they aren't sentient beings. They can simply become yours after their health drops below a certain amount, to represent your troops taking them over. It would be cool to conquer enemy establishments during an attack instead of just destroying them, and take over castles / barracks / blacksmiths. Animals could work the same way, since pigs and cows don't care to fight for their country

I think this feature would add more depth balance and strategy, and I'd love to see any idea like this done. What do you think, and any developers willing to give it a try?

17

Feature requests / Ability to change music when an upgrade / new unit is reached

« on: 22 May 2013, 20:15:52 »

Some progressive factions could use this, such as one I'm working on now. Once a given unit is created for the first time, or a given upgrade is researched, a trigger to change the music would be useful. Random example: Once you create your first Technodrome, the song changes to a more modern one. For small factions this makes no sense, but for more progressive and upgrade-based ones it's a welcome addition.

18

Feature requests / Walls and gates

« on: 20 May 2013, 18:57:14 »

Glest Advanced added this feature some time ago for Magitech factions. You have the ability to build continuous stone walls, and if I remember right you can also add a gate which only allies can walk through. Walls are harder to destroy but it's possible to attack individual segments. I'd like to see MG and its faction having this ability as well. Maybe it can be ported from Glest Advanced... if not perhaps implemented from scratch. Not sure how difficult it would be, but wanted to drop this suggestion here as well.

19

Feature requests / Automatic unit production

« on: 20 May 2013, 14:36:37 »

As I recently found out, the recipe of success in a Glest game is building units as quickly as possible. But as you advance that gets more and more soliciting, since you must click a lot of buildings / summoners and give new unit creation orders (especially after you establish yourself in different far areas of the map). I was wondering if a system to automate the process is an acceptable idea. It would make things a lot easier and allow the player to focus on other things than running to buildings and constantly clicking buttons.

Best way to do this is allowing unit creation buttons to be 'permanently pressed', eg: by control-clicking them. When they are, that building / summoner will try to produce the selected type of unit as soon as the needed resources are available and there are no existing orders on queue. If more than one unit is control + clicked, the building / summoner will go through them in order. If the player gives other commands to the building / unit in the meantime, those are added to the queue and the automation system waits until they're all over.

Example: You play as Tech and have a barracks, which you want to constantly produce swordsmen and archers. You select the barracks and control + click the 'produce swordsman' and 'produce archer' buttons. As soon as you have enough resources, the building automatically starts producing a swordsman. Once the swordsman is done, the building tries producing an archer. If you don't have the needed resources it does nothing and waits till you do. After it finishes with the archer, it tries to produce a swordsman again and so on.

20

Feature requests / Unit patrolling

« on: 20 May 2013, 14:13:16 »

I like how in most RTS games, you can select a set of units and control + left-click on different spots to have units patrol there. I'd like to see something similar in MG. So when Control / Alt / Shift clicking multiple locations, the selected units will constantly run between them and loop through the selected "circuit". Glest Advanced has this, so maybe the feature can be ported over from it.

21

Feature requests / Auto explore

« on: 20 May 2013, 14:09:16 »

One of the most annoying and soliciting moments is when at the start of a game, you have to work hard to establish as many units as possible, and at the same time explore the map so you know where resources and enemies are located. Exploring is upsetting because you must constantly select an unit and click in the black spaces, in between visiting units and buildings to give new orders.

Could an auto explore command be added please? Consisting of a button on any moving unit, which when clicked causes the unit to go around the map and explore the area. It would make things a bit easier and less soliciting.

22

Feature requests / Spy units

« on: 20 May 2013, 11:25:44 »

In my opinion this would spice up the gameplay quite a bit, and add more suspense and strategy to the mix. But on the technical side, it might be complicated to find a correct implementation. Here's my idea:

Each faction would have the ability to train spy units. Such units would have a special feature: They can appear as an own unit to the faction they're spying for. For instance, if Player 1 (red) trains a spy against Player 2 (blue), P2 and all enemies of P1 see it as P2's unit (blue color) and will attempt to attack / not attack it accordingly, while P1 and his allies see it correctly (red color) or have another way of knowing it's P1's spy. Covered spies must never auto-attack the enemy they're spying for, but right clicking any enemy unit should attack as normal. Spies can be used to enter the enemy's territory and explore it, allowing the player to see their enemy's setup. Also, when a spy is ready to blow its cover (more on that below) they can do some damage and take the enemy by surprise.

Obviously, there should be ways to blow a spy's cover. This should happen if the spy gets in a fight with the faction they're spying for (regardless of who attacks first). Additionally, there could be anti-spy buildings or units. If a covered spy gets too close to one his cover is blown. Blown cover means the spy turns back into a normal unit which can be seen and attacked like all others. I'm not sure when and how spies should be infiltrated / masked... this should probably work similar to morphing but under more strict conditions. A spy that's been deconspired should also be unable to re-disguise itself for a few minutes.

Sadly there would be a lot of technical difficulties to making this possible. Those are the ones I'm aware of:

- What happens when the player who sends the spy is of a different faction from the player being spied? If for instance P1 is Magic and P2 is Tech, P1 would quickly notice one of their units is a magic unit although they are tech. Only solution is for each faction to have their infiltrated spies look like one of their units (have the same model). For magic that could be the mage, for tech that could be the worker or swordsman, etc. They should look the same but not have the same abilities... so if a covered spy looks like a mage it doesn't mean it can gather resources or attack with magic.

- What if a faction clicks an enemy spy and tells it to go somewhere? Even worse, what if it tells it to attack or gather resources? If the spied player notices an unit (seemingly theirs) won't respond to commands, it's obvious they're a covered spy. We could allow masked spies to be controlled by both their real owner and the faction they're infiltrated with, in which case the owner has priority (if both factions click for the spy to go somewhere). But what if the spy looks like a worker yet is visibly unable to gather resources and build... or looks like a soldier but can't attack? I guess this could be another way to deconspire them.

- Considering that Player 1 is on one side of the map and Player 2 on the other side. P1 sends a spy over to P2, which means he has to walk all the way from one end to the other. Unless P2 is really stupid or not paying attention, he notices an unit of their own walk from one point to the other, either on the minimap and in the world. They know they haven't sent anyone there, so it would raise obvious questions. This too would need some thinking.

Due to those difficulties I'm not hoping we'll see this happening, at least not anytime soon. But it would be really fun if it could. I'm reminded of a very old RTS game I used to play back when I had my first modern computer, which I think was called Populous. At some point you could produce spy units, which were able to enter the enemy's base and set fire to buildings (but once they did they were deconspired).

23

Feature requests / Alliance changing system

« on: 19 May 2013, 22:09:53 »

I've been thinking about this feature for a bit. It would be one of the nicest new abilities to add, and should be possible to implement if player teams can be changed during a game. This is how I believe it should work:

The ability to change alliances should be a game option, possibly disabled by default. When enabled, a menu (opened by a keybind) presents the player with a GUI listing all players (including them self). They can select any players from that list, while another selector specifies the team in which he suggests moving (more on that below). There should also be a text field where the player optionally writes why they want the team change. Lastly, when the player is done he presses ok and the proposal is sent to all players involved (more on that below).

The menu can be used to do one of two things: Go to another team, or ask someone else to join yours. The menu should assume which you are doing by the team you selected (if it points to your current team it means you're inviting, if not it means you want to leave there). When you want to join a different team, you can select either just yourself or yourself plus other players (be they enemies or allies). When you want to bring a player to your team, you can only select enemy players. Once the player presses OK, all players involved get notified and must express their approval (either in chat or a menu popping up). That includes the players you selected to invite / leave with, as well as all players in the team you are inviting to / leaving to. The change only happens if everyone votes "yes".

To better explain what I had in mind, here are some examples of how it would be used. Given the following initial setup, and considering we are Player 1:

Player 1 = Team 1
Player 2 = Team 1
Player 3 = Team 2
Player 4 = Team 2
Player 5 = Team 3

Example 1: Players 1 and 2 aren't doing too well. Players 3 & 4 are more powerful but could use some extra help. In order to survive, Player 1 considers betraying 2 and joining 3 & 4, so he launches the proposal of joining Team 2. Players 3 & 4 who compose this team are informed, and need to vote whether they agree or not. If both do, Player 1 becomes part of Team 2. In this circumstance, Player 1 could have also invited Player 5 with him, and if 5 also additionally agreed both of them would have went to Team 2.

Example 2: Players 1, 2 and 5 are very weakened, while Player 4 is very powerful. Players 1 & 2 can no longer afford to fight 5 as well, and neither can 5. So Player 1 proposes that Player 5 joins his team, and 5 is asked to vote if he wants to or not. Player 2 is must also vote since he's part of Team 1 where 5 is being invited. If both votes are positive, the transition is done. Additionally, considering that Player 3 was willing to betray 4 for whatever reason, the proposal could have been that players 5 and 3 both joined Team 1 (3, 5 and 2 would all have to vote if they agree).

Example 3: Player 1 has grown very powerful and all other players are weak. He's actually so powerful that he no longer wants any allies. Although the game started with 3 teams, he makes the proposal of becoming part of a new team (Team 4) so he may separate from everyone. Such would require no vote from anyone else since it involves Player 1 alone. Optionally, Player 1 could have invited any of the other players (2, 3, 4 and / or 5) to come with him to the new team.

Example 4: Player 1 is being attacked by Players 3 & 4. He's losing and near the point of being destroyed. Before the enemy's units get to his last castle, he asks to surrender, by telling players 3 & 4 he wants to join them. If 3 & 4 feel like taking 1 as an ally instead of finishing him off, they accept. Player 1 becomes part of their team and the units from 3 & 4 automatically stop the attack.

I think this ability would add more feel, strategy and realism to MegaGlest. What led me to think of this were historical movies I occasionally seen recently... about how nations went to wars, established alliances, surrendered when there was no other choice, etc. Only downside is that this could cause imbalance, as weaker players would try to join the stronger ones. Then again, that's how many weak nations survived throughout history, so this would only add more realism. What do you think? Can this be done in MG anytime soon?

24

Maps, tilesets and scenarios / Map - Link

« on: 19 February 2013, 15:37:48 »

4 vs 4 map, symmetrical horizontally and vertically. The point is to have a layout where players in each team are linked in a specific order and must be defeated accordingly, mountains and trees making it impossible to get past without having to fight each faction in the way. You must first defeat the 1st player near the entrance, then go for the 2nd or 3rd player, and from there reach the 4th player.

The map comes in two variants, large and small. Small is 64 x 128 and contains smaller roads and areas, but also fewer resources and not as much room for each faction to place units and buildings. Large is 128 x 256 and contains larger fields and longer roads (as well as new areas) but the layout is a bit more confusing to learn. They're both different maps but go for the same layout and have the same name... try whichever you like most.

Download the small version here: link 1.
Download the large version here: link 1.

(click to show/hide)

25

Maps, tilesets and scenarios / Map - Natural Fortress

« on: 19 February 2013, 15:08:55 »

One of the maps I worked on during the last days. It is a 3 vs 3, 64 x 128, vertically symmetrical map. Each team is located behind large mountains, in an open area which can only be accessed through a tight path. Allies work together to protect the main entrance while making their way through the enemy's. Resources are located inside the safe area, both near the starting points as well as a few places around them, but also outside the "fortress" in open fields for those who wish to risk establishing a castle there. A lake divides the map vertically, which can be crossed in two opposite points where there's shallow water.

You can download the map from here: link 1. Try it out and let me know what you think

(click to show/hide)