Gameplay Roadmap - 2.1.1.1 Dissipation of stages

Request new features or present your ideas.
Post Reply
User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Gameplay Roadmap - 2.1.1.1 Dissipation of stages

Post by Viech »

2.1.1.1 Dissipation of stages wrote:

The most obvious solution would be increasing the number of stages until all items are unlocked at an appropriate time. A more abstract and flexible way to do this is giving each item a confidence threshold of its own. Compared to any fixed number of stages, this will greatly improve our development workflow since we can position items freely first and optionally group them into a fixed number of stages later on.

As a first step I would remove stages and add the old stages' confidence thresholds to the config files of the relevant items. Instead of announcing a stage up/down, the fact that an item has been unlocked or locked would be announced to a team. The confidence reward/punishment for staging up/down would be replaced by (automatically) giving items a second threshold that is responsible for revoking access. The next step would be tweaking all those values individually as we see fit. The third step is optional: Items would be regrouped into a fixed number of stages with given thresholds. Alternatively this approach would allow for easy testing of a player generated item order (i.e. tech trees).

Ishq wrote:

I agree. This is the way to go for more dynamic gameplay. Also, I would like to emphasize that splitting each item into its own individual stage should rather be a fallback system than a first step. Such an implementation is far too rigid, and hardly a step up from our current stage system. The only benefit it provides is increased granularity. Ultimately, I still envision us moving to some sort of nonlinear system of picking and choosing upgrades. I have, in the past, proposed an allocation system that allows unlocking items based on allocating confidence to your desired items. We need to decide which system (nonlinear + picking or thresholds and hierarchical) we prefer, and work on that. If the rest of the team agrees that a nonlinear system is superior (regardless of the obstacles), we should devote our energy to that instead using individual item thresholds. This is the most obvious and least imaginative solution to this problem. We should only do this if we can't do anything else.

Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

User avatar
Anomalous
Programmer
Posts: 318
Joined: Wed Mar 07, 2012 3:51 pm UTC

Re: Gameplay Roadmap - 2.1.1.1 Dissipation of stages

Post by Anomalous »

Team votes for unlocking wouldn't be hard to do. We'd want to allow the vote even if the item isn't unlockable yet: prerequisites would be unlocked first (in some pre-defined order). Also, I think that a default unlocking order would make sense alongside this.

Debian and Ubuntu packages (squeeze, wheezy, sid; 12.04, 12.10, 13.04) may work on derivatives

OFFEND! … no, that's not right… ATTACK!

User avatar
Viech
Project Head
Posts: 2139
Joined: Fri Aug 03, 2012 11:50 pm UTC
Location: Berlin

Re: Gameplay Roadmap - 2.1.1.1 Dissipation of stages

Post by Viech »

For further brainstorming on the topic of nonlinear upgrade unlocking, we should use this thread.

Responsible for: Arch Linux package & torrent distribution, Parpax (map), Chameleon (map texture editor), Sloth (material file generator), gameplay design & programming, artistic direction

Post Reply