Results 1 to 4 of 4
  1. #1
    Join Date
    Aug 2010
    Location
    In my room.
    Posts
    748

    Features and Assets: Clarification and Global Decision rate.

    Hello, In this thread I'd like to talk about Features, Assets and the rate we decide on what to put into the Confirmed Asset List.

    First I need to say what my own definition of a feature is, and what my own definition of an asset is. We can change this, but eventually these two definitions will become locked in for the project to ensure whenever someone utters the world "Asset" or "Feature", everyone knows what they're talking about.

    Feature: A feature is a high level element of gameplay. Something that happens in the game. For example: It would be a game feature to allow players to punch each other in the face. Naturally features go into the game design document.

    Asset: An asset is the building blocks that make a feature happen. Multiple assets could go into making one feature realised. For example: A 3d model, animation data, and code(and much more I'm sure) goes into making the feature "Can swing a sword" happen.

    If there are any questions or clarification that needs sorting, ask away.

    The other thing I want to talk about is the rate the official documents get updated with decisions on stuff we want to implement.

    With such a large scope project, and the fact that we don't really know how much time it will take to create. On top of that, we cannot expect the design document to be fully complete before we start building assets. What I propose instead is for us to establish a system to regularly add things to the official design documents from people's personal design documents on a weekly basis. Things would be decided/announced during the meetings (as they actually for the most part currently are).

    I also think we should make the rate of new decisions to be dynamic, but with an arbitrary start. We would increase/decrease the rate based on the rate of progress in implementing things.

    Here's my numbers, Start off with 1 feature per week, and increase it if it gets done in the week on time. If the feature does not get implemented after a week of it going into the Global design document, we'll add one more feature. If it does get implemented, then we'll increase the rate to 2 new features decided per week. We'd also decrease as needed.

    In terms of assets, I was thinking of starting it at 1 asset per team per week to go into the Global Assets folder. Again, we'd increase and decrease the rate per week decided upon, based on the rate the individual teams are able to produce finished works.

    Hope that makes sense.
    I'm so negative, like an electron.

  2. #2
    Join Date
    Mar 2013
    Location
    Australia
    Posts
    217
    With such a large scope project, and the fact that we don't really know how much time it will take to create. On top of that, we cannot expect the design document to be fully complete before we start building assets.
    In Software development this is what we would call the Waterfall method, Everything gets completed fully before it gets pasted down the chain, from designer to developer to tester. Its an approach that is not very flexible and does not allow for questioning or alterations by team member down the chain like the testers as it could have already included days of work. This approach will not work for this type of project, scale is to large and the teams will change. Instead we need to be more agile with our approach. Taking small chunks of work in regular iterations. Working close together as a team to design, implement and test and if needed send it through the same process again. Its cheaper to fix a problem early than later in the process.

    The agile methodology i'm most familiar with is called Scrum. At a high level features are broken down and added to a backlog (the business side calls these User Story's because you are trying to explain a feature from the point of view of the User). At this point we don't need to know how its going to be implemented. just we would like the feature (or asset). Features are rarely the same size and complexity so its difficult to say that you can commit to one feature a week. What we do in scrum is we have regular planing meetings, we take the things on the top of the backlog (ordered by priority) and estimate points for them. A point is a relative number that factors in Complexity, Risk and Repetition of the task.

    If you compare Task A to Task B you can say Task A is about a 3, or it could be anything you want as long as the other tasks are relative. Then when we go to estimate Task B you can say well its a bit more complicated than Task A and there are some unknowns about how to implement it so i'll factor that in and give it a 5. (this is a very quick crash coarse)

    Now if we work in one or 2 week cycles (Sprints) you will be able to get a reflection of the velocity of the team. On average team A might be completing about 20 points worth of work, so when you plan your next sprint you only take on about 20 points worth of work. That might be 5 small features or assets or it could be 1 big feature or asset.

    I think a lot of the Agile Methodologies will be beneficial for the team. Particularly when it comes to planning and managing your teams throughput.

  3. #3
    Join Date
    Aug 2010
    Location
    In my room.
    Posts
    748
    Well I think what I'm setting up is pretty much the agile methodology you describe just more tailored to this specific project. In your terms, Sprints. I think we'll be doing 1 week sprints, although I wouldn't really describe it as sprinting as I don't think we should put that kind of pressure on ourselves. So I think we're both on the same page here

    P.S. I remember reading something about the waterfall method, the inventory stated before he began "Here's a development system that doesn't work and should never be used". I'm paraphrasing of course.
    Last edited by IronSoul; 08-25-2013 at 09:21 AM.
    I'm so negative, like an electron.

  4. #4
    Join Date
    Mar 2013
    Location
    Australia
    Posts
    217
    lol, yeah it's starting to be a common view in software development.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •