ZFGC

General => King of Thieves => Archive => Software Engineering => Topic started by: MG-Zero on June 08, 2011, 02:02:04 am

Title: Requirements Due Date: 6/15
Post by: MG-Zero on June 08, 2011, 02:02:04 am
The requirements gathering phase will be first.  All I ask is that members of the Software Engineering Division post here the rules and requirements of a BASIC Zelda Engine.  I will gather these together myself at the end of the week and form them into a document.  You can post any requirements you feel are needed here. 

NOTE: In general, requirements are formatted as: "The system shall/shall not/should/should not [verb]" but I don't require this.  Just an optional guideline if anyone wants to follow it :)
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 08, 2011, 02:07:28 am
I'll throw a few down to get it started...

The player shall start with a minimum of 3 hearts and have a max of 20.
The player shall have a refillable magic meter.
The player shall at all times be notified of their current health and magic status via the HUD.
Title: Re: Requirements Due Date: 6/15
Post by: . on June 08, 2011, 02:25:04 am
The player shall have the ability to move via the keyboard.
The player shall have the ability to use a sword.
The player shall have the ability to set items and tools to one or more keys whether or not the sword is an interchangeable item.
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 09, 2011, 11:50:20 pm
The HUD shall consist of: Hearts, magic meter, action icon, item icons, a rupee counter, and any additional icons that may be needed in the future.
The HUD shall be designed with expandability in mind.

C'mon guys, keep em coming :P
Title: Re: Requirements Due Date: 6/15
Post by: . on June 10, 2011, 01:34:59 am
The system should include basic movement functions such as roll, pick up/throw, jumping off ledges, and stairs.
The system should include dialogue among signs and NPCs.
The system should include simple room transitions.
The system should include a variety of NPC types such as stationary, roaming, and path following.
EDIT: The system should include stationary NPCs.
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on June 10, 2011, 01:37:09 am
The system should include basic movement functions such as roll, pick up/throw, jumping off ledges, and stairs.
The system should include dialogue among signs and NPCs.
The system should include simple room transitions.
The system should include a variety of NPC types such as stationary, roaming, and path following.

The last statement isn't basic at all. We're talking BASIC elements here. Something that includes path finding is not considered basic, in my opinion. Anything NPC-related should not be included in the "basic" engine; we should limit it to speaking with NPCs only if they are stationery.
Title: Re: Requirements Due Date: 6/15
Post by: . on June 10, 2011, 02:20:43 am
I wasn't saying path finding. I said roaming and path following. Roaming would move around randomly (with no specific goal) and path following wouldn't have to find a path because we would set one to it, though you are right that they probably aren't for the basic engine.
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 10, 2011, 02:22:46 am
So would you say an appropriate change to your requirement would be something like...

The system shall have npcs with basic functionality including movement and text-based interaction

?
Title: Re: Requirements Due Date: 6/15
Post by: . on June 10, 2011, 03:26:37 am
I changed it in my original post, but yes something to that effect.
Title: Re: Requirements Due Date: 6/15
Post by: Wasabi on June 10, 2011, 07:55:29 am
The player shall be able to swim.
The player shall be able to ledge jump/building jump.
The player shall be able to walk tightropes.
The player shall be able to climb.
The player shall be able to roll.
The player shall be able to take damage.
The player shall be able to perform actions on other objects.
The player shall be able to perform actions on NPCs.
The HUD shall include a rupee counter.
The HUD shall include a magic meter.
The HUD shall include a heart meter.
The HUD shall show dialog boxes where required.
The System shall be able to freeze control from the player when required (eg. cutscenes).
The System shall animate tiles as required.
The System shall play sounds when required.

And I'm done for now.
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on June 10, 2011, 01:46:31 pm
So would you say an appropriate change to your requirement would be something like...

The system shall have npcs with basic functionality including movement and text-based interaction

?

I still consider this to be outside of a basic engine. Movement requires some sort of intelligence. The NPC characters do not have to move for the engine to be fine.

Quote
I wasn't saying path finding. I said roaming and path following. Roaming would move around randomly (with no specific goal) and path following wouldn't have to find a path because we would set one to it, though you are right that they probably aren't for the basic engine.

Roaming and path following both include algorithms that are "pathfinding". I wouldn't say roaming is 100% random either.
Title: Re: Requirements Due Date: 6/15
Post by: Cassyblanca on June 10, 2011, 02:58:47 pm
Roaming and path following both include algorithms that are "pathfinding". I wouldn't say roaming is 100% random either.
This is true - roaming needs basic controls to keep the character from roaming away from the game area, and "path following" is literally pathfinding.

