Bedouin Posted March 8, 2020 Share Posted March 8, 2020 Before You Read If you’re planning a game, make sure to read Planning Your Game Part 1: How to get started. If you know how to program and are planning a game, you have applause from this corner. Being able to do things yourself is the most efficient and time-saving route you can take. If you don’t know how to program, I strongly encourage you to learn. Even if you don’t learn to the level that you need to build a game, it will help you better communicate with your programmer, understand their time requirements, and help both of you not be as stressed in your relationship. If you plan to hire a programmer, be sure to read So you want to be a Site Owner, but have no idea anything about Programming … which has a lot of great advice. Note that this guide is written from the standpoint of hiring a programmer but could easily apply if you are programming the game yourself. Project Management Staying organized and having your whole team on the same page is very important in large, long-term projects. Having everything clearly laid out helps the owner, programmer, artist, and moderators to know their responsibilities and deadlines if applicable. There are numerous project management tools out there but I’ll just list a few of my favorites that are free. Teamwork If you only need 1 or 2 projects, Teamwork is the way to go. The free tier includes all features so you can use it to its full potential. Features include time tracking, messages which email to team members, notebooks for ideas and passwords, files, links, timelines and gantt charts, estimated time per task, calendar, and invoices. You get 5 standard users on the free tier but can have as many collaborators as you need. Teamwork can be viewed in task lists or board view. Asana While you don’t have all the features available on the free version of Asana, you aren’t limited to the number of projects you can have. You can also keep up with project status, files, and conversations. You are also not limited to your team members as long as the project is public. Asana can be viewed in task lists or board view. Trello If you’re a fan of the Kanban board, Trello might be for you. It is free to use, and you can link it to Slack if your team uses that for communication. It can only be used in board view. Be aware that boards can be searchable on Google so unless that is your intention, make sure to lock it down. Podio This one was pointed out to me and seems to be a very flexible management tool. It allows you to build lists and customize views. You can choose which lists your team members see which could be handy if you have an art team, programming team, etc. Other free project management tools: https://blog.hubspot.com/marketing/free-project-management-software Plan/Game Design Document Hopefully by this point, you know what your game is going to be about. It’s a good idea to tell your programmer (either in conversation or through a game design document) the entire plan. Knowing everything up front will help them build with the big picture in mind. If you add a feature down the road when something was hard-coded to save time, they may have to rebuild part of a feature for the new additions. I can’t advocate a game design document enough when planning a game. In Part 1, I linked a game design document resource, but the document could take on any format. As long as it paints a picture of what features that game will have, you’re doing something right. It’s okay if it doesn’t include everything because games are living entities that change drastically over time based on new ideas and player feedback. Phases/Milestones If you have a plan, it’s a lot easier to break that plan down into more manageable pieces. As an African proverb says, “The best way to eat the elephant standing in your path is to cut it up into little pieces.” In other words, you have to set manageable goals for your project. Instead of saying to yourself, “I’m going to build a pet site like Neopets,” you can instead say, “I’m working on the first phase of my project which only includes basic player information.” Instead of tackling Mt. Everest immediately, you know that you first have to pass the trailhead. You know your progress by passing milestones. So you have this big idea but maybe you aren’t sure how to break it up. First of all, make sure your goals and phases are SMART. S - Specific M - Measurable A - Achievable R - Realistic T - Timely This applies to game planning. If you’re here to do it as a hobby when you can for 1 hour per week or per month, this may not apply to you. But if you’re wanting to make progress and release a game to the public by X month in X year, you’ll definitely want to do a bit of forward thinking. If your plan lacks one of the elements above, add it. This will help you and your team by defining expectations for each phase of the project. Real Example Continuing with the kangaroo game from Part 1, Roo Boss, let’s define some phases. Phase Goal Phase 1: Players Players should be able to register, login, and view/edit their profile. They should also be able to manage their money through a bank. Phase 2: Kangaroos (Basics) Players should be able to purchase kangaroos from an NPC, view basic stats and health information, and edit their name and description. Phase 3: Items Players should be able to purchase items from a shop. Items can be of type food (increases kangaroo health), health (repairs damages), or toy (increases kangaroo happiness). Players should be able to give these items to a kangaroo. Phase 4: Images and colors Players should be able to see their unique kangaroo based on color traits. Phase 5: Breeding Players can breed together 2 kangaroos to produce a joey that has color traits from the parents I could keep going with more phases, but I think you get the idea. I prefer to write the goal as something the player will see which also starts to define how you will eventually test and mark this goal as complete. Are you starting to feel better about tackling your massive project? Pet sites are very time intensive and can very easily cause overwhelm, especially if you start thinking in terms of how many hours are put in which can directly translate to costs. How do you plan programming? Now that you have phases, you can figure out programming for each phase individually. Starting with Phase 1, you already know a few things are needed to accomplish the end goal. Here is a list of to-do items or tasks that you could potentially give a programmer. You will need a domain so that you can test. You’ll need to “point” this domain to where your code is hosted. (Recommended: Namecheap) You’ll need hosting for all the code to go on. (Recommended: Digital Ocean or Vultr) Determine if your game will be built in a framework. There is a great breakdown of framework options and why these are a better choice over code from scratch in the So You Want to Be a Site Owner… article. Set up the framework if applicable. Determine the database schema. This is something your programmer will do, but you need to know that this takes time. Determine what the game will look like while it’s in development. I highly recommend a basic bootstrap template (already pre-packaged with Laravel) until there is more to the game. If login and registration comes with the framework, determine if those need to be customized for your game. An example of this is adding a starting money amount to the pre-packaged Laravel registration setup. Build the profile. This will display the avatar, player name, join date, bio, and if they are online. Create a settings page. This will allow the player to edit their name, avatar (only as a URL, not an uploaded file), bio, email, and password. Create a bank page that allows the player to deposit and withdraw money. Note a couple things in this list. Although the goal of “Players should be able to register, login, and view/edit their profile. They should also be able to manage their money through a bank.” seems simple, it requires you to step back a few steps to determine what is required to reach that goal. Since we don’t have anything yet, we have to start from the very first step of setting up a site. Know what your game is built on. The most popular choice right now seems to be PHP and Laravel but there are a ton of options that you could choose. If it is Laravel, read some of the documentation. There is plenty, and you can get a big picture on what has an “easy button” with Laravel. And if it isn’t, find the documentation because there will always be some on a framework. Know the details of each task and provide as many as possible. You can’t say “Build a profile page” and expect someone to read your mind and know which fields to put on it. Define all of the information that should be on every page. Know the logic behind each task. If there is any sort of special algorithm associated with making the game work, know what it is. If you don’t know what it is, ask the programmer to provide documentation. Down the road when a player asks how something is built or calculated, your answer should not be “I don’t know.” Don’t try to build the whole game in a single phase. It’s okay to not do everything associated with a feature. The goal of each phase is to get a version of something that can be tested then marked off as complete. Additions can come with future feature versions. I specified whether a field was a simple URL link which would be stored in the database or uploading a file. Uploading a file means you are managing files on your server which could mean a significant time difference in this quote. You should also know if the programmer decides to outsource files to a storage site such as Amazon or store the files locally on the server. If files are attached to players and stored locally, know that you could potentially have to manage server space and continually upgrade as your game grows. What’s Next? Now that you have a task list for your phase, you can send it to a programmer. Even if you provide as many details as you can, expect there to be some questions. If there aren't any questions, you should question them on why they are not questioning you. The programmer will most likely add or rearrange the task list so that it makes sense to them. This is okay. Sometimes, there are more technical details than what you can possibly account for without knowing how to program. Be aware of any changes and make sure it makes sense to you why things were changed. Ask the programmer to add hours to each task. This is a common practice in the programming world so they should be able to comply with this. If the programmer charges hourly or by task, adding hours will help you associate time and effort, and therefore cost, with each task. It will also define a scope for the phase and allow for there to be some sort of timeline. Without an idea of the effort involved from both sides, estimating timelines would be difficult. Scope Creep Any project is susceptible to scope creep. Scope creep happens when more things are added after a project is started. This could be due to a few reasons and is sometimes unavoidable. You realize you didn’t define all the requirements for the phase. At this point, it would be better to add it to a future phase instead of adding it to this phase. Unexpected complications came up. This could be due to anything from testing taking longer than planned to packages or dependencies not working like originally thought. This happens to even the most senior programmers so be understanding if this is the case. Communication is key in understanding why something could be taking longer than the original quote. The programmer realizes they didn’t account for everything necessary to fulfill a task. This is slightly different from 2 in that it is avoidable with enough planning. However, this also happens because it’s impossible to predict everything. Beginner programmers are more likely to have issues with this. What do you do when a phase is complete? TEST. And test some more. Make sure the phase checks all of your boxes and what is in the original task list. It is YOUR job to make sure that everything is accurate from the player’s point of view. After you test, start planning the next phase. Make sure to talk about it with your programmer so that you can answer any questions and revise the scope and task list if needed before attributing any hours to it. Try not to make task lists too big. A good rule of thumb is to make each one between 5 and 20 hours. If it gets to be more than 20 hours, that’s getting to be more of a mini project all on its own and could become overwhelming and harder to manage. Conclusion Hopefully this helps aspiring game owners who do not know where to get started in the actual build part of their plan. Keep in mind that this is from my perspective and others can have different processes. I’ve written this based on 6 years of experience of working with clients to build scopes for projects anywhere from 5 hours to 1,000+ hours, and 11 years of building games either with a programmer or programming them myself. If you have any questions, we have a great group of programmers in the community who are happy to help if you are unsure about technical details. If you found this guide useful, feel free to suggest other guides like this. I can try my best to write them or find someone who has more expertise on the subject matter. Other Helpful Guides If you're looking for more information, here are some past TGL guides that go with this topic: Feature Development, Scope & Destruction How to Get Started Considerations of Designing for Scale Version Control with Git How to: Keep your project organized using Trello 5 Quote Link to comment Share on other sites More sharing options...
SilverBrick Posted March 9, 2020 Share Posted March 9, 2020 Thank you so much it was really helpful for me and i enjoyed reading it. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.