Modding and Modularity (Full Version)

All Forums >> [New Releases from Matrix Games] >> Distant Worlds 1 Series >> Design and Modding



Message

Erik Rutins -> Modding and Modularity (7/1/2014 1:22:58 AM)

Hi everyone,

Elliot and I have been discussing the new features we've added since the release of Universe and what the modding community is most interested in. We were wondering about the importance of modularity as brought up by Locarnus vs. the importance of just extending the possibilities of what can be modded. We are very much interested in your input to this discussion.

Thanks in advance for your thoughts.

Regards,

- Erik



Shogouki -> RE: Modding and Modularity (7/1/2014 1:35:02 AM)

Glad to see this brought up! Hopefully some good input and ideas will come from it.



elvendeathknight -> RE: Modding and Modularity (7/1/2014 1:58:44 AM)

I prefer the extension of possibilities of what can be done. I'm working on a mod that will never be published and will only be used for my own pleasure. I don't need it to be "compatible" with every mod ever published.

After reading Locarnus' posts, I understand that he expects that every modable parts of the game should easily fit in any mod. I think it is not realistic considering the amount of changes one can make. I personnaly like the recend addition of the research order, which fits perfectly with the ship templates.

If I want to incorporate bits of another mod, I can always open that wordpad and make the modifications myself. We are only talking about changing values in a text editor.



Franky007 -> RE: Modding and Modularity (7/1/2014 2:10:18 AM)

The research tree, the components, the wonders and races are all linked together; i don't see how they could be made completely modular.

I would prefer improvements in other area before spending too much time on this.



Unforeseen -> RE: Modding and Modularity (7/1/2014 2:21:15 AM)

I'm sorta in the gray area as far as this most recent change. I'm not really a fan of the concept in the first place, as setting a static research order just doesn't really seem like the foundation for an interesting game. At least not in the way that keeps me playing. Any mod that incorporated this feature in it i would probably have to edit and remove the changes. And certainly i do support modularity over overall modding potential in this case. I like to be able to choose what mods i want and add them seamlessly into my game, and easily remove any mods i don't like from compilations without breaking them or causing myself to do EXTRA work to get them compatible.

..On the other hand i respect the desire to enhance the capability of modders. The more capability one has to change the game, the more they can drive the game in the direction that they PERSONALLY want it to go/be. I'm still swaying more towards the modularity side of this regardless though, as i don't really like this particular feature addon for my personal tastes and it is going to cause the modder of one of the best mods in development right now to quit. A mod i personally view as must have. I may actually try and revert to a previous version of DW and Extended, forsaking the bug fixes and future development so that i can play with Locarnus's Balance Mod. Even if its just version .87... [I wont do this with Orange Mod, That mod will continue it's regular development once the patch goes live and extended is updated.]

Anyways, that's my take on it.

Edit: I do think that with a little bit of extra work it is entirely possible to make any version of the balance mod compatible with any mod using this feature. It's just ALOT of "little bit" of extra work and may require coordination between modders...something they may not be willing to do...



Tanaka -> RE: Modding and Modularity (7/1/2014 2:49:15 AM)

I would like to use this mod: http://www.matrixgames.com/forums/tm.asp?m=3630680 (More (& Rebalanced) Wonders Mod) but I cannot use it if I want to use another research mod.

"A small modification in the tech tree was necessary (again ... WHY ?!, the tech necessary should be in the facilities.txt !) so this is incompatible with mods altering the research.txt file."

Is there a way to make these separate? Is that what you mean? If so then that would be great!



Shogouki -> RE: Modding and Modularity (7/1/2014 3:00:54 AM)

I'm rather torn on this issue like Unforeseen. I think ultimately I just want what will encourage the best growth and longevity for this mod community.



necaradan666 -> RE: Modding and Modularity (7/1/2014 3:06:48 AM)


I believe it's up to the game to be as open to modding as possible for ALL USERS, someone wanted that latest feature added didn't they?

The way Themes are separated into their own folders means that there is NO NEED for compatibility. So it's up to the individual modders to decide if they want to make their mods compatible with every other mod under the sun and adjust their files to each others standards accordingly, if that is what all parties are interested in. If some modders don't want to coordinate I guess you just have to see to your own mods and release them on their own merits rather than the fact that they're compatible with 'must haves'

