Release model

[ElonNarai]

For the sake of the design document I need to get a solid definition of what the current release model is as it can have a huge impact on the design document.

So from the wiki page:

Release Model Offered for download on the internet. Game will be released in several 20-30 minute sections of gameplay called "modules".

I assume this model was designed to allow iterative game development (so each release holds a new chapter) but this holds problems as small things can change making the previous models incompatible with the new one.

Personally I think we should try update by update release model (like used by Mount&Blade) since that would be easier to maintain. But since this still allows changes to the story we should think of patching save files to make up for any changes (a save game editor, maybe).

There is almost no differnce with the "modules release model" and the "update by update release model" accept that the later one is a complete new download which is easier to maintain than going through all the previous modules. I did read in viewtopic.php?f=18&t=745 that this is easier, but I think it's harder to delevop.

So is the above release model still valid? Because I haven't seen much topics about it (couldn't search on "module" alone)

[gorzuate]

I looked up Mount&Blade and tried to figure out what their release model is like, but didn't find anything about it. So I'm not sure what they're doing.

One big reason for releasing Allacrost in parts, or modules if you will, was so that we don't have to create the maps and artwork and story all at once. If we did that we'd never make a single release. So each module was intended to represent a chapter of the story, and we could make the content necessary for that part of the game, instead of the whole game.

When our first module is released, most of the game code will be finished. Maybe some advanced features won't be implemented yet, and the code could still be optimized and what not afterwards. But I think most of the functionality should be there.

Since we haven't actually released the first module yet, it is safe to say that we (or at least, I) haven't thought about backwards-compatibility with older modules. I just figured we'd cross that bridge when we got to it.

[ElonNarai]

Well, the problem is that I'm trying to cross that bridge. We don't need to know what is behind that bridge, but we at least should have a general idea how to cross that bridge.
Options are:

1. We freeze the module that are done and only fix it if needed. (so only if a module becomes incompatible we will touch it again)
2. We release the modules as seperate games and only keep the save games compatible(either with or without game manager that chains it together)
3. There are no different modules
4. We release the games as sequence of each other, so that we won't have to make the compatible with each other

We could wait with it but I think we can all agree that if we don't think about ahead of time we will hit a brick wall. This is the so called anti-pattern: Architecture by Implication
Oh and anti-patterns are design patterns that are not good but evil.

[rujasu]

Options are:

1. We freeze the module that are done and only fix it if needed. (so only if a module becomes incompatible we will touch it again)
2. We release the modules as seperate games and only keep the save games compatible(either with or without game manager that chains it together)
3. There are no different modules
4. We release the games as sequence of each other, so that we won't have to make the compatible with each other

I disagree with all of these ideas.

Once the demo is released, we decide firmly on a format for saved data that will be supported for the entire game. The game engine should be prepared to support everything we need at that point. Modules will be 99% game content. (That said, I think the idea of each module containing two hours of gameplay is completely unrealistic. Each module should be 20-30% of the game; we can't have too many of them.)

When we're releasing modules, the only changes that should be made to the engine are:

-Bugfixes
-Changes that don't affect gameplay directly (audio/interface stuff)
-Changes that may affect mechanics, but don't change handling of actor/object/map data

This means we will have to make sure we get things right the first time, as making significant changes to Module I when we're on Module III won't work. I think this is feasible for us, but as I said we cannot break down into tiny modules because it will be too hard to chain them together.

[ElonNarai]

Options are:

1. We freeze the module that are done and only fix it if needed. (so only if a module becomes incompatible we will touch it again)
2. We release the modules as seperate games and only keep the save games compatible(either with or without game manager that chains it together)
3. There are no different modules
4. We release the games as sequence of each other, so that we won't have to make the compatible with each other

I disagree with all of these ideas.

Once the demo is released, we decide firmly on a format for saved data that will be supported for the entire game. The game engine should be prepared to support everything we need at that point. Modules will be 99% game content. (That said, I think the idea of each module containing two hours of gameplay is completely unrealistic. Each module should be 20-30% of the game; we can't have too many of them.)

When we're releasing modules, the only changes that should be made to the engine are:

-Bugfixes
-Changes that don't affect gameplay directly (audio/interface stuff)
-Changes that may affect mechanics, but don't change handling of actor/object/map data

This means we will have to make sure we get things right the first time, as making significant changes to Module I when we're on Module III won't work. I think this is feasible for us, but as I said we cannot break down into tiny modules because it will be too hard to chain them together.

You're right that is feasible and I haven't thought of increasing the length of the gameplay.

So another option is that the playtime of a module is 20% of the game which should be 8 hours of gameplay for each module instead of 20-30 minutes that was the originally idea.

If we do the above then the modules become less a problem since you want to demonstrate almost everything in your first release (at least I hope so) which means a lot of things are standarized.

rujasu, you have my vote ^_^, I will see if I can get other people to like your idea as well.

[gorzuate]

I agree with rujasu but I'm undecided on the length of each module

[rujasu]

I agree with rujasu but I'm undecided on the length of each module

I'll throw 8-10 hours per module out there as a possibility. Also, I think releasing the game demo will give us a better impression of time factors.

[gorzuate]

I don't see the problem with having each module represent a chapter of the story. It makes for easily definable start and stop points, both from a playable point of view and a creating game content point of view.

But if one chapter translates to 15 min of game time, then yeah, it would kind of suck