Gameplay Design Doc [ DRAFT ]

Request new features or present your ideas.
Post Reply
User avatar
Ishq
Project Head
Posts: 1147
Joined: Tue Mar 06, 2012 8:32 pm UTC

Gameplay Design Doc [ DRAFT ]

Post by Ishq »

Yes, this is the longest post I've ever written in my life, and it is only going to get longer.

Note: At the moment, this is incomplete. This is basically a culmination of all the IRC ideas, ideas from trem.net, and other ideas I felt would be cool to include. It will form the base of our actual gameplay design document. Furthermore, currently, I am going to emphasize the the larger gameplay aspects. Aspects that affect the entire team, or both teams; things like stages, building, reasearch, and upgrades. Things that involve individual classes, structures, or weapons will be handled only once we have finalized the more general gameplay.

Gameplay

Basic

Unvanquished will feature two teams, aliens and humans, each with a unique set of abilities, structures, and strategies. The goal is to eliminate all the enemy players and their ability to respawn (eg, kill all players and spawns).

Humans

Humans will primarily rely on ranged weapons and be less mobile than the aliens. The human tech is near futuristic weaponry and structures. The human team’s strength is its adaptability. There are no classes for the human team, the right equipment should be chosen for any given operation.

Weapons

Construction Kit
Machine Gun
Chainsaw
Shotgun
Laser Rifle
Mass Driver
Minigun
Pulse rifle
Lucifer Cannon
(names subject to change)

Buildables

Reactor
Telenode
Defense computer
Armoury
Medistation
Machine Gun Turret
Tesla Generator
Synergizer
Repeater
(Names subject to change)I'

Upgrading/Research

Humans get upgrades by building synergizers. The more synergizers humans build, the more upgrades they can receive. synergizers must be built at least (insert minimum distance here) apart. Synergizers mine much necessary resources that the humans require to research new technologies such as weapons, buildable structures, and upgrades. Building a synergizer also gives the humans buildable material to build new structures. Synergizers give an exponentially decreasing amount of building material per time interval as the game goes on. Thus, as the game goes on, older synergizers will produce less and less resources requiring expansion. Once an area has been harvested, it cannot be harvested again by the same team. If a synergizer is destroyed and rebuilt within the same area, it will begin to collect resources at the same rate as it was collecting before it was destroyed. Repeaters can be stacked to allow power to more than 20 bp worth of structures. This style of resources can be extending to doing things like adding powerups to existing buildables. This is strategically viable as powering up an existing structure will be cheaper than building a new structure, and a host of power upped structures may be more efficient than one new structure. The power up idea is just a theoretical idea however.

The Tech Tree vs Stage System

The Tech Tree is an interesting idea, but ultimately not viable due to teamwork issues in public games. However, a meshing of a tech tree and a stage system could be interesting. Below are some proposals on how to handle how upgrades are added:

  • Stages: Build N synergizers for Stage 2 and N + M synergizers for Stage 3.
  • Tech Tree: For every synergizer built, pick a weapon/structure/upgrade from the base tree. Then more synergizers are built, either expand the initial tree or buy a new base item to begin expanding that.
  • Stages + Tech Tree: Still thinking about this one. More details to follow.

Sudden Death

There will be no need for any sudden death mechanism. Smaller maps should be played when lesser players are on. Dynamic map rotation based on player counts should become the defacto standard and the recommended players per map should be more rigorously followed.

Resources

Resources can be found on all map surfaces unless specifically denied by the mapper (and some other surfaces that would not make sense to have resources on eg., lava).

User avatar
velociostrich
Dragoon
Posts: 318
Joined: Thu Mar 08, 2012 6:24 pm UTC

Re: Gameplay Design Doc [ DRAFT ]

Post by velociostrich »

A comprehensive design document is massive, which means that using the forums (while okay for now, I suppose) for authoring revisions will quickly become difficult to manage. If it's not a concern making the design doc visible to any user, we could host it on the wiki (and set it so that only devs may edit it, or perhaps assign a particular dev to keep it lined up with whatever is currently agreed upon in the forums). One really nifty feature of the wiki is being able to see what changes have been made to the doc, which becomes especially important when it really starts taking on some appreciable size.

User avatar
kharnov
Granger
Posts: 1851
Joined: Tue Mar 06, 2012 10:54 pm UTC
Clan: GT
Location: New York City

Re: Gameplay Design Doc [ DRAFT ]

Post by kharnov »

What if we used some sort of version control system and made 'commits' to a game design document, along with a changelog of what was altered? I've been told that a few people have actually written novels and other things this way.

Hell, why don't we use git?

User avatar
danmal
Posts: 193
Joined: Thu Mar 08, 2012 1:44 am UTC

Re: Gameplay Design Doc [ DRAFT ]

Post by danmal »

This is possible but it introduces a barrier to reading/editing the document that a wiki doesn't.

User avatar
kharnov
Granger
Posts: 1851
Joined: Tue Mar 06, 2012 10:54 pm UTC
Clan: GT
Location: New York City

Re: Gameplay Design Doc [ DRAFT ]

Post by kharnov »

The document would not be hard to read at all. You'd just have to download the 'source' tarball with the text file in it. Alternatively, you can probably just read it on github itself. The advantage that git has over the wiki is that each commit is purposeful, has a description associated with it, and it's very easy to track who is proposing which ideas. In addition, you can see the difference in each commit.

User avatar
Ishq
Project Head
Posts: 1147
Joined: Tue Mar 06, 2012 8:32 pm UTC

Re: Gameplay Design Doc [ DRAFT ]

Post by Ishq »

I'll move this to the wiki once I have finished writing it. At the moment, Google Docs provides sufficient revision control.

User avatar
velociostrich
Dragoon
Posts: 318
Joined: Thu Mar 08, 2012 6:24 pm UTC

Re: Gameplay Design Doc [ DRAFT ]

Post by velociostrich »

kharnov wrote:

The advantage that git has over the wiki is that each commit is purposeful, has a description associated with it, and it's very easy to track who is proposing which ideas. In addition, you can see the difference in each commit.

Kharnov, you can do all of those things with a wiki; that is the point of a wiki. Moreover, a design document with formatting would be preferable to a plain-text document (although I think Github may support displaying documents written in markdown, which imo is vastly inferior to MediaWiki markup), and the wiki makes linking to different areas of an article (or across articles, for that matter) extremely easy.

Post Reply