And Locarnus vehemently wanted reactors adjusted for his mod's sake and was accommodated twice but quits when someone else's request goes through? Just because it makes his mod .. not unusable on it's own, just incompatible with others. Bad form old chap.



Sithuk -> RE: Modding and Modularity (7/1/2014 6:17:08 AM)

I don't know enough about the detail of the issues. Can one of the more experienced modders post the main issues and their recommendations to resolve them?

There is likely to be only so far that the mods can be made compatible with one another. Are the modders asking for a greater number of separate data files to reduce the risk of conflicts between files?



hewwo -> RE: Modding and Modularity (7/1/2014 6:19:21 AM)

Yeah, I'm also thinking, more modding options is better than not having them just for the sake of modularity. Its a bit of work to integrate stuff perhaps, but I'm sure we'll just... do the extra work and the game will be better for it in the end. So, don't stop adding modding options just because peoples gut reaction to change is negative, and don't get too influenced by a vocal minority on the forums promoting their cause with extra large font size! (speaking of which, I want my filters to be remembered when I close/open a screen:p)



Sirian -> RE: Modding and Modularity (7/1/2014 10:09:55 AM)

In principle, I would appreciate more modularity when modding.

The question is, how far would the modularity go and how much effort on your side would that mean? Lets take wonders and research for example. We have facility and wonder descriptions in one file and research project description in another file. In a perfect world, each file would contain only information used in its scope of authority and no other information. That means, the facilities file would only describe facilities (how they look, what they do, how much they cost...) and the reseach project file would only contain information about research projects (dependencies, cost...)

But what about the information that ties these two entities together? Facilites definity do need a connection to the research projects that unlock them. At the moment, they are linked by ids, meaning we use information that belongs to a different scope. Since we are trying to decouple the information "kingdoms", how will the links be implemented? Will they be put into the research file or the facilities file? Or a third file? They must be somewhere.

If it would mean we get links that have a descriptive nature rather than an id number, I am all for more modularity. A link that says:
this facility depends on the research project that...
- lets you build [whatever component or troop or ship type].
- lets you colonize this planet type
- lets you build ships of xy size
- increases your research/mining/docking rate to xy (or above)

That would be totally awesome.



Osito -> RE: Modding and Modularity (7/1/2014 10:23:46 AM)

Personally I think it's far more important that different mods can work together. Extending modding capababilities is good for people who want to create a mod for their own use, or for someone creating a total conversion, but it makes it much more difficult to bring together several existing mods (in fact, that's already difficult enough as it it). For example, at the moment we're seeing mods that:

1. Change the races (Haree's mod, which is pretty much regarded as 'vanilla' by many).
2. Change the resources.
3. Change the graphics for the resources.
4. Change the UI.
5. Change the energy tree.
6. Change the colonisation techs.

and so on.

Without good modularity we often have to choose which mod to run, and can only run one at a time. If anything, I would recommend you look at improving the existing modularity to make it easier for people who are modding different aspects of the game to make their mods compatible with other mods.

Having said that, I still think the game editor could use some work ;-)

Osito



Efaferal -> RE: Modding and Modularity (7/1/2014 2:07:10 PM)

I am strongly in favor of modularity. What I have seen of DW it feels very well crafted to this end. However as content is added by the developers and modders the chain of dependency gets rather complicated. If the community and developers want to continue to expand this project there will have to be some architecture to define how the modules fit together and a system for tracking compatibility- either in or out of the DW code base.

I think the principle we would appreciate from the Developers is that any future change which creates dependencies between the content be added as a new module/file. Case in point: the 'Research Path' addition. This is a brilliant addition but creates a new dependency between race and research. Therefore the implementation needs to be in a new file/table so a race.txt can be put in any mod base but the research path will depend upon the combination of tech and race of a given mod. (Sort of like a Db creation exercise)

To support the modularity, the 'holy grail' would be a content editor suite which allows creation of in game content like research techs, create the appropriate links to graphics/components/facilities/etc. or fix missing/broken links, and save out with a version and theme tag.








