Downloads

41 :eek:
We seriously run through release numbers way too fast. We should have release candidates or something. The past few releases have all been a single commit and quite frankly I have never seen releases with so few changes before.

I added 2.5.41 to master and git tags.

Yeah, I should have called it 2.5.4.1. Anyways, I wouldn't call it a "release" as I am just putting it out there for the guys to play test since we don't have a Git play testing team.
 
@M:C team:

Hi guys,

I know I am giving advices without having been asked. :)

But currently your development seems quite chaotic too people outside your team and sometimes even your team members seem to not know what is currently going on,
where to get the current sources or what to test.

1) You need to have one "Single Point of Truth" where team members will always find the current revision to work on.
(Keep it simple for less experienced modders.)

Especially if your own team members and partners are confused, you should start to worry.

In RaR this "Single Point of Truth" is our SVN.
Thus there is never any confusion, where to get the current (internal) version to work on or to test.

2) When working in a bigger team you will need to establish some project structures:
Planing, Work Organisation, Quality Control, ...

Especially if several modders are working on DLL.
Otherwise you will get problems some day.

To be honest, I see almost nothing of that here. It seems like you all just mod what you like and in the end just throw together what you just did.
(But maybe I simply don't know what you are doing internally.)

3) Throwing almost untested internal revisions at community and then have masses of bugfix patches afterwards is a very bad idea.

Most of community does not want to be your testers. They want to be players that enjoy stable and balanced releases.
I have seen lots of great games and mods totally ruining their (potentially much bigger) communities with publishing behaviours like this.

Also, only very very few people from community will be willing to regularly check for bugfix patches they need to install.
(Most of them won't know at which bugfix patch they currently are a few days later.)

When you will get bug reports, you will have big problems analyzing because people won't know the exact revision.

------------

See, you guys do have skills and you do have very interesting ideas. :thumbsup:

But from the things I read here,

1. You do not seem to work like a real (organized, structured and efficient) team yet. (Efficiency and Quality)
2. Your strategy of publishing almost untested revisions / not having strong quality control is quite problematic. (User Satisfaction and Analyzing Bugs)

Maybe you should seriously rethink the way you are organized. :dunno:

------------

So again, sorry for getting involved without being asked. :blush:
(But I do wish only the best for this modding community.)
 
1) You need to have one "Single Point of Truth" where team members will always find the current revision to work on.
(Keep it simple for less experienced modders.)
We have two points like that, both are git branches
1: develop: this is where new features are developed and it is by definition poorly tested and unstable.
2: release-2.5: this is a branch, which is meant to become as stable as possible as it is meant to be used for next release and new features are NOT meant to be put into this one.

The reason why it is split into two is because development on new features can continue while the release branch gets stability tested. This ability grows more important as the number of modders increase.

2) When working in a bigger team you will need to establish some project structures:
Planing, Work Organisation, Quality Control, ...

Especially if several modders are working on DLL.
Otherwise you will get problems some day.
This is true regardless of number of modders. We really need a better long term plan (how many times have I mentioned this by now?:mischief:)

We actually have quality control and a decent project structure. What we need to do is to stick to the plan, which seems to be an issue.

3) Throwing almost untested internal revisions at community and then have masses of bugfix patches afterwards is a very bad idea.
I fully agree. People should use the head revision of release-2.5. The problem is that whenever Kailric commits to this branch, he makes a new patch release. This was not part of the plan :(
The issue is that people don't pull that branch, but releasing tons of versioned patches is not the solution to that problem. The originally intended solution was to make a release branch (in this case release-2.5), then get people to play using that one and once people stop reporting bugs for it, it can be used for a release.

I'm not really sure why it turned into patch hell again as my source of information regarding releases is the public forum. Patch releases turns up out of nowhere and I'm not informed of them before they are in the public, which is another potentially major issue.
 
We have two points like that, both are git branches
1: develop: this is where new features are developed and it is by definition poorly tested and unstable.
2: release-2.5: this is a branch, which is meant to become as stable as possible as it is meant to be used for next release and new features are NOT meant to be put into this one.

Why not follow a much simpler approach ? :dunno:

Development Phase --> Improvment Phase --> Release --> Development Phase ...

I believe that it is essential to stabilize / improve before continuing with other new stuff.
Does it make that much sense to develop new features while the existing ones are not "finished" (stable, performant, balanced, nice graphics, atmospheric texts, ...) ?

The reason why it is split into two is because development on new features can continue while the release branch gets stability tested.

Why do you think that is the best way to go ? :confused:

This is true regardless of number of modders. We really need a better long term plan (how many times have I mentioned this by now?:mischief:)

Long term plans is only the smaller part of it, but it is important as well.

Short term plans and organization so people can efficiently join forces to finally get things done at high quality is more important though.
Otherwise people will tend to pick "easy" and "fun" topics and topics like bugs, text improvments, balancing, ... will always get neglected.

---------

In both, TAC and RaR, we always had dedicated phases for improvments and quality control.

In those phases, the complete team tries to take care of quality:

* fixing bugs and general code improvments (stability and performance)
* graphical improvments (simply making things look better)
* writing Colopedia entries
* text improvments and translations
* checking logs, testing with autoplay, ...
* play testing and balancing
...

The amount of work that usually needs to be done here is at least as much as the development of the functionality for new features.
Then why not properly take the time todo so ? :confused:

Before improvments are not completed, no commits of new complex features are allowed.
I can't even understand, why there are continuously new features developed, while the existing work has not been optimized yet ...

But maybe I am simply too old. :)
 
