Forum index VCMI Project - Heroes 3: WoG recreated
Forum of the project aiming to recreate best turn-based strategy ever!

FAQFAQ  SearchSearch  MemberlistMemberlist  UsergroupsUsergroups  StatisticsStatistics
RegisterRegister  Log inLog in  AlbumAlbum  DownloadDownload

Previous topic :: Next topic
Modding system discussion
Author Message
Warmonger 
VCMI programmer


Age: 27
Joined: 07 Jun 2008
Posts: 1530
Location: Warsaw, Poland
Posted: 2012-02-05, 17:12   Modding system discussion

Today I started writting down the concept of Modding System. The amount of text will grow rapidly, so the article is placed on Wiki for clarity and convenience.

Of course, all suggestions, questions and implementation proposals are mostly appreciated.
_________________
Think twice if you really need to send me private message. Use public forum for general questions.
DJ Warmonger blog
beegee wrote:
Warmonger, you are the best!
Last edited by Warmonger on 2012-02-05, 19:07; edited 1 time in total  
 
 
     
AVS 

Joined: 25 Feb 2011
Posts: 545
Location: Russia
Posted: 2012-02-05, 18:42   

1. Intermediate engine-script layer
Will be good to have exported C (not C++) interface allowing writing mods in almost _any_ language (anyway, I agreed that is enough to have build-in scripting support only for ERM and Python)
2. Direct memory access is often used in ERM, and is not impossible to partially support it by mapping UN:C f.e. calls to safe access to game objects (which by-turn may be implemented in python). I don`t think that it should be implemented by team, but should be stated that it`s possible.
3. Defining all new|modified game object directly in script code may be significantly slow. A suggest use json configs for them.
 
     
Warmonger 
VCMI programmer


Age: 27
Joined: 07 Jun 2008
Posts: 1530
Location: Warsaw, Poland
Posted: 2012-02-05, 20:05   

1. We can always create any number of layers and levels of abstraction, but it's nice to finally have something actually working and useful.
2. Ok, makes sense if you know it by heart ;)
3. Not all behaviour cna or should be defined by set of parameters. Some of them, especially adventure map objects, need to have custom script in form of script.

Also, using script as a universal way of describing mods may be convenient for users. You may clearly tell what happens when you append more scripts to the file, but it's less intuitive what happens when you add more configuration files to already existing pile of configuration files.
_________________
Think twice if you really need to send me private message. Use public forum for general questions.
DJ Warmonger blog
beegee wrote:
Warmonger, you are the best!
 
 
     
AVS 

Joined: 25 Feb 2011
Posts: 545
Location: Russia
  Posted: 2012-02-05, 21:01   

If WoG will be mount as mod for vcmi, vcmi will require SoD and wog data will be repackaged in vcmi mod format?
 
     
beegee 
VCMI programmer

Joined: 12 Dec 2009
Posts: 247
Location: Stuttgart, Germany
Posted: 2012-02-06, 13:16   

I've thought of creating such a thread for a few months, but haven't had time for it. We should talk about this issue thoroughly. It will have a major impact on future development of VCMI.

In my opinion there should be 3 different ways of extending VCMI.

1) Technique: Resource override mechanism. A file called CORC.DEF in folder /Mods/[MOD_NAME]/... overrides original CORC def file for example.
Features: + add/replace animations, bitmaps, music, sounds, campaigns, config files(creature stats)... => even a new town/faction could be added like this way(everything should be layed out in config files,...)

One problem: If two mods want to change in each case one different creature stat(e.g. attack), it will result in a conflict.
Simple solution: a) You should choose either mod A or B. b) File diff tool could merge those different two config files(automatically, at vcmi startup) c) Those two mod developers should work together:)

For config files the add_ prefix can be used to expicitely say that you only want to add a few lines to original config file. e.g. add_creatures.json

2) Technique: Python support only as a CAMPAIGN/MAP scripting language like ERM.
Features: Scripted events(adventure map, battles), simple actions should be possible like the following: give resources from player A to B under XY pre-conditions, teleport hero from location A to B,... don't have enough ideas :)

3) Technique: Extending the core of VCMI. If a modder wants to add reasonable, smaller and mostly non-gameplay-changes like improving the minimap(toogle on/off enemies), adding the possibility to build troops on a new week siege battle then the modder should be allowed to make a branch and then commit this to trunk. This shouldn't be done via Python or CPP Reflection or anything else as such a possibility would be nearly impossible to implement, worrysome, buggy,... Such mods like anything else which differs from OH3 should be made completely optionally. Useful good implemented mods with a high quality(graphical quality too) should be activated by default. (there are shipped with vcmi)
Mid-controversial mods like stack experience, wog features should be integrated in trunk too, but not activated by default.
Controversial mods like re-building a town from scratch which you could done via WOG shouldn't be supported at all in my opinion. As such things would blow up our source code significantly. => they should program a fork of VCMI then...
Features: CPP land. Everything is possible.:) Every change to trunk should be discussed, so you can't work completely independently.