Hannable -> RE: Modding and Modularity (7/1/2014 4:05:41 PM)

I'm going to vote for modularity, as well.

The reason is because some mods are just slight changes or tweaks but have to be placed in its own theme. Who really wants to give up Distant Worlds Extended or the Balance mod for a small tweak no matter how good that tweak is? I wanted to use the Colonization mod but couldn't unless I pitched DWE. I tried adding the Colonization changes to DWE but quickly became mired in "where does this go?" and "should I delete this part?" and decided meh ... I want to play the game, not spend my free time dealing with crashes and missing entries.

Bottom line is that having more modding features doesn't help much if the new mods created with them have to replace, rather than integrate with, older mods that we enjoy using. The only choice for the end user is to get in there and edit the files ourselves to make them compatible - but that's harder than it seems. Messing around with other people's work without understanding what's happening under the hood can result in lots 'o crashes.

So yeah, I think modularity is the way to go.



mensrea -> RE: Modding and Modularity (7/1/2014 4:31:43 PM)

As long as updates or the addition of new features are not breaking old mods Minecraft style I am all for new options over modularity. And even if you add features that completely break a mod, if they were something revolutionary or game changing I would rather have them and completely rebuild my mod then not have them. You will probably never design a system that makes drastically different mods modular and the onus of that burden will always fall on the modder to make things work together if they so choose. Even with well developed modding systems like the ones implemented in Skyrim and Fallout you inevitably encounter incompatibility warnings between some mods.

I don't really understand how this has gotten to this point as unless I am sorely mistaken the tech mod still works fine and the only issue is that if some race mod does decide to use the new racial tech modding features the race mod and tech mod will no longer be compatible. In that case the solution to me seems simple: you branch the race mod and run two versions, one which relies on the vanilla tech tree and one that relies on the expanded tech tree. Yes its extra work, but its not like we are working with java or C++ or something.

If anything members of the community need to devise their own standards for modularity because to me those sorts of things have to be done at the bottom not imposed from the top. We can settle on our own standards, assemble mod packs that take disparate mods and make them interchangeable and coherent, etc. I honestly don't think its a valuable use of a developers time to do that sort of stuff as you guys have access to the real code and can make changes to that, so I expect new features from you, not community organization.

And to put things in perspective here I'm not just talking out of my ass and trying to be the tough love guy. I designed this mod https://github.com/mensreaMC/Deus-Ex-Machina only to have it continually butchered by mojang through machine gun fast updates. So I know how it feels to have to start over and lose hundreds of hours of work. I'm afraid it just comes with the territory and we have to accept that part of the otherwise rewarding and engaging process of modding are the occasional setbacks and heartbreaks.



Locarnus -> RE: Modding and Modularity (7/1/2014 5:03:59 PM)

For the 1.9.5.4 modding feature (specified racial techs in the research.txt) add a new

config-races.txt

In this file there could be a section called something like "research-to-racial" containing a variable "res-race-tech" followed by a dummy variable.
eg 
research-to-racial:
res-race-tech=0

would deactivate all the racial bindings in the research.txt

So if I as a research modder define that a tech is only usable by a certain race, the 0 would make those techs available to all races. If the value is set to 1, the racial techs are in effect. If the value is set to 2, those special techs get deactivated for every race to avoid making OP racial techs available if those are not used.

It is not a solution, just a workaround. It would allow racial modders to use a specific research.txt without the modularity killing parts. They would just need to deploy the mini config-races.txt to make it compatible.


The other way around for the 1.9.5.5 modding feature (detailed research order in races.txt). As a research modder I would deploy a

config-research.txt

which could look like that 
racial-to-research:
race-res-tech-order=0

thus deactivating the precise research orders specified in the race.txt files.


As said before, far from a solution.
But modders can concentrate on their areas (with opportunity costs of not using the incompatible features) while the features stay .
And maybe one day, when the seperate mods are matured, "total conversion" mods might combine them, including the modularity incompatible modding features.

edit:
Or you could make the research orders of 1.9.5.5 seperate files, as Efaferal suggested. It would have the benefit that the orders can be shuffled around easily and just copypasted/renamed for different races:

quote:

ORIGINAL: Efaferal

