next »

[absolutely]

Please read this article on the wiki:

http://openwar.bartvanheukelom.nl/wiki/index.php/Specifications#Game_Modules

Then come back here and vote. Don't vote if you're not absolutely sure of your choice, as this is an important decision.
Also, please post here and explain your choice.

The "not modular" option is simply a waste of our time.  I'm for fully modular, myself.

The "not modular" option is simply a waste of our time.

i know, but it's still an option, for completeness' sake

I'm with Darvin.

Fully Modular is like Neverwinter Nights. It may break a few games when updates are made, but after nearly 70 patches, NWN is still popular because of it's toolset and active modding community. Sure, I make no assumptions that we can magically make our game just as popular, but NWN proves the system certainly works.

Solinx

A bump to this forgotten topic:

I've come up with a solution for shared resources (which is a part of the modular structure debat), as far as the theory is concerned at least. It's quite simple:

I say share the resources. I would have said it before, but I had no answer for the questions above, now I have.

The question is simple: How does the game know if a resource is shared?

The answer is simple too: Tags, File tags and Module tags.

File tags? Well, filename, size and creation date should be sufficient to determine if a resource file is the same.

Why module tags? And what are they? Let's start from the beginning, with the installation of two modules that use the same resource file. Each resource file that is installed with the first module gets a module specific tag. When you install the second module, the game will notice that the shared resource file is already present in your module resources folder.

Instead of overwriting the file, or doing nothing at all, it would add a tag to this resource, marking it for the engine, that the file is used by module x and module y. With the uninstallation of module y, the engine will check the tag lists of the resources and notice that one resource is shared with module x. It will then remove the y tag from that resource file, but leave the file itself intact on the hard disk. Only when both modules will be uninstalled, the shared resource will be removed too.

Each resource file would need to have at least one module tag, the one of the module it got installed with. These tags could also be used to create a standard uninstaller for modules, the more so if the use of them is extended to all files that come with a module.

Simple, but effective.

The wiki page:link

Now that was the theoretical part. Could you tell me if it can be done like that?

Solinx

now really, when are two games going to use the same resource? i'm against this modular setup. modules should be limited to an original game and it's mods

- it's overly complicated to program
- game developers will much faster use resources from others, which will reduce originality
- if one game decides to change a resource in a patch, what will the other game, that depends on it, do?
- what about different engine versions? what about people adapting the engine?
- what are the gains?

as i see it, we should do it the battlefield way:

- the game engine is in it's own folder (1 game engine for every game)
- the game content is then a module in this engine (however, games by other developers, are not)
- expansion packs and mods for the game, are also a module
- games by other developers, have their own copy of the engine (which will be less than 5% of the total game size), completely independent, in it's own installation folder. it can even be 200% modified

and if you insist on shared resources (which, i think, is a bad idea), that's still possible with this setup

In terms of complexity, the tag system Solinx brings up would definitely get the job done.  You wouldn't even need to store the tag inside the file, just have an aptly named "filename_tag" text file in the same folder containing all its tag information which is read whenever the resource is going to be removed or updated.  I do agree that updating a module will definitely provoke the most difficult scenario, but worst-case you leave the old version in place and remove the tag to the game that no longer uses it, then add in the new version.

We should AT LEAST have object libraries of commonly used public resources so that modules can share them.  Frankly, if you're not going so far as to create your own stand-alone game, I would not hold anyone against importing a standard terrain and environmental objects library.  Nor would I hold anyone making something like a "First Age" game against using Nisyrran and Balkurn models where appropriate.  If it's a good resource, why bother making an original that's just going to look roughly the same when zoomed out?

Mind you, I think you've left a critical grey zone for people who are making something above the common mod, but below a stand-alone project.  These are the kind of people who won't touch the engine itself, but also will be making something unique and different from any existing game.  Is it fair to say they have to be a module of such-and-such?  I think that, should we succeed, there will be a strong "Open War" modding community that is not specific to any open war game, just the engine itself.  I envision libraries of public resources contributed by modellers, which are then utilized in a wealth of semi-professional works.  I do think we need to accommodate this.  It's not that they're being unoriginal, it's that they're amateurs, and they don't have the manpower or even willpower to make terrain textures when it's already done for them.  Those who enjoy these wealths of mods should not be penalized for having 40 or so on their computer that use the same global resources.

In terms of complexity, the tag system Solinx brings up would definitely get the job done.  You wouldn't even need to store the tag inside the file, just have an aptly named "filename_tag" text file in the same folder containing all its tag information which is read whenever the resource is going to be removed or updated.  I do agree that updating a module will definitely provoke the most difficult scenario, but worst-case you leave the old version in place and remove the tag to the game that no longer uses it, then add in the new version.

the same question arises..is it worth it?

We should AT LEAST have object libraries of commonly used public resources so that modules can share them.  Frankly, if you're not going so far as to create your own stand-alone game, I would not hold anyone against importing a standard terrain and environmental objects library.  Nor would I hold anyone making something like a "First Age" game against using Nisyrran and Balkurn models where appropriate.  If it's a good resource, why bother making an original that's just going to look roughly the same when zoomed out?

ok, so we can do a library of commonly used resources, i agree with that now, but my main point against the fully modular system is dependencies. as such, objects in the library should not be changed (not under the same name), and each game will still have it's own copy of the engine (except mods and expansion packs, which will run on the engine of the mother game)

Mind you, I think you've left a critical grey zone for people who are making something above the common mod, but below a stand-alone project.  These are the kind of people who won't touch the engine itself, but also will be making something unique and different from any existing game.  Is it fair to say they have to be a module of such-and-such?

they can copy the source game, and change what they want, then release it as a seperate game

Alright, this is a though topic.

The question is: Who do you want to work with the engine?

Do you want only professional people to work with the engine? Or do you want to make it available to high skilled amateurs, comparable with the good modders of BFME 2. Or do you want the entry skill of modding / creating a game with this engine to be like the Sage engine?

Perhaps we should have done this earlier, define our non-player target group.


Personnally, I prefer the engine + game combination to be open for people with the skill to mod a few weapon changes into BFME 2. Yes, that open. Not easier than BFME 2, but no harder either. This, of course, is the lower limit. The higher limit will go beyond BFME 2, since the engine will allow a complete game to be made, by very skilled amateurs, or professionals.


Now back to the discussion point, shared resources.

- Complex to program.

In terms of complexity, the tag system Solinx brings up would definitely get the job done. You wouldn't even need to store the tag inside the file, just have an aptly named "filename_tag" text file in the same folder containing all its tag information which is read whenever the resource is going to be removed or updated.

Thanks Yes, there would be a need to have a tag file for each resource file. It could be done as a file for each module, but then the files of all modules would have to be checked with each uninstallation. Adding a tag to the resource file itself would indeed be complex with all the various filetypes possible.

- if one game decides to change a resource in a patch, what will the other game, that depends on it, do?

I do agree that updating a module will definitely provoke the most difficult scenario, but worst-case you leave the old version in place and remove the tag to the game that no longer uses it, then add in the new version.

You just gave the answer yourself. If there is to be an update, the file needs be unpacked again from some source. The updated file is no longer the same as the shared file, so it will be located in another folder. One tag of the previously shared file will be removed, as the file is no longer shared.

- Game developers will much faster use resources from others, which will reduce originality

True, in a sense. The question is, what will be the long term effects? Will everyone really be so plain to use the exact same resources? I think not.
Shared resources stimulate the growth of a community, especially early on, it adds to the social atmosphere. And as with open source communities, a modding community lives on as long the participants are having a good time.

With shared resources, some people just make resources, without a game or mod. They are pure artists and want to show their skill, help people, want to learn new skills, but can't make a game or mod, or just don't want to.

- what about different engine versions? what about people adapting the engine?

Yes, there will be those who adapt the engine. If they do that, they will have created a new engine, based on our engine. It is logical to me that their engine is no longer bound directly too the official engine, and thus will have it's own installment.

As for the patches. Versions of the official engine could be separate installments too, or they could be applied like to any other game, depending on the size, amount, effect and impact of the changes. Going from version 1.1 to 1.2 could be a separate installment, going from 1.2.3 to 1.2.4 would be an patch without a separate installment.

Or, and this I prefer, we could give the players the option during the upgrade. At which time the engine would run a rough check as to which things would stop functioning. My doubt is if this is possible.

- what are the gains?

Well, you already know the technical gains, saving harddisk space, etc. and I told you about the social aspect, and the standalone artist input. My question: What is to loose?

Before you go on answering that question, read on abit.

as i see it, we should do it the battlefield way:

- the game engine is in it's own folder (1 game engine for every game)
- the game content is then a module in this engine (however, games by other developers, are not)
- expansion packs and mods for the game, are also a module
- games by other developers, have their own copy of the engine (which will be less than 5% of the total game size), completely independent, in it's own installation folder. it can even be 200% modified

Very well, the system you describe is certainly a good one.

From what I understand, all games/mods/expansions are modules to the engine, unless a developer group decides to change the engine. From that point, they do get a separate installment, and in that installment, the same structure can be used for games/mods/expansions, as long as they are based on that specific engine version.