Y'all worry to much.:D The only official "team" members (if we just count the ones on Git) we have for M:C are Night and I, the others have issues with using our repository. What can we do about that? Force them to conform?

M:C has been around since Jan 9 2011, and it will continue on a while more as I am having a blast with it.

What we should do is not call it a "release" but rather a "alpha release" or "development release" however best said in development talk so that people know there could be issues, and that we need testers. I posted 5 "patches" or tweaks so far, and that's not a whole lot, and it gets more stable with each one. What should I do, keep the patches to myself? At the moment we have guys wanting to play test, that may not be true tomorrow, so I give them what they want.

I have posted a list of new features and content I intended to add in the long run. I want to get the key features in the mod so they are there to interact with each other so while I play test I can get a feel of them as whole and hopefully discover any issues.

I am liking this new victory condition so I am going to be play testing it for quite a while and at the same time adjusting and fixing other issues that I see needs addressed.
 
I agree with Kail, no one is getting paid and no one is paying, this is just fun!

It's Kail's baby, if he wants to make a fundemental change he is welcome to do it.

The only hiccup so far is TW getting a bit confused by which patches needed applying, the simplest solution to that is keep a 'main patch' at the download section, that contains all hotfixes so you only ever need to 'hunt' for one patch, it is not like a patch is ever a very big download, and most patches overwrite something in a previous patch and thus contains the same files anyway.

I for one am loving the latest version, and the bugs are not dampening my enjoyment, especially when a hotfix generally appears in a day or two of report!

Onward to Glory!!
 
Why not follow a much simpler approach ? :dunno:

Development Phase --> Improvment Phase --> Release --> Development Phase ...
We are doing that, more or less. What we can do, which isn't part of this is during a development phase, we can go back to last release and start an improvement phase based on that one based on bug reports. This is usually referred to as hot fixing. This is meant to fix bugs not detected in the improvement phase. It sort of ended up replacing the improvement phase, which is the real issue here.

The key here is that git is optimized to a workflow with branches. Making a new branch and later merging it back into the original is much easier in git than in svn and it actually makes sense to work in multiple branches at the same time. In fact we use too few branches and we really should have one for each feature under development.

I can't even understand, why there are continuously new features developed, while the existing features have not been optimized yet ...
The goal is not to make brand new features right now, it is to make features to support/replace existing features and then we will balance the combined output. For instance the topic for a while now has been the economy. Rather than "improving the existing code" we ended up with a brand new trade screen class, which we intend to implement before doing anything to economy balance. There is no need to balance something you intend to heavily modify anyway.

Ok, there is work on other (new) features too. The save branch I made less than a week ago is unrelated. However the goal here is stability. M:C 2.5.3 was released due to forgetting to save some data and now I changed the save code into something where adding data is easier as read and write can't get out of sync. Possibly more important now we have a script to analyze the code and detect unsaved variables, which it assumes should be saved. Such an automated check should prevent releasing anything in the future where the savegames lack variables.
 
The goal is not to make brand new features right now, it is to make features to support/replace existing features and then we will balance the combined output. For instance the topic for a while now has been the economy. Rather than "improving the existing code" we ended up with a brand new trade screen class, which we intend to implement before doing anything to economy balance. There is no need to balance something you intend to heavily modify anyway.