I am all for the research paths improvement. Right now the 'dynamic' ( random ) AI research ends up researching non essentials and doesn't coordinate well with the ship design templates.
I think the research paths should be a separate file so partial mods will continue to work.





judahpeter -> RE: Modding and Modularity (7/1/2014 8:27:50 PM)

I would suggest taking the "BEST" community mods that most people really enjoy (maybe a vote) and making it part of the "Vanilla" game. :) Then there isn't so much a need for mods or modularity. Am I out of touch with this?



mensrea -> RE: Modding and Modularity (7/1/2014 9:02:01 PM)

Nah man, there's a definite need for mods. They attract more people to a game and increase the replay value for anyone that uses it. From a business perspective alone the ability to mod a game is valuable. Personally all the best games I have ever played were highly modded.

That being said mods are a lot like multiplayer; a lot of people don't care about them or will just never bother with them. To each their own.

Locarnus's work around suggestion sounds great and relatively simple but then again I'm not the guy doing the coding and I don't even know what language this game is written in (could the coder reveal that by chance?).



judahpeter -> RE: Modding and Modularity (7/1/2014 9:09:54 PM)


quote:

ORIGINAL: mensrea

Nah man, there's a definite need for mods. They attract more people to a game and increase the replay value for anyone that uses it. From a business perspective alone the ability to mod a game is valuable. Personally all the best games I have ever played were highly modded.


I wasn't talking about removing mods or the ability to mod, just ADDING the best and most popular to the actual game so that those are integrated. Once this window of opportunity is over, then its just adding mods from this day forward.



mensrea -> RE: Modding and Modularity (7/1/2014 9:35:39 PM)


quote:

ORIGINAL: judahpeter
I wasn't talking about removing mods or the ability to mod, just ADDING the best and most popular to the actual game so that those are integrated. Once this window of opportunity is over, then its just adding mods from this day forward.


Ahhh, ok, I misunderstood you there. I agree about adding some of the best mods to vanilla. I wouldn't mind seeing the extended tech tree, extended race, balanced wonders and eventually (hopefully) the AI improvement mod added to the game. From the sounds of it on the forum some of these mods are considered essential, anyway.



Imperius -> RE: Modding and Modularity (7/2/2014 2:43:20 PM)

I'd be more interested in what can be modded.

For example Crusader Kings II I've worked with extensively, and there are some great total conversion mods for it. I like what Distant Worlds has done so far, it is extremely modder friendly, but the events for custom scenarios could use a handful of more features.

A trigger set by a certain date for example, would be extremely useful. Ie, year 2150, a massive alien invasion happens. It's too random to base it on exploration, tech, or appearance of characters for my tastes.

Also the ability (if possible) to change empires in the editor; for example first you make one empire, design and place ships and such, then you switch over to another one and do the same for when creating custom scenarios.

And finally, the ability to change the galactic date also in the editor; most sci fi scenarios do not start in the year 2100 :)




mensrea -> RE: Modding and Modularity (7/3/2014 5:42:44 PM)

I did think of one thing that would make it easier for modders who work with techs, components and resources.

Right now the lists work like this

129, missile tubes, yada yada, so on so forth
130, laser beams, yada yada, so on so forth
131, solar panels, yada yada, so on so forth
132, cyclone torpedoes, yada yada, so on so forth

Now if I add a 134 to that list it fails to work because there's no 133. However, what if instead of crashing when it doesn't find 133 it just skips it and looks for 134. This would enable modders to claim blocks of IDs for their mod which wouldn't conflict with the ID's in other mods. So when a player wants to use both mods all they have to do is a little copy pasta instead of reconfiguring every ID (which would then break the paths with anything calling on that ID).

That would apply to techs, components and resources as well as pretty much everything that uses ID's. Sure, modders will have to decide what range of ID's they lay claim to, but we could collaborate on that and keep track of whos got what in a sticky in the modding section.

Even if this is something that's not possible to do with this engine it would be great to have in the next DW.



Rhikore -> RE: Modding and Modularity (7/3/2014 6:47:22 PM)

E & E, thank you guys so much for the work you've been doing and for an overall epic 4X.