No objections to that, as I don't see how we can keep engine changes within one engine installment. What we could have is a common starter application, which would have tabs for engine versions, etc. Obviously, this would not be the only way to start games, just a common, easy approachable, portal for all games based on the OpenWar engine, or it's derived engines. Keeping things easily accessable to players, while advertising the modification capabilities of the engine/game. (Why else would there be such a portal, if not to make a selection in game modifications?)

And now come the shared resources (no, I hadn't forgotten about those ). The battlefield system is comparable to the NWN system. That system is based on the use of modules too. Aside from there being only one engine, the big difference is that NWN doesn't include the resources into the modules. Resources are packed into separate files, called hakpacks, which are distributed separately from the module. Both module and hakpacks are located in their own folder. These hakpacks can sometimes amount to over 150 mb, while a complex module only has a size of 20 mb. At NWN vault, there are over 6000 hakpacks to be found for NWN 1, against 5000 modules and then there are the the 350 model(packs). Edit: It seems there are twice as many models, and there are also portraits, textures, etc. NWN is one big community.


I have no illusions that OpenWar will ever have such an active community, but it does give you something to think about. The resources that are available, outnumber the amount of modules. Modules can use multiple packs, pick a few things from this one, a few from that and a bit more from a third. The used resources will not be unique, but the combinations are, unless everyone decides to use the exact same combinations. Seeing as how mod theme's vary, I don't think we will need to be afraid of that. Besides, if a model is really good, and can be used in multiple games, why not do so?

You agree with a library for commonly used resources. With NWN, the official version of that are the patches released by Bioware. The unofficial version are the CEP, and other prominent hakpacks, developed by the community. These are big packs, full with high quality resources, and used in quite a lot of modules. Because of the shared resources system, these hakpacks only have to be downloaded once, without interference of the Bioware. You could almost name it a public patch, if only it were applied into the original campaign. If it would have been a good campaign, I don't doubt the community would have requested permission to release it as a module, with some of these community patches attached.

Edit:
Shared resources increase the bond of the community, and it gives them the ability to bring out their own common libraries, without having to create a game/mod or ask for official support.

Solinx

From what I understand, all games/mods/expansions are modules to the engine

then you understood me wrong the way i see it, one game and it's expansions/mods have absolutely nothing to do with another game and it's expansions/mods, whether they were made by the same developer or not, on the same engine version or not, using the same resources or not (an exception to that is the resource library, from which developers can use resources, if the explicitly define that, so not automatically)

anyway, i think we should talk about this on MSN some time. it will be much easier if we can give eachother direct answers, and unfortunately my 'sense of english' is not quite good enough to discuss about such a difficult subject

[This were the points be agreed on for the engine:]

Alright, we had a nice msn conversation and it turned out there was some miscommunication. His focus was the shared engine core, mine was the shared resources.

This were the points be agreed on for the engine:
- Game devs have two options:
-- They make their own game, with it's own engine (which they can modify) in it's own folder.
-- They modify an existing game. Their modification will be in a subdirectory of the game they modify, and will use the same engine as that game.
- We make versions of the OpenWar engine. We do not enforce patches. Gamedevs are free to apply the new versions to their game, or choose not to. We do enforce these patches on our own game.

The points we agreed with on the resources:
- There will be a common resource library.
- Gamedevs are free to keep their own resources private for only their own game. It speaks of itself, that it will not be permitted to upload another's resources without permission, etc.
- When a resource file is updated in the common library, the old version remains and the new version is stored as a new file. This is to prevent games from breaking.

These points are agreed on by 2playgames and me. If you have more to add, or wish to debate them, feel free to do so.

Solinx

yes, there is just one thing we need to decide, and that's how will we implement the resource library. some options:
- the library is a site. developers can download resources and put them in their game. the engine won't see the difference from private resource
- the resources are stored in a central place on the harddisk. the engine will download them when needed
- the resources are stored in a central place on the harddisk. they will be placed there by the installer of a game

Hmpf, didn't I reply to this already? Well then, let's do that now.

I think your second or third option is the one I would very much like to see:

Games and modifications alike wouldn't come with shared resources, only private resources. Instead, they would come with a list of the necessary shared resources. During installation, they download all resources in the list that are not already available in the local library. This local library is a central place on the harddisk, which contains all shared resources for all games/modifications.

Through that, we save download traffic, and time, for both server and client, and we save harddisk space. Technically, this option would be the one with most gained.

Naturally, the included list should be normally readable in a text editor and shared resources should be manually downloadable, so that in case the PC the game/modification will be installed on doesn't have an internet connection, can still get the game/mod installed.

Solinx

yes, that seems like a fine solution

now, how to detect resources that are no longer needed?

Well, resources that are no longer needed are linked to a game or module that is no longer installed or updated. Using tags, or one central database, resources can be selected for deletion when a game or module is uninstalled or upgraded.

In that case we should also introduce a user tag. When resources are to be uninstalled, the user would get a warning screen, in which you could choose to keep the resources in his library anyway. In such a case, the user tag would be applied.

Solinx

in that case, i prefer a central database. it's more organized than tags

True at that. Silly, how the most logical solutions come last

Solinx

I'd had to read this topic twice to follow you guys.

I'm with 2play on the structure of the engine with its modules much like the battlefield way. I'm not familiar with NWN or shared resources. And I'm not yet convinced of the advantages of them. Altough it could be a good solution.

But what happens when a mod depends on one version of a resource that is upgraded by the installation of another mod, who also depends on the same resource but only a newer version?
Please don't flame me on this one, I know you discussed it in the above postings but this is the one big thing I don't like in shared resources.

I've to disagree with 2play in using a database to keep track of al versions of files and wich mod depends on them. Although a database is a nice idea, I think its unnecessarily for this information. I would suggest the use of XML files for this one.

It could be simple, just let a mod contain a XML file in wich al needed shared resources and their versions are stored.
Then you just check wich mods are installed, compare the shared resources that they need to the resources that are installed and you're done, you know wich you need and which are obsolete.

I also think it wouldn't be a good idea to let the mod download and install resources from a server on the internet. Afterall we need a server then with a piece of custom software to wich the installer can connect. Writing the software isn't the problem, the server is. Remember this aint a webserver, it would be a server wich we manage ourself. This could get pretty expensive. Managing isn't a problem either, I've got some fair knowledge of linux and windows server environments.

The best solution for this would to let the installers contain all the resources they need, and then let them check if they need to install it. This will lead to big downloads for players, but when finished the download players can install the mod at once. Without any hassle. Big downloads shouldn't be a big problem, this days most people wo play games have a broadband internet connection.

edit: corrected some faults

But what happens when a mod depends on one version of a resource that is upgraded by the installation of another mod, who also depends on the same resource but only a newer version?
Please don't flame me on this one, I know you discussed it in the above postings but this is the one big thing I don't like in shared resources.

if a resource enters the database, it will remain unchanged. newer versions always get their own entry

I've to disagree with 2play in using a database to keep track of al versions of files and wich mod depends on them. Although a database is a nice idea, I think its unnecessarily for this information. I would suggest the use of XML files for this one.

we meant 'database' in a more abstract way, not necessarily one with SQL and everything. XML files would be good for this

Afterall we need a server then with a piece of custom software to wich the installer can connect.

FTP anyone?

The best solution for this would to let the installers contain all the resources they need, and then let them check if they need to install it.

now that you say it, that's also a very good option. that way, the load will be distributed to the game developers

Afterall we need a server then with a piece of custom software to wich the installer can connect.

FTP anyone?

Had to think about this point before writing it down. But this could be done by ftp yes, http should also work fine. For the ones familiar with Linux, I think the apt-get program in debian based distros is a nice example for us.

The best solution for this would to let the installers contain all the resources they need, and then let them check if they need to install it.

now that you say it, that's also a very good option. that way, the load will be distributed to the game developers

Or offer the modders / developers 2 options. Give them the option to let their players download the full pack, resulting in a big download with resources they may possibly already have. Or let them use an updater much like the apt-get method under linux in debian based distros.

Only had Mandrake 9.2 for a few months (too many driver issues and difficulties with internet, along with a lack of time to properly learn how Linux operates), so I don't know about Debian, but I think I get the idea of apt-get anyway.

Giving both developers and players two options is good.
- Apt-get allows for cheap games, financed collectively you could say.
- Apt-get gives non-broadbandth users (there are quite a lot of them still, if not in the Netherlands) easier downloads.
- Manual download of resources, for non-broadbandth, offline install.
- Full download for the quick, hassle free installation.
- Full download, for the richer developers, who wish to provide some sort of premium download.
- Full download for the easy offline install.

And probably some more situations. It's 3.26 in the morning, so I call it a day

Solinx

I'd say I'm very happy with the system described.  It's a great compromise between the different points of view.

So, we all agree on this, then I will include it in the new site texts.

Solinx

Then we're settled on this one 
Only some small details are left, but that shouldn't be a hassle to deal with.

Personally, having an open source game that is not easily modular just doesn't make sense. It's open source for crying out loud! I think the real question will be as to how easily moddable the game will be.

erm, what's the connection between modular and open-source?

More modularity means it's more easily modifiable, which anything open source should strive to be.  I think the modularity we're talking about is on a different level than the modularity he's talking about, which is where the confusion comes from.

yeah, so i thought...