That is what I was trying to say too. I want to get all the major planned features in the mod, even if they are not 100% complete, so that we can test them out with other features as a whole. Then we can better see how to "complete" each feature so they work well with each other.

I am excited about the economy changes and the possibilities there. But it will be no quick fix and will need to be balanced with the other features we are introducing.
 
Ummm... speaking of ways and 'how-to's, and since I've decided to work on Russian translation, I've got a bunch of questions. Because I happened to be unable to come up with a better way, I just downloaded v2.5 and started through '.../Assets/XML/Text' files. So the questions are:

- Are they the latest?
- Will they remain the latest when I'm finished? If not, where I get new ones in the process?
- How do I share finished files?

And a technical question. I've noticed that entries suggest grammar usage like:
<Spanish>
<Text>aquitano:aquitana:aquitanos:aquitanas</Text>
<Gender>Male:Female:Male:Female</Gender>
<Plural>0:0:1:1</Plural>
</Spanish>
This one is self-explanatory: there are different adjective forms depending on if the object described by the adjective is single or plural, male or female, ok.

But the next one puzzles me:
<German>
<Text>Austrasisch:Austrasischen:Austrasische</Text>
<Gender>Neuter:Neuter:Neuter</Gender>
<Plural>0:0:0</Plural>
</German>
All of neutral gender, all single, but different adjective forms. Well, personally I don't mind, but how does the game pick the right one?

What I actually mean is: how does this feature with genders/numbers work?
 
Ummm... speaking of ways and 'how-to's, and since I've decided to work on Russian translation, I've got a bunch of questions. Because I happened to be unable to come up with a better way, I just downloaded v2.5 and started through '.../Assets/XML/Text' files. So the questions are:

- Are they the latest?
- Will they remain the latest when I'm finished? If not, where I get new ones in the process?
- How do I share finished files?
Use git to get the newest version.
https://sourceforge.net/p/colonizationmodcollection/wiki/GIT/
I guess I better finish that guide on how to select branch and commit changed files back into the system for other people to download.

A few notes. I made a perl script to add empty lines to the XML files. You would then be able to search for "<Russian></Russian>" to find the untranslated lines. When somebody adds a new string, the script should ensure that there will be something to search for to find the outdated parts.

The XML files should be html escaped. However as this makes the files somewhat harder to read, I may change that to be UTF-8 encoded and then do something in the DLL. I have known that for a while, but not done anything about it since English will not have issues. We can automatically convert between regular text and html escaped text meaning that isn't an issue right now. I wrote a post on how to do it automatically, but I can't find it right now :(

What I actually mean is: how does this feature with genders/numbers work?
I will get back to you on that one. The game engine was originally written for English and the grammar is kind of like a later addon. It may not work as well as we would like to think. This mean in order to add a proper Russian translation we might have to modify the DLL to get a better grammatical understanding. We can do that (I think) once we know what is broken and how it should work.
 
I wrote a post on how to do it automatically, but I can't find it right now :(
Forgive me, but you may have put a finger on one of your main issues.
Especially you, Nightingale, are very helpful due to the fact that you are not only developing and correcting, but giving explanations, too. Unfortunately, this is a very rare but very precious behaviour for a modder, so let me take the occasion to thank you for this.
Nevertheless, as far as I see it, your explanations are scattered all over the place - which is understandable, as they often are caused by questions and misunderstandings in the various threads. But they are scattered.

It might be worth the effort to collect them and put them into one "sticky" thread for anybody to have a single place to look for explanations. This might help your team, too.


The game engine was originally written for English and the grammar is kind of like a later addon. It may not work as well as we would like to think. This mean in order to add a proper Russian translation we might have to modify the DLL to get a better grammatical understanding. We can do that (I think) once we know what is broken and how it should work.
I would strongly propose to postpone this until you have a release you are really satisfied with.
From browsing your subforum I get the impression that you guys are working in around ten different construction zones at the moment. Seems not to be the best idea to open no. 11 now.
Grammar and text composition are an issue in Col, no doubt. But as long as the texts are at least understandable, there are more important things to finish at the moment (just my point of view, of course).
 
- Are they the latest?
- Will they remain the latest when I'm finished? If not, where I get new ones in the process?

New texts will be added from time to time, but anything you translate will and can be used. However, you are translating for M:C it seems and not all M:C text would relate to a World War era Russian setting that you was interested in. Not trying to discourage you just letting you know. However again, I would love to add a Historical Russian Civ to M:C. Actually, they are represented I guess you can say as the Native Slavs? Other than those, what would be a good Player Civ/Leader for Russians of this period 476-1500 AD. The Kievan Rus would fit in there somewhere right?

I would strongly propose to postpone this until you have a release you are really satisfied with.
From browsing your subforum I get the impression that you guys are working in around ten different construction zones at the moment. Seems not to be the best idea to open no. 11 now.
Grammar and text composition are an issue in Col, no doubt. But as long as the texts are at least understandable, there are more important things to finish at the moment (just my point of view, of course).

Is our forums really that chaotic? Yeah there are a bunch of ideas going around but, only about 3 construction zones. I'm working on Nation States, Minor Civs, AI and a new Victory Condition(which all tie together), Fullerene is working on some Religion code, and Nightinggale is soaring about saving the world as usual. Daw isn't really a modder from what I understand so only so much he can do, but he has offered to help and we don't want to discourage him by asking him to do something he doesn't want to do or has no idea what to do.
 
We are doing that, more or less.
...
This is usually referred to as hot fixing.
...
It sort of ended up replacing the improvement phase, which is the real issue here.

Ok, so generally you intend to do improvment phases before "community" releases in the future. :thumbsup:

There is no need to balance something you intend to heavily modify anyway.
...
However the goal here is stability.

What we should do is not call it a "release" but rather a "alpha release" or "development release" ...

Ok, I finally got the picture. :)