Regarding Modding and Modularity:
I have to vote with the majority here, More options = More Customization = Better Game = More Fun.
Players that are troubled by incompatible Mods could simply investigate the issues and solve them themselves with little trouble.

Characteristics:
I would really like to see Characteristics Values become an Average Composite of the Sub-Characteristics.
Thusly requiring the Sub-Characteristics to receive a modifiable numerical value in the range of the Current Main Characterisitics.
Having the ability to specifically mod sub-characteristics would provide much greater racial uniqueness and a certain sense of vivaciousness to the game.

Racial Balance:
Effort made to provide a racial bonus metric would be great...

(Copy/Paste from another Thread)
"Hey Guys, Ill be working on a race mod soon, hopefully, and was wanting to address balance across governments and races.

I think the best way to do this would be to create some basically "blank" races with one bonus.
Equalizing Pop Growth across all Blank races, except for the Race intended to test the efficacy of Pop Growth.

All bonuses would have to be of the same percentage or equivalent point values.

Then run tests with said races, using a special map, or editing home systems for control, providing identical environmental factors.

After a good sample size, we should be able to create a racial Bonus metric, by which we can balance the races.
This metric could also be used to balance government types.

... Yada Yada."

Wonders:
I personally would like to see the power of Wonders diminished, and racial exclusivity relinquished, yet allow for 1 type of Wonder per System.



I would appreciate feedback, and some verification that youve seen this post if at all possilbe.

Keep up the good Work, and God Bless.





Unforeseen -> RE: Modding and Modularity (7/3/2014 6:59:20 PM)

It's not really the majority, the voting is fairly even.



Rhikore -> RE: Modding and Modularity (7/3/2014 7:01:57 PM)

@Unforeseen, My bad, I was posting from memory of the last time I read the post.
Any comments on my suggestions?



Unforeseen -> RE: Modding and Modularity (7/3/2014 7:06:45 PM)

I'm not really much of an expert when it comes to mechanics to be honest, but i do agree that wonders should not be racially exclusive. I'm not really a fan of racial exclusion at all to be honest.



tjhkkr -> RE: Modding and Modularity (7/3/2014 8:29:35 PM)

I think greater modding capabilities; modularity would seem to be difficult at best given the diversity of themes and events for the respective mods.



BigWolfChris -> RE: Modding and Modularity (7/3/2014 8:49:34 PM)

Greater modding capabilities are a must to me
Modularity would be nice, but due to the nature of how things are stored (text file for each part), it'd become a headache

When tools start popping up that assist in modding, we'd probably find popular mods having conflicts with other popular mods anyway, such is the case in most modding communities

Having it truly modular would require alot of rebuilding of the game code I would think



ParagonExile -> RE: Modding and Modularity (7/3/2014 10:56:36 PM)

Why not both? :3

[image]http://x4.fjcdn.com/comments/3700959+_b18e6ed1071bfada62ff7a6e829d7b25.jpg[/image]



Solarius Scorch -> RE: Modding and Modularity (7/31/2014 3:00:47 PM)

quote:

ORIGINAL: mensrea

I did think of one thing that would make it easier for modders who work with techs, components and resources.

Right now the lists work like this

129, missile tubes, yada yada, so on so forth
130, laser beams, yada yada, so on so forth
131, solar panels, yada yada, so on so forth
132, cyclone torpedoes, yada yada, so on so forth

Now if I add a 134 to that list it fails to work because there's no 133.


That's because DW runs on numerical IDs. Most games I've modded in my life (mostly Civilization: Call to Power and Openxcom) use strings instead; for example you'd have STR_MISSILE_TUBES instead of 129. That's much more comfortable, since you always know what you're dealing with (the only downside is slightly larger text files). But I guess this would be too much of a change to ask for.

Now, regarding the files' intertwining: I've always found it rather confusing how racial techs or wonders are. Perhaps it would be clearer - and more modular - if we had each race's special research externalized to separate files? So you'd have a folder named "racialtechs", and inside - racial files, much like the policy files: human.txt, dhayut.txt and so on. Each of these files would contain:
- Special research available to the race,
- An option to disable certain research from the main research file for this race.
The same could be done for other stuff, like wonders (a separate folder for each aspect).



Page: [1] 2   next >   >>

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.40625