Although the implementation detail should probably be discussed elsewhere, I'll describe the following with technologies I am familiar with. That's not to say we can't evaluate alternatives.
I apologise in advance for the lack of syntax highlighting for the specflow stuff below, should still be readable I hope. ('#' denotes a comment)
What I have in mind is a series of specflow Given/When/Thens describing some typical (simple) game behaviours to aim for in MVP which will help us progress towards an achievable, measurable goal in January.
Here are some examples off the top of my head:
Feature: Third Person Shooter Game
In order to push development of the game engine in the right direction
As a player
I want to be able to achieve the basics of a third person shooter game
Scenario: Create a character
Given I have provided a unique username for my character
When I create the character
Then my character should be available to play with
Scenario: Persist created characters
Given I created a character last time I ran the game
When I load the game
Then my character is available for selection
Scenario: Start a new game
Given I have selected a previously created character
When I start a new game
Then my character is loaded into the world
Scenario: Move character
Given I have started a game
When I try to move
Then my character's location moves accordingly
Scenario: Persist game
Given I have saved my game
When I load the game
Then my character is in the same location as when I saved my game
Some very basic (and very subject to change) examples there. I believe the above alone tackles (and therefore would provide failing tests for) the following items I'd like to see in MVP:
Local server play (no connection to a server)
Single player
World Generation
Actor Generation
Actor Translation (movement)
World Persistence (inc. Actor)
This intentionally avoids the following items that I would like to see for v2 (but may derail a v1 release if included too early):
Remote server play
Remote server authentication
Remote server security
Local client anti-tampering (and/or server authority)
Multiplayer
Rendering
Dynamic World Generation
Actor Physics
Actor Containers (inventories)
World Containers (inventories)
etc (sky's the limit)
All of these other elements could, I think, be easily introduced to a model achieving those v1 targets. As an example:
Feature: Multiplayer
In order to push development of the game engine in the right direction
As a player
I want to be able play with and against other players
# There's an interesting aspect of linking (or making accessible) our engine
# to mechanisms beyond that of the game. i.e. Creating an account on a website
Scenario: Login to remote server (cluster)
Given I have created an online account
When I login with valid credentials
Then my account is made available
# Add various scenarios for hacking techniques. Perhaps even start a
# a competition to see who can break into the engine remotely?
# Add various scenarios for server redundancies
Scenario: Changes to the world whilst I was offline are pushed to me
Given my character was killed by another player whilst I was offline
When I join the game
Then I am notified that my character is dead
Scenario: Movement of other players is visible to me
Given my character can see another character
When the other player moves their character
Then I can see their character move accordingly
etc.
I would like for scenarios here to overlap, but not duplicate requirements in Clean Living. That repository is completely idle right now, but I'll begin to expand it once we hammer out this issue. I'd be keen to see people consider games they would like to write, even if it means shifting development focus of you guys from this repo to your respective game(s), simply to drive the requirements of the engine. Or, for someone else to take ownership/control of the Clean Living game?
Holy wall of text batman; I'll leave it there for now. Thoughts?
Proposal:
Let's add some G/W/T's to define the MVP scope.
Although the implementation detail should probably be discussed elsewhere, I'll describe the following with technologies I am familiar with. That's not to say we can't evaluate alternatives.
I apologise in advance for the lack of syntax highlighting for the specflow stuff below, should still be readable I hope. ('#' denotes a comment)
What I have in mind is a series of specflow Given/When/Thens describing some typical (simple) game behaviours to aim for in MVP which will help us progress towards an achievable, measurable goal in January.
Here are some examples off the top of my head:
Some very basic (and very subject to change) examples there. I believe the above alone tackles (and therefore would provide failing tests for) the following items I'd like to see in MVP:
This intentionally avoids the following items that I would like to see for v2 (but may derail a v1 release if included too early):
All of these other elements could, I think, be easily introduced to a model achieving those v1 targets. As an example:
etc.
I would like for scenarios here to overlap, but not duplicate requirements in Clean Living. That repository is completely idle right now, but I'll begin to expand it once we hammer out this issue. I'd be keen to see people consider games they would like to write, even if it means shifting development focus of you guys from this repo to your respective game(s), simply to drive the requirements of the engine. Or, for someone else to take ownership/control of the Clean Living game?
Holy wall of text batman; I'll leave it there for now. Thoughts?
//cc @herecydev @sblackler @danielcirket @mattridgway