You are actually currently not having real "community" releases that are intended to really be played by community.
(I avoid to talk about "final" release, because that term is often misunderstood as the absolutely last release of a project.)

Your current releases are "alpha" releases that are mainly intended for partners to help testing and finding bugs in the logic.
(As you said, that it is not about testing balancing or getting feedback about other details, they are not "beta releases" yet.)

Well, involving interested people from community as partners into testing is a valid strategy. :thumbsup:
(Just would not have done that with public releases. But that is a matter of taste.)

It is just important though, that community understands.
Otherwise if somebody does expect a "community" release and only gets an "alpha" release he might be disappointed and loose interest.

The fact that you were always generally talking about "releases" got me confused. :)

But now I understand, that M:C is still under "heavy construction" and you first need to continue focussing on pure fuctionality / stability before you can really take care of quality of the rest.
(I thought you already had or were currently heading for a "community" release.)
 
It might be worth the effort to collect them and put them into one "sticky" thread for anybody to have a single place to look for explanations. This might help your team, too.
The DLL thread was meant for that, but it isn't working that well.

What we really need is somebody to keep an eye on the forum and whenever there is something worth remembering, like howto guides or concepts to be coded, it should be added to SF. We have both a ticket system to remember tasks and a wiki, which is great for writing guides on how to do stuff.

Sadly I have learned that I'm not that happy with writing wiki texts. It would be nice if somebody else would look into this.

I would strongly propose to postpone this until you have a release you are really satisfied with.
My plan would actually be to do nothing right now. Once the translation encounters specific problems where something appears to be impossible to do, then it would be time to figure out what to do from there.


