Messages

1

Off topic / Re: What are y'all up to these days?

« on: 11 August 2019, 10:33:44 »

After changing my low paying service jobs and sort of flip flopping between politics and EVE Online for hobbies I'm mostly back to working on my post Mandate turn based fantasy politics simulator project. Politics was incredibly frustrating. After finally connecting with the political campaign I was supporting and working with some awesome people like Michael Sayman, of Facebook fame, on various volunteer projects, I realized the candidate I was supporting had a terrible dumpster fire campaign, for a variety of reasons and that the roughly 2 years I spent being involved in politics over multiple elections was all a waste of time. Also, the country, and the planet, are screwed especially for non-wealthy people. I had fun in EVE but I ended up having to stop for real life reasons just as I was about to become one of the top 20 richest players in the game. Which sucked. It was cool to see the devs actually implement a galactic invasion storyline recently, because while I don't play anymore I had worked with people who had plans to do a player run event in the same style. Michael offered to get me an interview at Google but realistically I wouldn't be able to hold down a knowledge job doing something I wasn't into so I had to decline.

Working on my own game really makes me miss Mandate for one specific reason. I could implement a major feature pretty easily. And there was an already working game so I could see new features in action. On my own project there is still a long stretch where its not a functioning game so the payoff of adding a feature is quite a bit reduced. Grinding through adding UI elements and AI, and other non-gameplay aspects of the game is pretty tedious also. A lot of that is my own fault for doing a game with a substantial scope increase over most other turn based 4x/grand strategy games, though. With Mandate it was mostly Majesty TFKS ++. So it was much easier to stay on target on top of the shorter conception to function time for game features. Downside of course was not being able to make a living off a FOSS game whereas if I ever do finish my current game I could theoretically pay bills and not have a day job.

2

Mods / Re: Unit capturing

« on: 27 November 2016, 03:14:20 »

You would need a mapping which unit to spawn for which unit. By this you get a dependency of one faction to another. Up to now there is no such dependency and you can move factions around.
I dont really want to introduce this dependency, but if it would exists it is possible to implement somehting like you suggested.

I don't see how. You kill a unit and spawn your own faction's version. If you kill a unit that you don't indicate in the XML, you don't spawn a unit. So the unit would just die instead of being captured. So yeah it wouldn't work right but it wouldn't break the game somehow. If you were going to the level of modding that involves swapping factions around you should be able to handle this. You could even just bump and error if capture failed to the error log. If people are moving around factions but can't read error logs that's not really your fault.

3

Mods / Re: Unit capturing

« on: 24 November 2016, 17:43:14 »

Wouldn't you just define the unit conversion in the XML and then kill the one unit and spawn the proper replacement in the same location? In what way is this complicated?

In fact wouldn't this just be a copy of the spawn at death feature which you did in fact implement? You don't literally have to modify a given unit to another type.

4

Off topic / Modding AI: Player Created AI Modules For Strategy Games

« on: 27 October 2016, 23:21:48 »

I've been developing an idea I plan to use in my current game project. At least I hope to do so.

I would like to enable a game state output to a file, sort of like saving, which can then be accessed by a separate program. That program could then return a file which would be read with the game. In this way you would enable modders to have 100% freedom to design the AI mod of their dreams, probably a compiled program in C++ or some other language. Since they are trading file outputs the actual nature of the program probably doesn't matter as far as languages are concerned. The modder made AI could do all sorts of stuff like have its own files and data just like the built in AI of a game does since its its own totally separate program. Well there may need to be a way to spawn multiple instances of the AI module so that they can all run simultaneously and speed up the end turn wait. My CPU has 8 logical cores so it could use 1 for each instance of the AI.

Well, even just using all 4 cores would be helpful. Otherwise as long as your program could produce proper output you would have total freedom in the AI. Obviously for real time and multiplayer games this could be an issue, especially some kind of cheat in multiplayer, though I'm not sure it would be super easy to send a bogus output to get some benefit.

Also each individual AI could allow for scripting if so desired since it can do anything it wants, so you wouldn't be preventing non programmers from helping.

