Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Feature Request Design documents

Discussion in 'Open Projects' started by o92design, Oct 30, 2020.

  1. o92design

    o92design

    Joined:
    Jun 19, 2018
    Posts:
    4
    Hi, i've asked this on discord but maybe here is better.

    Will there be any further direction to this? Like an art bible and technical design document. The roadmap is mainly for tasks / issues i would say - for example level design and beach could be anything
     
  2. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Good question. Right now we're using the roadmap also as a game design wiki, you can find it here: https://open.codecks.io/unity-open-project-1/decks/65

    For the art bible, we were thinking of asking the artists we're working with to produce one, to use as guidelines for the community to produce the rest of the art. What kind of information would you expect from it?

    Same question for the technical design doc. To be fair, I know that the design wiki is currently lacking as it is, but that's the whole point: we are building it as we go and some of the information in it comes from the threads here on the forum. And more will be added as we reach an agreement on it.
     
  3. Zold2012

    Zold2012

    Joined:
    Feb 4, 2014
    Posts:
    67
    Hey, I really think a game design document would help organize the project. Every time a stream goes out, the forum gets a new wave of people eager to help but we rely on them wading through pages of the forum to figure anything out. The Unity team could still assign tasks in Codecks and veto decisions in the document, they'd just have a single reference for everything which would speed everything up.

    I've made a starter document to give an idea of what it could look like.
    https://docs.google.com/document/d/198v9JyfS8uIUVxDAIlhBWKOe5fSvBgSVtBt-EvWSDmg/

    If not a complete document like this, perhaps a few smaller documents for each system. we've done something similar for the cooking thread previously.
    https://docs.google.com/document/d/1kGQXAkZul-dptwB6cXT71QrpBMDb8iQW3sdVfDaQ26g/edit
     
    BrettHuang and RunninglVlan like this.
  4. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    But that's what the roadmap is for? Tasks + design docs, in a way that it's easy to navigate.
    And in fact generally design docs or design bibles are starting to disappear in common game design practice, because nobody reads them :/
     
    Amel-Unity likes this.
  5. Zold2012

    Zold2012

    Joined:
    Feb 4, 2014
    Posts:
    67
    if the roadmap worked why are people asking for a design document? The issue with the codeck wiki is its not up to date with the decisions in the threads and it relies on unity keeping it up to date when it could be a community task.

    I can't speak for industry trends but I can speak as to what I'm observing in these forums

    The GUI Wireframing, Inventory, and Cooking threads are all talking about the same system, assuming they know how it works, or asking how it works, having a hard time verifying what they're talking about. Meanwhile, the most the roadmap says is the game "will feature a simple cooking system where you can combine 5 items from your inventory" which isn't descriptive enough to build systems. what is cooking used for? what do the dishes do? we've addressed some of that in the cooking thread already but someone not familiar with that might think its fair game, or more frustratingly, suggest systems that have already been suggested.

    to use @o92design 's example about the beach, we've gone over quite a bit of the beach layout in the level design and now whiteboxing threads but it's not reflected in the wiki. The information that goes over that stuff is largely stuck on a nonofficial thread at the bottom of page 2. Noone just coming into this is going to be able to find that on their own.

    I keep seeing people talk about utensils as an inventory item, but the current cooking system doesn't use utensils, it's instead focused on having the player gauge the quality of ingredients before combining them. Additionally, the proposed systems that did use utensils didn't have them existing as inventory items.

    This confusion has made it difficult (for me at least) to move forward with new design ideas as it's not clear if current ideas are accepted yet. A design document won't immediately fix these issues, but it will allow people to see that the issues exist and resolve them. It doesn't have to be a google document, but it does need to be something that the community has a more direct role in curating.
     
    itsLevi0sa likes this.
  6. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    The open poster said that the roadmap is for tasks, maybe he didn't see the wiki deck?

    2 things:
    - Those threads contain WAAAAAAY too many details which we won't have the time to implement. This needs to be understood by everyone. Not everything that gets written on the forum is "truth".
    - The fact that some important details are not in the wiki cards is our mistake. I will update them. (Edit: I have) But this doesn't warrant the need for yet another doc.

    It's not :) That's why it's not in the cards. Only what's in the roadmap is going to be what we built.

    I was saying it in the story thread and I will repeat it once again: we need to be realistic on the scope of this game. Don't get me wrong: I love the passion behind the ideas, but ideas need graphics, animations, sound, and code made by someone later on and I predict we won't have the time and the contributions. If I'm wrong - and I hope I am - we will expand the gameplay!

    Sorry but that's impossible. It would derail the project in no time. There are thousands of people roaming this forum, we need to have one final word or the project will never come to an end. Hope you understand this :)
     
    itsLevi0sa likes this.
  7. aby_gamemaker

    aby_gamemaker

    Joined:
    Nov 5, 2020
    Posts:
    69
    I believe we need to define some hierarchy and divide departments.

    For example, let's say we have 5 departments:

    STORY AND IDEATION
    ASSET & UI DESIGN
    CODING
    LEVEL DESIGN
    PLAY TESTING

    Once the departments are decided,
    each dept. will have a unity representative(U.R.) leading it with a team leader from the community assisting him and filling in the U.R. of all the work community has done pertaining to that department.

    Now wether each department makes a Game design doc or not it is up to them but whichever makes them they should pick a colour code for their department to enable each community member to freely contribute to all departments if they choose to do so.
    They will just have to keep that many GDD updated.

    So streamlining the forums can be done the same way.
    Let's just decide the departments, color code and make sub forums for the departments and encourage the teams to crush smaller goals consistently.
     
  8. Zold2012

    Zold2012

    Joined:
    Feb 4, 2014
    Posts:
    67
    how many things on the wiki aren't listed because unity team hasn't gotten around to writing them and how many of the things on the wiki aren't listed because they've been rejected?

    for instance, we've laid out suggestions for the types of gameplay obstacles that might require cooking a dish in the cooking document. But it sounds like we're not doing that, so what problems does the cooking system solve? Is it just about restoring health? It is not currently listed on the codecks. If it's not accomplishing much then do we even need it?
     
  9. itsLevi0sa

    itsLevi0sa

    Joined:
    Oct 26, 2019
    Posts:
    128
    @Zold2012 first of all I really appreciate you making this document, you did a great job in organizing it. I felt we needed one too (at least for our gameplay discussions), however we do need to make it clear that this is non-official and just for us, just to have a summary. Ciro is obviously right. We shouldn’t confuse other people that any of the things written in that is “truth”. And if this is something that the Unity’s team might find “dangerous” we should really withdraw it then (or really keep it between us). However, I do feel that it would be nice to keep a track of people’s ideas as something interesting might come out of it and somebody might be interested to try something out from all this, for their own’s sake, regardless of this project. It might also help any newcomer who would like to catch up with what the community has been discussing, instead of reading endless pages of threads. And it could also make a nice “record” in the end of all the community discussion highlights after this project is over. No need to make it more complicated, no need for moderators or bring any other headache to Unity’s team, we could just have the link lying here, and whoever wants, and whenever they feel, they might add something.
     
  10. cirocontinisio

    cirocontinisio

    Joined:
    Jun 20, 2016
    Posts:
    884
    Your question is valid and in a normal development process we would make assumptions, create prototypes, validate which ones makes sense and are fun and understandable, and throw away the ones that don't.

    In our case, we don't have all this time and coordination. Adding a gameplay feature and letting somebody work on it for a couple of weeks, just to throw away their work (which might be the only code from them that makes it into the game) because it doesn't fit or there's no time to fully develop it is a route we cannot go down.

    So, with this in mind, the plan is to add a few things to create some potentially interesting gameplay, in the sense that they might not be fully developed for the scope of this demo, but they would be for the hypothetical full game.

    For instance, you mention the effects of eating food. The team and I are thinking that the only effect should be to cure the chef. That is mega easy to implement from a programming standpoint (it just requires us to bump up the energy bar, right?) but it gives you an idea of the potential other effects the food could have.

    At the same time, if you think about it, it might be useless in the demo: the fights are probably not going to be SO hard as to require healing during the fight.

    So to answer your questions regarding the cooking system:
    - Do we need it? No, we don't need it.
    - Are we going to have it anyway? Yes, since many people from the community really want to put it in.
    - What purpose does it solve? Creation of dishes which: A) advance the story, B) heal the protagonist, and C) make you win the game.
    - Is that it? For now, yes. We can think of additional effects and impact on the gameplay/fights as a 'stretch goal', that is something that we can think of adding after we have 90% of the gameplay in place.

    How does this sound?
     
    Last edited: Nov 7, 2020
    shuttle127 and itsLevi0sa like this.
  11. Zold2012

    Zold2012

    Joined:
    Feb 4, 2014
    Posts:
    67
    That sounds understandable. In that scenario the problem being solved by the cooking system is, "specific npcs want specific meals" as long as the system is used more than once it has a purpose. It had been difficult up till now to think about how to lay things out like level design because I couldn't tell what the gameplay wanted to do. There are plenty of games like "short hike" where the method of interaction is mostly walking around an environment and talking to npcs, however the idea that there would be some form of alternative combat made it unclear what the focus was. My push for the document was mostly just to collect these ideas so we could see them all and then choose one that would go into the codecks.

    The last concern i have is regaurding the chick. There is the idea the chick can be used to burn environment items, should that be it's own self contained thing, something you have to feed the chick for, or is it worth pursuing now?