New texts will be added from time to time, but anything you translate will and can be used.
I modified the text system to use the English string if the one for the chosen language is missing (vanilla can't handle this case). Combine this with the script, which helps locating the untranslated strings and keeping the translation up to date will not be that much of an issue.


However, you are translating for M:C it seems and not all M:C text would relate to a World War era Russian setting that you was interested in. Not trying to discourage you just letting you know. However again, I would love to add a Historical Russian Civ to M:C. Actually, they are represented I guess you can say as the Native Slavs? Other than those, what would be a good Player Civ/Leader for Russians of this period 476-1500 AD. The Kievan Rus would fit in there somewhere right?

I'm working on Nation States, Minor Civs, AI and a new Victory Condition(which all tie together)
I wonder if it would make sense to split it up a little bit and possibly use branches :think:

Fullerene is working on some Religion code
We have to remember Fullerene is new at this and have yet to actually contribute with anything. The size of the XML files and the source code mean there is a certain learning curve. If Fullerene found a corner he can dig into and do something productive with, then I'm ok with that. Maybe I will make a branch for him and his development can live its own life at his rate until he is more experienced.

Nightinggale is soaring about saving the world as usual.
If bug prevention and assisting other people is saving the world, then yeah :cool:

Come to think of it, I guess it is a bit tricky to say precisely what I do. I improve performance and stability and make the DLL more generic in the sense that design decisions are moved to XML and then I aid other people when they are stuck on something. While true, it doesn't sound like it do my work justice. How to write what I actually do :think:
I build the DLL foundation that other people use to build mods on.
 
Lead Performance and Foundational Functionality Developer (I think this one is my favourite)

aka "I kick ass" :worship: Nightinggale

What we really need is somebody to keep an eye on the forum and whenever there is something worth remembering, like howto guides or concepts to be coded, it should be added to SF. We have both a ticket system to remember tasks and a wiki, which is great for writing guides on how to do stuff.

I will attempt to do this.

I wonder if it would make sense to split it up a little bit and possibly use branches :think:

Currently I am play testing them all, AI, diplomacy, UnitAI, etc, and how they interact with each other, so splitting them up wouldn't work so well. Like the new NationState of Rome is the new Victory Condition and how it interacts with the Minor Civs and how the Player interacts with them all is all tied together. I pretty much took over "develop" branch as my own :) so, it would be good to create other branches for anything else. I will be working with develop branch for quite a while.

If bug prevention and assisting other people is saving the world, then yeah :cool:

Then yeah:goodjob:


Well, involving interested people from community as partners into testing is a valid strategy. :thumbsup:
(Just would not have done that with public releases. But that is a matter of taste.)

Yeah, that is how I have done it this whole time and it as worked quite well in generating interests as well as producing a stable release. It is not necessarily a matter of taste but more a matter of necessity :) I can't play test alone and besides, like any mod this was a dream of mine that I felt like I would share with the community. If others have a common vision and would like to help then that is awesome, if not then I continue on regardless.

We just need to make a point that the mod is not "finished" and could have issues, but which mod is "finished" and doesn't have issues?
 
Use git ... that guide on how to ... a perl script
Ok then. Hope my wits will be enough to master that software.

The XML files should be html escaped. However as this makes the files somewhat harder to read, I may change that to be UTF-8 encoded and then do something in the DLL.
Sorry, I don't understand what is "html escaped", and acronyms like "UTF-8" and "DLL" scare the hell out of me... You mean if Cyrillic fonts will be depicted right in game?

I will get back to you on that one.
Ok. The other way around may be that I will manage to construct "universal" phrases to avoid issues with different genders/numbers. That must be possible at least sometimes.

I would strongly propose to postpone this until you have a release you are really satisfied with.
[..]
Grammar and text composition are an issue in Col, no doubt. But as long as the texts are at least understandable, there are more important things to finish at the moment (just my point of view, of course).
I agree. In fact I was asking just in case there was a ready answer. But since there is not yet, it definitely can wait.

New texts will be added from time to time, but anything you translate will and can be used.
As soon as I master the GIT thing, as far as I understood. Right?

However, you are translating for M:C it seems and not all M:C text would relate to a World War era Russian setting that you was interested in.
I understand that, but don't see a problem there:
A. It is fun to work with medieval things as well;
B. There's nothing to translate in the USSR thing anyway so far;
C. Working on medieval thing will familiarize me with how the in-game phrases are assembled. This will help to build up the USSR thing faster when the time is right for that.

However again, I would love to add a Historical Russian Civ to M:C. Actually, they are represented I guess you can say as the Native Slavs? Other than those, what would be a good Player Civ/Leader for Russians of this period 476-1500 AD. The Kievan Rus would fit in there somewhere right?
Well, the period is too long for my folksmen there. You see, Kievan Rus is a good candidate for earlier stages with Vladimir the Red Sun or Yaroslav the Wise as a leader. The problem is that it started to fall apart in X century and it was actually no more by the XIII century when it ended up invaded by the Golden Horde as realms fell one by one being unable and unwilling to help each other to defend. For 3 next centuries the Horde took control over the power over the Russian realms, leaving some autonomy but demanding heavy tribute and the leaders must be approved by the Khans of the Horde. Alexander Nevskiy is a good leader for that period, but the Kievan Rus as such was actually no more. Several attempts to lift The Golden Horde occupation were made under the Moscow rising authority (that is how and when the Russian central power moved from Kiev to Moscow), and Dmitriy Donskoy is a good leader for that. None of the attempts was really successful, as the Horde returned with even fiercer raids every time. And only in XVI century (which is the mod timeframe end) as the Horde weakened due to internal processes the Russian realms were reunited under Moscow reign instead of Kiev now.