5

MegaGlest / Re: IRC Freenode and Discord Channels!! Please introduce them to new players.

« on: 9 October 2016, 01:31:36 »

This topic is a bit of a waste of time really. Regardless of what you do almost no one is going to play MG multiplayer. It lacks distinctive features, so what reason to play it over professional games? It has no players, so its not convenient. It doesn't meet modern standards for art quality.

Why argue over who doesn't do what? Even popular professional games of ages past with better mechanics and assets are failing in multiplayer. WC3, BW, etc.

6

Feature requests / Re: Global Damage Multiplier in Custom Game Options

« on: 5 October 2016, 06:40:30 »

No I mean, literally I wrote all the code you needed. Okay well not the get function. Unless MegaGlest is calculating damage in more than one area, which is a violation of OOP, you just need to assign a variable to World and then apply it in the damage equation.

In world.h:
int damageMultiplier;
int getDamageMultiplier() {return damageMultiplier;}

In wherever damage is calculated:
damage equation crap * world->getDamageMultiplier();

Since this is modified in game you don't even need to mess with the config file or anything.

The most work is adding an editbox in the UI to modify the variable at game set up.

7

Feature requests / Re: Global Damage Multiplier in Custom Game Options

« on: 5 October 2016, 06:29:31 »

This is pretty simple. A variable in the world class that initialized to 1.0. Then you simply add something like:

damage equation crap * world->getDamageMultiplier();

8

Feature requests / Re: Possibility to disable the vanishing corpses

« on: 5 October 2016, 06:24:46 »

Can't you just set the time factor for the corpse to an arbitrarily large number and have it persist forever? Since its not animated and has no collision properties or unit data it should be relatively easy on server resources. Or is the time setting a GAE thing?

9

Feature requests / Re: Randomly generated maps

« on: 5 October 2016, 06:22:37 »

Generating roads would be pretty simple. Its basically just a one time pathfinding operation where you can take some shortcuts.

The real issue is making it look nice. Making a functional random map is trivial. Making a "wow that's awesome" random map is the sticky part.

10

Feature requests / Re: GUI based unit editor

« on: 5 October 2016, 06:20:34 »

Copy pasting is like 70% of new unit making. Its just a tedious pain in the ass to write all the tags and sub-tags out by hand, especially if you mistype something. When I began my current game development project where I wrote all my own code, I immediately dumped XML for plain text. There are occasionally some issues if I want to nest something where I have to write a special function to load each class of object but the actual writing of data files is immensely simpler.

What Omega fails to understand is that XML editing isn't a matter of difficulty, its a matter of "holy shit this is boring and takes forever I'd rather roll around in a nest of fire ants that type out 50000000 lines of XML for this new faction".

11

Feature requests / Re: My Idea Box

« on: 5 October 2016, 06:16:20 »

Its a matter of time, different coding practices, and different code bases. For instance a lot of Mandate relies on GAE features which increases the amount of changes that would need to be done. Also nothing is Mandate is multiplayer safe. So you can't even just copy paste the code from GAE/Mandate over to MG. You'd have to copy the data structures and then rewrite a lot of the functions with multiplayer, cross platform, etc in mind.

12

Feature requests / Re: My Idea Box

« on: 4 October 2016, 19:08:55 »

I've never played any of those strategy games, I find that virtually every "strategy" game is heavy on micro, which has absolutely nothing to do with strategy. I desire to play a strategy game that is more like real strategy, where you focus on actual strategy instead of tedious clicking just to keep your units from killing themselves. I just find it ludicrous that as things currently stand, you have to tell the worker to fix the building that's about to fall on him. It's also always a bit awkward when a soldier is standing there and doesn't respond as archers he can't see slowly fill him with arrows. The units are pretty much brain-dead.

Sorry for my little rant. My uniform selection idea was just a quick thought, as hopefully a way to spend less time assigning shortcuts.

Mandate had that, Majesty had that decades ago. Actually in Mandate you only controlled your sovereign unit directly. I had units doing relatively complex behaviors. Of course its basically just a priority list. Like a wizard would check if a blacksmith have a fantastic new stave available, check his gold inventory, check the cost, then decide whether to buy it. A smithy could build a forge for mithril and then check if any nearby smelters had mithril ingots, send a worker unit to buy them, and then make mithril plate armor. I had a bit of budget checking so that a smithy wouldn't blow a whole budget on mithril and not have any money to get iron for iron swords for poorer customers.

The major difficulty is primarily the quality of the AI. For instance my mages had a mana pool. They'd run through the spell list and find the lowest mana cost spell that did enough damage to kill an enemy or the lowest mana cost spell that did the most damage. Spells even had cooldown checks. But they couldn't behave in a much smarter way. For instance they couldn't calculate that the enemy was x distance away so we can pop spell Z, wait for the cooldown, then pop it again for maximum mana savings. They'd do the check for each attack individually. So they might end up casting spell X, then spell Y which combined cost 10 extra mana. I could have had them run a larger number of checks for various things but then you start worrying about performance issues.

13

Feature requests / Re: Human-only simulation

« on: 4 October 2016, 18:59:46 »

Should be pretty simple. Control scheme should just be a check to ask, is this part of player faction? No? Cut off GUI code beyond description. Ergo, just set all checks to yes. That's what happens in GAE. I was swapping control dynamically through the capture mechanic in Mandate and I barely changed the GAE code for GUI display.

14

Feature requests / Re: GUI based unit editor

« on: 4 October 2016, 18:54:43 »

I made one of these. Unfortunately its not MG-compatible. Its relatively simple to do though. Making the GUI is the most difficult part. I had mine included directly in the game, just like the map editor I made was. Easier than making an all new separate program. Plus if you do it in the game you can easily test it by simply copying XML loading code the game itself uses.

15

Feature requests / Re: Persian "princess" melee attack

« on: 6 July 2015, 12:18:56 »

I taught the AI in Mandate to use multiple attacks properly, as you can see in my video. They pick the attack dealing the most damage, unless a less mana costly attack can kill the enemy. I did not teach them to use 2 weaker attacks for less mana if that would work instead of hitting their highest damage attack and then using the weakest finishing move. They also couldn't detect a blob of enemy units to focus an AOE hit on. But those are not extremely difficult, unless you have some other use for the performance the distance and damage calculations use up.

16

Off topic / Re: Great linux games

« on: 24 August 2014, 16:19:29 »

I gave up on EU4 after the massive headache of trying to do a total conversion. Their error checking for modders is shit, as is their documentation. I did play it for 1500 hours. I was forced into doing mods because Johan keeps *** up the vanilla game with his stupid ass ideas.

17

Mods / Re: Total conversion based on the Ryzom assets?

« on: 14 August 2014, 21:51:28 »

Levels are pretty simple to implement. Items are a massive pain for a robust implementation.

18

Feature requests / Re: Non selectable non commandable uints

« on: 5 August 2014, 14:33:25 »

Mandate has emanations inside tiles themselves, as well as from map objects. Those might be more useful methods than non-selectable units and require very little code to set up.

19

Feature requests / Re: Non selectable non commandable uints

« on: 5 August 2014, 04:51:44 »

In such a case, why even have commands on that unit?

Have you played the storming scenario? I'm pretty sure that it's in all engines, since it was one of the last additions to vanilla Glest before development stopped. In that scenario, you have to accompany a summoner around the map. If the summoner dies, game over. In order to make things difficult, the summoner moves on her own and you must guard her. But that would be too easy if you could control the summoner (just make her sit in a safe place).

The solution that the original Glest devs used was to make the summoner belong to an allied faction (thus preventing you from issuing commands from her). Making a unit non-commandable would allow this to be done without using a new faction.

Only complaint is that as a unit property, you'd have to create an entirely new unit to use this in scenarios (which is totally doable if you use a custom techtree/faction, but not so doable if you want to use someone else's techtree/faction). I was able to do this in military (several units only appeared in scenarios) since I had full control over the techtree. But a scenario for MG won't be able to modify the MegaPack without requiring a new version of the game (or a MegaPack clone, etc).

So setting a unit non-commandable would probably better as a Lua command.

Although that's assuming that scenarios are the only reason to set a unit non-commandable (but I can't think of any others).

That's my bad. I always forget about LUA.

20

Feature requests / Re: Tags

« on: 4 August 2014, 16:52:52 »

Hey Yggdrasil, long time, no see. Anyway, thank you for your reply. That worked perfectly. While I knew about passing by reference and value, I did not know that return types had similar semantics. The code is now working as expected.

Anyway, now that that's working as expected, I just a have a few things related to tags that I need to finish up. I need to verify that saving and loading the game works as expected, I want to refactor AttackBoost::isAffected (it has a horrible amount of code clones), and I want to make tags translatable (in the same manner as the rest of the techtrees).

EDIT: This makes me realize that there's a number of other places where we return a copy to a vector instead of a reference. They haven't been caught because they didn't use iterators like I did, but pose a threat creating of future bugs. Might be worth taking the time to convert these.

How does saving work in MegaGlest? I spent a lot of time modifying GAE's save and I wonder if GAE and MG do it in the same way.

21

Feature requests / Re: Non selectable non commandable uints

« on: 4 August 2014, 16:51:08 »

Non-commandable would be useful for scenarios. The normal approach (as used by the Storming scenario) is to use units in an allied faction. This would remove the need to use an allied unit (which is kind of confusing and removes a faction).

I'm not sure about use cases for non-selectable though.

The new AI in Mandate functions this way. There are actually several trivial ways to implement this. The command part at least. Add a resource that the commands of a unit require, don't put the resource in the game. Boom. Can't ever use the commands. However, I don't understand the purpose of this in MegaGlest because it doesn't have player side AI. The unit would sit there doing nothing. In such a case, why even have commands on that unit?

22

Feature requests / Re: Tags

« on: 3 August 2014, 06:05:47 »

I don't think you provided enough examples to find an error, but why not just use vectors or for_each? Its not like you are calling the code enough to be a performance issue.

23

Feature requests / Re: Tags

« on: 2 August 2014, 04:11:29 »

and maybe even techtrees so you can move factions form other techtrees in and out if they work with the same tags

Since tags are merely strings, yes, they can be moved into other factions. Of course, this does have the downside of no "type checking" (if you typo a tag, you won't be warned), but this is a useful tradeoff (and not the only thing that isn't checked).

You could make a tag list for the tech tree and check tags in the rest of the XML against that. That will prevent types pretty easily. Its barely any extra effort.

24

Feature requests / Re: Tags

« on: 31 July 2014, 03:32:14 »

The sad thing is that what i said was the exact same thing as Jhon.D, Just in another way...

Im happy Jhon. D got the point across but im a little sad it's so difficult to communicate in general.

I think I emphasized more the cross-faction capabilities and how much work it would save in that regard, which isn't really a message that I gleaned from your posts.  If it's there, I missed it.  If I do better at communication, it's because I have a ton of practice at it, and we're dealing in my native language.

Its probable that Titi is simply given John undue weight in discussions for reasons that have little to do with the validity of the specific points in question.

If you're implying favoritism, my track record with feature suggestions in MegaGlest suggests otherwise.  This might be the first one he's ever agreed with.

Its not favoritism exactly. Its more that he respects you even if he disagrees most of the time. Most people don't base their decisions in discussions on the points made but who makes them. Its not something specific to Titi or you.

25

Feature requests / Re: Tags

« on: 29 July 2014, 21:55:19 »

What John.d.h says is the first thing that convinces me  . I am just not sure how many changes this will need.

The sad thing is that what i said was the exact same thing as Jhon.D, Just in another way...

Im happy Jhon. D got the point across but im a little sad it's so difficult to communicate in general.

Its probable that Titi is simply given John undue weight in discussions for reasons that have little to do with the validity of the specific points in question.