Post Mortem, Team Projects and Advice to Finish your Game!

Discussion in 'Non-Maker Specific Tutorials' started by Archeia, Dec 21, 2018.

  1. Archeia

    Archeia Level 99 Demi-fiend Staff Member Developer

    Messages:
    14,512
    Likes Received:
    14,141
    Location:
    Game Dev Salt Mines
    First Language:
    Filipino
    Primarily Uses:
    VNM
    This is a paraphrasing and an edit of a post mortem of a game which I think contains a lot of great advice in regards to team work and just game creation as a whole. But it also contains my own experiences with team projects and some stories my fellow game developers shared me.

    Why do Team Projects Fail?
    Here's a table of possibilities. It's not all of them but it's to give insight why it might or might not work out.

    Lead Dev Team Mates Possible Conclusions
    Passionate about the project but is only an ideas guy. Free or only interested in building their portfolio.

    - Game is in Jeopardy.

    - Team Mate might leave early.

    - Inconsistent quality across the board if ideas guy managed to get replacement unless they are really, really good or the art was simple to begin with.

    Passionate about the project but is only an ideas guy. Passionate about the project and does all the work.

    - Game is in Jeopardy.

    - Team mate will start to believe it is their game.

    - Team mate gets annoyed if lead dev removes their ideas or just very controlling when they are doing all the work.

    - Team mate will leave to make their own version of the project instead. Since all the art assets are theirs, they are free to recreate it or whatsoever.
    Passionate about the project and does majority of the work. Passionate about the project and does majority of the work. - They will finish the project as long as their standards aren't too high and keep a reasonable time table and deadlines.
    Passionate about the project but does not know what they want or changes their mind too often. Passionate about the project and does a lot of work.

    - Game is in jeopardy.

    - Team mate will get sick working with Lead Dev.

    - Team mate might try to ghost lead dev.

    Once Passionate but lost interest. Does not even contact their team mates about this and just disappears. Does a lot of the work and thinks it's still in production.

    - Team mate will stop working on team projects because they felt like their time is being wasted.

    - Lead dev will have a hard time finding help on a new project if team mate has a lot of friends and gets a warning from them or if their issue is publicized.

    - This also applies to vice versa.

    Passionate about the project and does a lot of work. In it for the money.

    - Game might get finished.

    - Don't expect much feedback from Team Mate. All they want is to get paid and get home.

    Passionate about the project and does a lot of work. Passionate about their craft but has low self esteem and especially when money is involved.

    - Game is in jeopardy.

    - Team mate might ghost Lead Dev because of the pressure or they felt that they failed Lead Dev.

    Passionate and does all of the work. Mildly interested and helps sometimes.

    - Game is in jeopardy.

    - It might take Lead Dev decades to finish their game. Unless they have great time management skills and discipline.

    - Quality will be inconsistent as dev goes on.

    - If Lead Dev does finish it, good job!

    Just wants to make a game. Any game. Preferrably Short. Just wants to make a game. Any game. Preferrably Short.

    - Game might get finished.

    - This might be for a short game jam like Ludum Dare.

    - Or the Lead Dev and Team Mate have amazing chemistry and they just do it.

    - This is really rare and you are one lucky person to even have such a person.


    Every Project Has a Shelf Life

    No matter how much or little financial backing you have, who you're working with, or how good you are. Every project has a shelf life. Eventually, the development team is going to get sick of each other or sick of the project. There will simply come a time when the scope must finally be altered backwards instead of forwards. Deadlines will slip. Money will vanish. Members will be put into a position by their real lives where they must move on to something else.

    Set deadlines, stay in your scope, and finish it. Worry about polish and adding features in later. Never, ever forget this.

    Make Deadlines and Project Plans. Learn How to Manage! (Part 1/2)

    Your initial choices can be a life and death situation for your project. It can also be your financial ruin.

    Never ever underestimate how bad management can ruin you. People will start to leave, hating to work with or for you and so on.

    Make deadlines and stick to them - it will keep you from wandering off and working on things which aren't crucial. Make project plans that are detailed, assign tasks to everyone, and then make sure they understand and agree to those plans. If they have concerns with anything, later on is NOT the time to bring them up.

    If you fail to start with good, detailed plans, then you will start working on things that don't really matter yet. If you make plans and don't stick to them, then it's the same as having no plan at all. If you don't share plans and changes to the plans with everyone else, don't be surprised when they get pissed off.

    Allow plenty of slack time in the plans for real life. It WILL get in the way, and there's not much you can do about it when it does.

    Make Deadlines and Project Plans. Learn How to Manage! (Part 2/2)
    • Learn Sprint or some type of project management plan.
    • Use a tool or website if you have to.
    • Make use of tools like Gitlab or Github and frequently commit and push to create backups.
    • Create branches for alpha beta builds to avoid losing your project to an update.
    • Milestones. Milestones. Milestones.
    • Assign Tasks and make sure to make them post in there to keep a record.
    • Enforce your team mates to write issues so you can keep track of every single bug reports or pending implementations.
    • ALWAYS ask for the source PSD or file in case something happens to your team mates.
    • ALWAYS backup your source files in case something happens to you.
    • Places like Gitlab and Github are amazing and you should use them.
    Communication is Key

    Choose a medium that is conducive to good communication that automatically creates records of conversations. Email, Forums and places like Github/Gitlab are great for this.

    Don't rely on Chat Services or IRC. They shut down often, and seldom create usable logs for future reference. Time is also of the essence on IRC and chat rooms. If you don't reply to something right away, then bringing it up later is often confusing, and anyone that does not happen to be paying attention at that moment will have an equally frustrating time replying.

    Email, Forums or places like Github/Gitlab are sequential, regardless of timing. Everyone has time to voice their opinions and ideas, and they can reference other posts that are RIGHT THERE while doing so. In addition, it enables everyone to work on the project at any time of day or week and still stay in the loop - something that IRC or chat doesn't do.

    Keep tight control of your communication channels. Don't let just anyone join. Otherwise, you will spend a lot of time doing admin work and the trolls will never leave. It's better to spend the time to specifically allow people, and to be able to immediately and permanently remove them if they start causing problems.

    Email is only really good for private conversations, and should be used as such. Don't air your dirty laundry in public and assume no-one will see it, because it has a very high chance of biting you in the ass and creating unnecessary tensions.

    Talk about EVERYTHING. Reach an understanding on EVERYTHING. If someone is going off-task, then tell them. Don't keep your concerns under your hat until they boil over and blow your head off. Letting things build up and explode can take you, bystanders, and the entire project with them. If you need to yell, do it and get it over with instead of waiting until later. What comes out of your mouth/keyboard later will only be that much more vile.

    Documentation is Important!

    Document. Document. Document.

    If code is poorly commented, often unspecific and unhelpful, they are useless. If you forget how to do a function, you will have to spend a lot of time reading code or hunting down old logs to do a certain thing. Or completely forget you implemented a feature.

    If documentation on art pipelines, map editing, and more were non-existent, replacements and fixing will take longer.

    You will have to keep explaining how to do very basic things to newcomers is a huge waste of time. Good tutorials and documentation would have alleviated a lot of this.

    Make use of your tools. Github/Gitlab have Wikis. Google Docs and Sheets exist.

    Use Placeholders

    When you implement something, waiting on the graphics guys to send assets to you so that you can get started is really not a good idea. The problem is that once implemented, if what has been done was not well thought out in advance then the assets will need to be modified or they will be wasted if the result isn't what was desired. After having the latter happen more than once, I simply refused to finish and submit assets until the game play mechanics had been tested FIRST and the assets were certified to be necessary.

    The same goes to implementing a new feature and asking your programmer to do it. A game is a full package. It's not some kind of lego box that you can easily remove things without affecting anything else. The seemingly simplest features tend to be the hardest ones to change. Here's an example of what I mean:

    Once, we were asked to implement stat distribution during a battle's victory scene to prepare for a demo release. We implemented it and the Lead Dev told us, "It wasn't as good as I thought and hard to balance. Just remove it."

    Not only were our motivation was shot, implementing that in such a crunch time was a miracle in and of itself. But "just remove it" is not as simple as it sounds. It's tied to the battle system and "just removing it" will compromise the stability of the game.
    Therefore, only ask for features once you create a scenario where you can imagine the game around it. By that I mean, do a tabletop version of your game and DM with yourself or something. Start thinking about how it's going to affect your game balance and if it's going to be fun.

    If you don't want to do that, create the feature through some hack show choices in an empty project and try working with that feature and see if you REALLY like it. Then ask your programmer.

    Otherwise you're just wasting their time and pissing them off.

    Make your Event or Code Modular (Reusable)

    Don't do your first rodeo without a plan. When you create code without planning it out in advance and knowing everything that will have to be changed to make it work, you are going to spend weeks implementing something that should have taken a few days. This sort of approach will simply create far more problems than it solves, and the next 20 updates will be focused on fixing new bugs.

    Always design your events or anything as modular as possible. Experience helps you think of ways to avoid past mistakes but always think about the future you when doing something.

    Let's say for example:

    You have a map that contains 5 cutscenes. The problem is they're heavily animated cutscenes and you missed the memo that one of them was supposed to be optional. The problem is you made it mandatory. Removing that will cause you to debug the entire map repeatedly to make sure that nothing is broken.

    How could you have avoided this? There are many ways. But here's one way you can do it.

    Create a copy of the map for each instance and create cutscenes there. You can also make it that if 2 or more cutscenes are minor, you can place them on the same map and just reserve a new map for the big one. The problem is however, you need to take into consideration future updates of the map. If you keep track of changes and add memos, inconsistencies will be mitigated.

    Quality Takes Time

    2D Art and scripts takes time. Don't expect to ask for something and get it immediately unless that person is a pro and you are paying some mad bucks. Which let's be real, most of us don't have.

    Let's do a quick summary of how long it takes to do a 2D Bust art from someone who is a pro:
    • Sketching or Concept - Takes days or weeks going back and forth with Lead Dev.
    • Lineart - Can take 2 hours to a week depending on how detailed it is.
    • Painting / Coloring - Can take 6 hours to 1 week depending on how detailed it is.
    • Quality Review - IF you find an error, let's hope you can easily fix it or risk redrawing the whole thing.
    A lot of people seem to ask for a 3D RPG Maker. And not only that 3D Programming requires a lot of math and knowledge, art assets have professional companies with staff dedicated to just rigging. I think this developer said it best.

    Create Re-usable Assets

    This applies to everyone. If you are making something that can't be re-used later, or isn't made from parts that can be re-used later, you need to seriously stop and try to find another way to do things. In code, if you create something that can't be copied and pasted or easily expanded, then you need to re-engineer the code. This is why some programmers have Core or Module scripts to avoid repetitive code.

    As an artist, you need to create as many general use assets as possible: basic materials, skeletons that can be re-used, level textures that are not 100% specific to any place in the game, parts that can be recombined into new assets and more. By doing this, you'll have something that looks and feels more consistent when you are finished, with principles that can be applied to more than one place.

    By failing to do this, you'll need to create a lot of assets every time you make something new, and that's going to eat your time.

    Do Not Upgrade Unless Absolutely Necessary

    A huge mistake people often do is upgrading their RPG Maker or plugins when they're in late development. If it works, don't upgrade. If you absolutely need a fix from a new update, make backups and know proper updating procedure, don't upgrade and yell at the devs for breaking your project. Or telling them to "take responsibility." Your project is your responsibility.

    Share Your Progress!

    Don't be afraid to share your progress in Social Media such as Twitter, Facebook, Tumblr, Forums etc. Keeping quiet will just make giving it attention later much, much harder considering how saturated the market is. Make use of hashtags! Here are some examples that everyone in this topic shared too. And this reddit thread.

    General Game Dev
    RPG Maker Specific:
    • #RPGmaker
    • #RMMV
    • #RMVXA
    • #tkool
    • #RPGツクール
    • #ツクール
    • #ツクールMV
    • #ツクールVXA
    If you are worried about people stealing your ideas, then...whew....

    Releasing Demos or Early Access

    Releasing a demo or Early Access is tricky and it will highly depend on what type of game you are trying to make. And it can be a double edged blade.

    I'd say that if it's your first ten games and you really want feedback it does not hurt to release something and get people's attention. But realize that the community can be saturated. And it's even rarer for people to play your game and give feedback. It will require the same amount of effort from your side to give feedback in order to receive one. Joining Discord channels will help you gain some friends (or enemies if that bad) but there will be quite a lot of socializing involved.

    I also recommend at least releasing 30 minutes to 1 hour of gameplay.

    Just remember that if you do release something:
    • Do not think of it as a personal attack to you as a person.
    • Your game can always be improved. Nothing is perfect.
    • Learn how to separate feedback that supports and one that completely misses your vision. Nobody said you have to apply it all.
    • Don't forget to thank people for their time for reviewing and giving feedback to your game!

    Community Comes Last

    This is not to say that the community should never be involved, but building a community is something that should happen at the end of a project, when it is finished or nearly finished. Creating a community too soon invites trouble that you definitely do not want.

    Community members will want to make their opinions known, and since everyone wants to be liked there is a really high chance that these opinions will be taken seriously. This will lead to a lot of second guessing of the plan, implementing new things, tweaking other things, and generally wasting time that needs to be spent actually making progress and finishing the project. Some of these things might be great ideas, but DON'T DO IT.

    Implementing community wishes and wants before the project is done is like the dark side of the force: Once you give in, it will forever dominate you. And it will also forever distract you from getting to the goal.

    Community is one of those things that certain developers do right. Valve comes to mind immediately. Team Fortress 2 is updated constantly, and it continually involves community members and keeps them interested. But one thing to keep in mind is that before there was a community, there was a finished game, and that makes ALL the difference in the world.

    And that's it. Enjoy.
     
    Last edited: Dec 22, 2018
    #1
  2. bgillisp

    bgillisp Global Moderators Global Mod

    Messages:
    11,575
    Likes Received:
    11,561
    Location:
    USA
    First Language:
    English
    Primarily Uses:
    RMVXA
    Can I shout this from the rooftops? I keep telling people this over and over and over.

    And those are good points on time. Someone once said to take the time you think it will take to make the game. Now double it. Double it again. Double it one more time. Now you are probably close to reality.

    And finally, I'd like to add one point on money spent, as I didn't see that addressed. Only spend the money on the project you can afford to never see again, especially if it is your first. This way if you don't finish, you didn't cripple yourself financially in the process at least.
     
    #2
    Elliott404 and Archeia like this.
  3. Silenity

    Silenity Veteran Veteran

    Messages:
    637
    Likes Received:
    232
    Location:
    Oregon
    First Language:
    English
    Primarily Uses:
    RMMV
    This is some really sound advice.
    Now, if only I could take it. :L
     
    #3

Share This Page