These 3 points should be relatively straightforward to implement. These techniques are robust and simple to understand from a modders point of view. Point 1) should be implemented in a couple of weeks.:), for Point 3) we have to implement nothing specific. A mod browser, conflict checker and such things are needed for point 1 and 3. Python scripts are no real mods, they extend the OH3 MAP format possibilities.
 
     
majaczek 

Age: 27
Joined: 12 Jun 2008
Posts: 474
Posted: 2012-02-06, 13:37   

begee I agree mostly but (1) and (2) should be proxied through nice mod system, so uninstalling a mod wouldn't be a hell, changes will be grouped into packages to maintain a whole package at a time, and to be posssible to enforce compability between clients while still allowing for skinning.

I agree mostly for (3) but i think it should be splitted between things that gets incorporated into client/server executable and things added via dynamic libraries (.dll, .so) like new AIs and all things that can be easily mounted into engine without to have recompile client/server executable
 
     
AVS 

Joined: 25 Feb 2011
Posts: 545
Location: Russia
Posted: 2012-02-06, 13:46   

Some interesting links:
http://forum.df2.ru/index.php?showtopic=26467 new version of Era - 2.0 ENG (most interesting is that WoG is now a plug-in)

http://wogarchive.ru/file.php?id=189 full sources of WoG.
 
     
AVS 

Joined: 25 Feb 2011
Posts: 545
Location: Russia
Posted: 2012-02-06, 13:55   

beegee wrote:


1) Technique: Resource override mechanism.


2) Technique: Python support only as a CAMPAIGN/MAP scripting language like ERM.



1) nearly all new factions|towns adds new creature abilities at least - impossible to implement w|o programming.

2) IMO if we support such language like python, we can rewrite _all_ mechanics in it. Only time-critical parts should remain in C++ with the lapse of time.
 
     
Ivan 
VCMI programmer

Age: 25
Joined: 08 May 2009
Posts: 1438
Location: Ukraine
Posted: 2012-02-06, 14:36   

@AVS
1. I'm actually against this. Python (or lua) + ERM (for WoG compatibility) should be more than enought for most modders + less languages we have more easier creation of guides, examples, support, etc will be.
3. Agree with this one. Configuration files are more easy to edit + at some point we'll be able to add some gui for it.

Checked wiki:
@Mod system proposal
Conversions - _may_ be possible to replace with incomplete config files. Graphics can be replaced on filesystem level (can be done with beegee's system)

Language - python is OK but what about lua? IIRC it is used in HoMM5 and gaming in general - so some modders may know it already.

New map format - care to fix the red link? ;)

Scripts online - what about separating server-side and client-side scripts + allow some interaction with them like sending python data structures over network? Will work in both Single and Multi as long as mods are in sync.

@Packages
main file IMO should be JSON which specify language, script files (if any) along with name, version, description, etc.

New objects:
Json may be better here - I don't like specifying name\description\images in code. For complex objects modders may specify name of python class with required actions.
Some of our c++ classes can be rewritten in python - will work as examples for modders + allow some un-hardcoding of mechanics.

@Mod handler
Apart from prerequisites there should be list of conflicting mods.

Object identifiers - numeric ID will be needed for SoD objects but what about using strings as ID instead of number at least for objects added in mods:
WOG.creatures("supreme archangel")
this ID should either match name of python class or specified in config file. (separate from readable name to allow localization). May even work with subID's. For example new object with id = "Mine" and subID="Mithril" can be added by engine with same ID as H3 mine but new subID.

@ERA
Looks to be simple resource overriding. We'll need more than that. Nice mod BTW.
 
     
majaczek 

Age: 27
Joined: 12 Jun 2008
Posts: 474
Posted: 2012-02-06, 14:52   

@Ivan@scripts_online
i was first (see wiki discussion) but of course totally agree
 
     
AVS 

Joined: 25 Feb 2011
Posts: 545
Location: Russia
Posted: 2012-02-06, 14:53   

@Ivan
Quote:
Object identifiers - numeric ID will be needed for SoD objects but what about using strings as ID instead of number at least for objects added in mods:
WOG.creatures("supreme archangel")

If use string IDs we should be of format.
Capital case with "_" and w|o spaces, camel case etc. Or engine should handle most of all cases ("supreme archangel"="supreme_archangel"="SupremeArchangel" ...)
 
     
Warmonger 
VCMI programmer


Age: 27
Joined: 07 Jun 2008
Posts: 1530
Location: Warsaw, Poland
Posted: 2012-02-06, 18:31   

Thank you for your contribution, this discussion makes more sense than I expected :D

Quote:
Language - python is OK but what about lua? IIRC it is used in HoMM5 and gaming in general - so some modders may know it already.

1. Lua is popular, but already obsolete. It doesn't seem to be developed much further.
2. Python has more advanced features, like explicit class and metaclass support, which may be useful for modding.
3. Python comes with tons of documentation, examples and rich library in case you may need to write something ambitious.

Lua implementation in H5, for example, was just a set of fixed functions... and you couldn't go beyond them with your own code.

Quote:
main file IMO should be JSON which specify language, script files (if any) along with name, version, description, etc.

I agree with that. Json files may be easier to scan and manage in first place.