I still consider this to be outside of a basic engine. Movement requires some sort of intelligence. The NPC characters do not have to move for the engine to be fine.
Given the number of tasks we're assigning for other areas, I wouldn't say that this is outside the requirements of a basic engine. No NPC in a Zelda game is going to need any pathfinding on the level of implementing either the A* or Djikstra algorithms, and implementing a minor roaming algorithm or "path-selection" system involving preconstructed roaming paths is trivial to implement in a properly-written game system.
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on June 10, 2011, 09:52:40 pm
Roaming and path following both include algorithms that are "pathfinding". I wouldn't say roaming is 100% random either.
This is true - roaming needs basic controls to keep the character from roaming away from the game area, and "path following" is literally pathfinding.

I still consider this to be outside of a basic engine. Movement requires some sort of intelligence. The NPC characters do not have to move for the engine to be fine.
Given the number of tasks we're assigning for other areas, I wouldn't say that this is outside the requirements of a basic engine. No NPC in a Zelda game is going to need any pathfinding on the level of implementing either the A* or Djikstra algorithms, and implementing a minor roaming algorithm or "path-selection" system involving preconstructed roaming paths is trivial to implement in a properly-written game system.

Yes, I understand it's not a high level of intelligence compared to other NPC roaming, but I still don't think it should be prioritized in the basic engine. That is all I'm saying. With the amount of stuff listed, the team already has plenty to work on.
Title: Re: Requirements Due Date: 6/15
Post by: Cassyblanca on June 10, 2011, 10:06:19 pm
What's listed thus far won't take much time at all to implement. Assuming the selection of C++ or C# as the core development language, it will take more time to implement the game engine systems - these aren't a very difficult addition to the system, and are tasks that could likely even be handled by a single developer (given sufficient understanding and experience).
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on June 10, 2011, 10:17:24 pm
Well, I'm still standing by my opinion that this kind of thing should be done in another sprint. We'll see what gets decided.
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 12, 2011, 02:54:35 pm
No, this stuff def. should not take long.  However, I just noticed that we've only come up with gameplay elements and have not mentioned any engine structure, so lets try to fill those in as well.  For example..

The system shall use states to determine how the engine should function (title screen, paused, in game etc)
The player should use a state swapping system as well (shooting, normal, horse riding etc)
The system shall use a base game object class from which all other game objects are derived
Title: Re: Requirements Due Date: 6/15
Post by: Cassyblanca on June 12, 2011, 05:20:46 pm
I think that will depend largely upon the poll, though I suppose C# may as well be declared the victor at this point. However, I don't think it's very appropriate to discuss system structure until a structured team has been formed for the engine development and their experience can be gauged. It's a small matter for either of us to write a robust FSM, but we can't guarantee that all working on the development side of the house will even know what we're talking about.

At the very least, system structure requirements should be done separate from the higher-level engine goals - preferably with only those that will be participating in the actual programming of the structure having a say.
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 12, 2011, 06:11:15 pm
I was talking in general terms, i.e. not noting specific structures (although I seemed to do that with the 3rd one on that list..) so they could be applied to whatever language was chosen.  It's not difficult to implement states into any of the above languages for example.  It will also be necessary when we're designing game objects to know how the engine is going to handle them.  But, considering how early we are, it can probably wait.  The lower-level engine requirements for the most part will probably make themselves apparent as we're working on scenarios and such.

EDIT: Actually yea, going by the current project plan, I jumped the gun a bit.

We'll have to work out who's doing programming, UML or both at some point as well.  On another note, half of this division has not yet responded to the PM that went out.
Title: Re: Requirements Due Date: 6/15
Post by: King Tetiro on June 14, 2011, 06:10:02 am
Here's what I think

-Should have the menu system
-Should have the game over screen
-Should have environment hazards and obstacles (Aka the pit of doom)
-Should not only have the sword, but the rest of the items that the player will acquire
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 14, 2011, 01:05:44 pm
Well, we currently don't know what all of the items are, so we can't do that yet.  The other 3 sound good, though!
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on June 14, 2011, 04:01:34 pm
Well, we currently don't know what all of the items are, so we can't do that yet.  The other 3 sound good, though!

I think it should be more like this:

-Should not only have the sword, but placeholders for the rest of the items that the player will acquire.