Summary, this means that the mod timeframe covers 4 main intercovering periods:
- Pre-state Eastern Slavic tribes and tribal unions (?-IX century);
- Kievan Rus to start with as a state (IX-XIII);
- Fragmented Russian realms (X-XVI) fighting each other, constantly rioting against the Horde, and also repelling invasions from the West (see Battle of the Ice for instance)
- Moscow Duchy (XIII-XVI) rising from the ashes to become the Russian Empire in 200 years...

... and, frankly, I have no idea about how to make it in one game...:crazyeye:
 
Ok then. Hope my wits will be enough to master that software.
Start with git. The perl script isn't an issue for quite a while, possibly ever.

Sorry, I don't understand what is "html escaped", and acronyms like "UTF-8" and "DLL" scare the hell out of me... You mean if Cyrillic fonts will be depicted right in game?
The game is written in C++ and all the code we write end up in a DLL file, which the game reads at startup. Any reference to DLL simply mean what we have written in C++.

UTF-8 is a character encoding. It looks like this:
Code:
&#1073;&#1080;&#1090;&#1074;&#1072; &#1085;&#1072; &#1063;&#1091;&#1076;&#1089;&#1082;&#1086;&#1084; &#1086;&#1079;&#1077;&#1088;&#1077;
The very same text when it is written with html escapes (I removed all the ; to prevent the browser from converting)
Code:
&#1073&#1080&#1090&#1074&#1072 &#1085&#1072 &#1063&#1091&#1076&#1089&#1082&#1086&#1084 &#1086&#1079&#1077&#1088&#1077
Changing the DLL to read UTF-8 instead of html escaped text will greatly increase readability of the XML files.

I just made a quick test and using UTF-8 showed a lot of ? characters, as expected. Using escaped html revealed a whole lot of blanks. Looks like we have an issue.

Do anybody know if there is a civ4 mod, which is available in Russian? It would be nice if we could just copy the character art as an easy solution to this issue.
 
We just need to make a point that the mod is not "finished" and could have issues, but which mod is "finished" and doesn't have issues ?

There are only a few mods which have officially been declared "final".
(TAC is one of those.)

But this is mainly about telling other people "We don't continue working on the mod.".
Most mods either continue or are simply abandoned at some point.

However, there is a big difference between those types of releases:

Alpha Release:
* Contains many "raw" features that have not yet undergone any detailled improvments or quality control.
* Lots of small open todos (e.g. balancing, graphics, texts, translations, ...) for the actual release.
* Intended to find support for bugfixing or programming or graphics.

Beta Release:
* No more "raw" features. Generally quality control has been done but mod is not intensively tested yet.
* Still some small open todos (e.g. balancing, graphics, texts, translations, ...) for the actual release.
* Intended to find support for testing or balancing or text improvments or translations.

Community Releases:
* Good quality control and intensive testing have been done.
* No (or almost no) open todos for the actual release.
* Intended for community to be played.

----

A "Community Release" does not mean that the mod is completely finished.
It simply completed one full development cycle and will start a new development cycle.

Publishing "Beta Releases" or even "Alpha Releases" is fine if that is part of your development strategy.
Even some professional software companies for games occassionally do that.

Of course, a mod might have only "Alpha Releases" in the early phases of the project and also decide to publish those.
It might also have several "Beta Releases" until it finally publishes a "Community Release".

Spoiler :

Actually even in TAC "Beta Releases" were published sometimes.
(But they were always officially declared as "Beta Releases" and while they were out, the "Community Release" was developed.)

Ray's Wishlist had nothing else than "Alpha Release" but I also officially declared it as "Prototype" (not meant to be played / for modders).
(I mainly wanted to develop prototypes for later development and share and discuss ideas with other modders.)

In RaR I never wanted to have "Beta Releases" or "Alpha Releases" published to community.
(But that is simply a matter of taste. I prefer to handle those development steps internally with team and partners.
It took more than one year of internal development until we published our first "Community Release".)


The issue simply is:

Community should know what it gets.

A player who gets an "Alpha Release" although he expects a "Community Release" will most likely be heavily disappointed.
If this happens several times to him with a mod, he might give up that mod forever.

Community wants "Community Releases" at some point.
(Of course it takes time to get there.)
 
Top Bottom