Quote:
Scripts online - what about separating server-side and client-side scripts + allow some interaction with them like sending python data structures over network? Will work in both Single and Multi as long as mods are in sync.

That makes sense in general, but there's an issue: client-side scripts (GUI) which result in change of game state, such as garrison drag-and-drop. This must be done in a smart way and I can't help much with network programming.

Quote:
Json may be better here - I don't like specifying name\description\images in code

Well, I believe some definictions can be conditional or generated at run time - for example, in a middle of a map you may want to create new artifact depending on player's choice. Or multiply certain type of creature, each with new abilities.
_________________
Think twice if you really need to send me private message. Use public forum for general questions.
DJ Warmonger blog
beegee wrote:
Warmonger, you are the best!
 
 
     
beegee 
VCMI programmer

Joined: 12 Dec 2009
Posts: 247
Location: Stuttgart, Germany
Posted: 2012-02-07, 13:30   

Quote:
I agree mostly but (1) and (2) should be proxied through nice mod system, so uninstalling a mod wouldn't be a hell, changes will be grouped into packages to maintain a whole package at a time, and to be posssible to enforce compability between clients while still allowing for skinning.


Every mod resides in its own folder under [game_dir]/mods/... Uninstalling shouldn't be a problem. Original files remain unchanged.

Quote:
I agree mostly for (3) but i think it should be splitted between things that gets incorporated into client/server executable and things added via dynamic libraries (.dll, .so) like new AIs and all things that can be easily mounted into engine without to have recompile client/server executable


For AI it may be OK. Client/Server/Lib executables shouldn't be replaced by mods. This would be the false direction. How to support several mods instantly then?

Quote:
nearly all new factions|towns adds new creature abilities at least - impossible to implement w|o programming.


No problem. You can use both point 1(resource override) and point 3(changes to trunk).

Quote:
IMO if we support such language like python, we can rewrite _all_ mechanics in it. Only time-critical parts should remain in C++ with the lapse of time.


AFAIK python can be connected with C with just a macro in the class/function definition. So calling a C++ function from Python shouldn't be a problem. The big problem is that we have to define places in VCMI code where we are likely to expect an addition to the normal behaviour(invoke predefined python methods from cpp). This can be a major task. Don't know if data type conversions will cause trouble. It would be nice especially for this discussion if someone could look how VCMI CPP/Python Integration could be done. Which steps are necessary exactly to call a function from cpp and the other way round? Where are performance bottlenecks? Which other risks are there? How could a creature ability be added? What is easily possible, what takes more work?
Developing mods in Python, than directly in c++ is more complicated as there is one additional layer anyway. Python as a map scripting language seems to be quite fine, but don't know if it makes sense to introduce gameplay changes which affects lib, client, server and ai.

Quote:
Some of our c++ classes can be rewritten in python - will work as examples for modders + allow some un-hardcoding of mechanics.


This makes sense. We should define a limited set of method declarations which can be overriden by Python mods dynamically. That methods have to be invoked from VCMI Core at specific positions.
Last edited by beegee on 2012-02-07, 14:14; edited 1 time in total  
 
     
AVS 

Joined: 25 Feb 2011
Posts: 545
Location: Russia
Posted: 2012-02-07, 13:51   

About defining objects in python:
RMG & map editor shouldn`t have dependency on python engine. Every object in mod should be accessible w|o executing scripts.
 
     
Ivan 
VCMI programmer

Age: 25
Joined: 08 May 2009
Posts: 1438
Location: Ukraine
Posted: 2012-02-07, 14:59   

Quote:
That makes sense in general, but there's an issue: client-side scripts (GUI) which result in change of game state, such as garrison drag-and-drop.This must be done in a smart way and I can't help much with network programming.

- Give to scripts access to CCallback - will allow client-side scripts to safely modify game state just like in our C++ gui code.
- For interaction between client and server parts of mod something like this should work:
1) on client convert python data to c++ string (in scripting system wrapper)
2) client sends message (modID + string) to server
3) convert c++ string back to python data on server
4) pass received data to python script on server

Quote:
It would be nice especially for this discussion if someone could look how VCMI CPP/Python Integration could be done

I know that there is Boost.Python which may work for us. Don't know anything about this lib though.
Quote:
Developing mods in Python, than directly in c++ is more complicated as there is one additional layer anyway. Python as a map scripting language seems to be quite fine, but don't know if it makes sense to introduce gameplay changes which affects lib, client, server and ai.

Asking modders to use C++ is even worse - it almost requires some computer science knowledge. Writing every ability in C++ by VCMI devs isn 't an option too.
Using python for gameplay mods shouldn't be *that* difficult - we already have clearly defined events (net packs). All we need is way to pass this events to scripts.
For example some kind of "Random encounters" mod will have script attached to "Hero moved" game event and will be triggered by engine each time a hero moves.
 
     
Display posts from previous:   
Reply to topic
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum
Add this topic to your bookmarks
Printable version

Jump to:  

Powered by phpBB modified by Przemo © 2003 phpBB Group
Template Chronicles modified by Nasedo modified by Tow.
© VCMI Team
Page generated in 0.09 second. SQL queries: 12