As much as we don't know the items, we can put placeholder images. We don't have to have a use for each item, but we can at least put in the images to space out the menu/make sure it's properly formatted.
Title: Re: Requirements Due Date: 6/15
Post by: Cassyblanca on June 14, 2011, 05:16:48 pm
Don't listen to her, she's Canadian!

I don't think placeholders should really be done, either, as we don't actually know how many items will be used. The design (and thus, implementation) of the menus will be greatly influenced by the selection of items, so focusing on creating an inventory system that will just be completely changed later on won't do too much good. As far as items are concerned, initial focus should be on creating functionality (which can have placeholders without fear of a complete redesign), simply mapped to buttons that won't end up being used as such in the game to test functionality of different item archetypes (such as thrown, swung, and conditional-use items) until the item selection and designs are finalized.

For example: In a basic engine test, we might map the 'I' key to test a thrown weapon prototype (such as a boomerang), 'O' to test a spell prototype, and 'P' to test a special item, such as an instrument system (Ocarina/harp/whatever).
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 15, 2011, 01:46:04 am
Well, we know the general functionality of a Zelda menu, so creating a prototype to test so said functionality with a few placeholders here and there shouldn't be a problem.
Title: Re: Requirements Due Date: 6/15
Post by: King Tetiro on June 15, 2011, 07:01:52 am
Don't listen to her, she's Canadian!

I don't think placeholders should really be done, either, as we don't actually know how many items will be used. The design (and thus, implementation) of the menus will be greatly influenced by the selection of items, so focusing on creating an inventory system that will just be completely changed later on won't do too much good. As far as items are concerned, initial focus should be on creating functionality (which can have placeholders without fear of a complete redesign), simply mapped to buttons that won't end up being used as such in the game to test functionality of different item archetypes (such as thrown, swung, and conditional-use items) until the item selection and designs are finalized.

For example: In a basic engine test, we might map the 'I' key to test a thrown weapon prototype (such as a boomerang), 'O' to test a spell prototype, and 'P' to test a special item, such as an instrument system (Ocarina/harp/whatever).

Made my day :P

I think it's good to assume we'll have the following items
-Bombs
-Boomerang
-Bow
-Bottles

The four B's!
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on June 15, 2011, 05:29:56 pm
Oh, awesome, these are due today :)  I'll have these doc'd up when I get home!
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on June 15, 2011, 06:12:20 pm
Don't listen to her, she's Canadian!

I don't think placeholders should really be done, either, as we don't actually know how many items will be used. The design (and thus, implementation) of the menus will be greatly influenced by the selection of items, so focusing on creating an inventory system that will just be completely changed later on won't do too much good. As far as items are concerned, initial focus should be on creating functionality (which can have placeholders without fear of a complete redesign), simply mapped to buttons that won't end up being used as such in the game to test functionality of different item archetypes (such as thrown, swung, and conditional-use items) until the item selection and designs are finalized.

For example: In a basic engine test, we might map the 'I' key to test a thrown weapon prototype (such as a boomerang), 'O' to test a spell prototype, and 'P' to test a special item, such as an instrument system (Ocarina/harp/whatever).

*cries* wawawwawa I'm offended.

Yeah sure, sounds good bro. I'm excited to see this spectacular document of SPECTACULAR QUALITY!
Title: Re: 28
Post by: Dantztron 3030 on December 06, 2011, 06:24:58 am
Utterly pent written content, Really enjoyed looking at.please feel free to visit these:Jimmy Choo Handbags (http://www.shophandbagstyle.com/jimmy-choo-handbags-c-10.html)

DUDE SOUNDS LEGIT, TELL ME MORE
Title: Re: Requirements Due Date: 6/15
Post by: DJvenom on December 06, 2011, 07:18:18 am
He rhymes too, holy !@#$%. Pent, Content. Please, These. WHOA!
Title: Re: Requirements Due Date: 6/15
Post by: thestig on December 06, 2011, 07:41:56 am
Jimmy Choo Handbags (http://www.shophandbagstyle.com/jimmy-choo-handbags-c-10.html)
Jimmy Choo Handbags?! No way! Mr. Walkway has some competition, it seems. xD
Title: Re: Requirements Due Date: 6/15
Post by: MG-Zero on December 06, 2011, 02:13:01 pm
...What?
Title: Re: Requirements Due Date: 6/15
Post by: Starforsaken101 on December 10, 2011, 02:27:47 pm
Everyone LOVES Jimmy Choo!

Contact Us | Legal | Advertise Here
2013 © ZFGC, All Rights Reserved