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

Typical Game Development Workflow

Discussion in 'Getting Started' started by MICBIRD03, Sep 21, 2018.

  1. MICBIRD03

    MICBIRD03

    Joined:
    Sep 16, 2017
    Posts:
    9
    Hi guys! I’m new to Unity and the developing world and was curious if anyone would be willing to share what a typical workflow might look like for creating a game?

    Would love to see the key steps how an idea might go from concept to completion.

    Thanks so much,
    Michael
     
  2. JoeStrout

    JoeStrout

    Joined:
    Jan 14, 2011
    Posts:
    9,859
    I usually prototype the hardest/weirdest/highest-risk thing first. So, if my idea for a game involves pushing blobs of jelly around with chopsticks using VR controllers, then I prototype that jelly-and-chopsticks-controller system first. I don't worry about how pretty it is; I just get something running and make sure that I can actually do it, and that it feels fun.

    If it doesn't feel fun, or if I conclude it's not doable, then I cut my losses and move on.

    If it is doable and feels fun, then I iterate: pick the highest remaining risk, and prototype that. And repeat. The result is something that looks more and more like the real game. Eventually there are no risks left except that I will never finish the game, so I tackle that one by aggressively limiting scope creep, polishing the thing up, and pushing it out the door.
     
  3. Vryken

    Vryken

    Joined:
    Jan 23, 2018
    Posts:
    2,106
    The golden rule is to break down large tasks into multiple smaller tasks.

    Want to add guns in your FPS game? Then before adding any features like models, animations, sound effects, particle effects, ammo capacity, etc...
    What you should do is:
    1. Get the game camera to follow your cursor's movements.
    2. Click your mouse to generate something that would apply damage (IE: a raycast or prefab).
    3. Test if your damage system works by firing on an object and having it log some message in the console when hit.
    4. Add some firerate time so that holding your mouse click doesn't make it fire every frame (unless desired).
    Etc...
    Then once you are satisfied with the core functions, that's when you could start adding any special features.
     
  4. MICBIRD03

    MICBIRD03

    Joined:
    Sep 16, 2017
    Posts:
    9
    Thanks Joe! Appreciate the response
     
  5. MICBIRD03

    MICBIRD03

    Joined:
    Sep 16, 2017
    Posts:
    9
    Thanks!
     
  6. RobsonCozendey

    RobsonCozendey

    Joined:
    Oct 19, 2013
    Posts:
    69
    I like a lot the spiraling approach: to build a complete game, technically speaking, but in the most skeletal way possible, and then go adding, refining, and polishing it.
     
    MICBIRD03 and JoeStrout like this.
  7. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    11,847
    TLDR: I come up with the idea, investigate it and other similar games, scope the game completely, decide if I want to go ahead, and then dive in.


    I can't speak to what is "typical", but my approach goes along these lines:

    1) Come up with the idea - This can come from anywhere, but most often I want to play a specific type of game but I'm unable to find one like I am looking for. I've also created games for a specific purpose other than to make a great game, such as the first game I put on Steam I made because it would be a simple game to create and I wanted to run through the paces of submitting to Steam on something I didn't care as much about compared to something I was putting years into.

    2) Research potential demand and competition - So even if the game I want doesn't exist, there are of course going to be games that have at least some similarities, so I look at what they are doing, what features they have, maybe actually play them, and look at what I can find as far as user response and roughly how well they have been selling, and especially what their users are complaining about. Even if you don't have sales number, you can at least look at other numbers such as the total number of reviews (a game with thousands of reviews on Steam has sold many times more copies).

    3) Scope the project - Here is where I sit down and plan out every high feature I want in the game, from the user's perspective, and then break those features down into components of those features. Basically one big outline of the game. If I'm unsure about things I may do more research into other games, or create a prototype. Then I go through all the features and their components and give rough time estimates, and if there are any expenses attached I estimate those as well (such as buying assets or paying a modeler).

    At that point I go through everything again and rate each feature and each component from "Nice to Have" to "Required". After that I look at only everything I rated as Required and ask myself if this game is really what I had in mind to make? Would I be happy if this is the game I made, and would it live up to my vision for it? If the answer is no, I go back and rerate everything and repeat.

    Once the answer is Yes, then I add up all of the time and $$$ estimates for everything required, and see if that is something I would want to commit to. If I think I could really budget more time or money, I'll start adding in some of the more optional features/components. If the answer never gets to Yes, then I shelve the idea entirely.

    4) Plan out the rough order of the project - So I'm happy with the game I want to make, so now I start planning out what order to develop the project. I generally build out features with basic functionality first to try to get as much of the game working at a minimal level as possible, to get to something playable as quickly as I can, and then return to finish developing those features later. If I'm going to be dependent on a 3rd party, such as building models, I start planning when I will need to contract for them in order to get them when I will need to implement them. Sometimes I write this all down, sometimes I just plan it out in my head.

    5) Get started - Now that I have a detailed plan of what is going into the game and what to work on first, I just get going on it. As soon as I have something playable I try to draft my friends in to play it, and will make rather trivial changes based on their responses fairly quickly. Anything large I will see about fitting into my plan, and judge whether it is worth adding.

    More on that, while developing I'll be coming up with all kinds of ideas on my own as well, in addition to player feedback. If the idea is more than a few hours of work I'll just add it to the list of what I want in the game, estimate its time and cost, and rate it against everything else. It is important to not get distracted from the plan and start just implementing anything you think of as it comes up, because if you do you may have a fairly uneven game (where certain features are developed to a ridiculous level, while others are pretty simple) or your 8 month plan may turn into several years.

    6) Don't throw away any ideas you didn't use - Any ideas that didn't make it in the game aren't wasted. If the game does well they are all candidates for getting into later patches, expansions, DLC, or a sequel. As well as any player feedback. Also don't just blindly implement anything a player suggests. Just because they think something should be a certain way doesn't mean they will like it when they get it, or that it won't piss off other players.
     
    MICBIRD03 likes this.
  8. MICBIRD03

    MICBIRD03

    Joined:
    Sep 16, 2017
    Posts:
    9
    Thanks so much! Appreciate you taking the time to respond!
     
  9. MICBIRD03

    MICBIRD03

    Joined:
    Sep 16, 2017
    Posts:
    9
    Thanks
    Thanks Joe! This was exactly the type of thing I was looking for.