Finish your project with Spiral + AGILE Hello. I'm learning gamedev, and teaching is part of learning. I hope sharing my notes on process helps a little. Do you never actually finish projects? Software methodologies draw a road map to release something. Videogames are complex and potentially neverending projects without limitations and a thoughtful approach. Exploratory programming can be enlightening, but a lack of limitations leads to nothing anyone will ever use. Moving forward with a clear process reduces the risk of the feature creep, too much complexity, and scope issues that leads to delays and project abandonment. There are a number of software methodologies that help manage software projects in particular. I’m using a spiral methodology with AGILE. Spiral Spiral methodology’s name is self-explanatory – You work through iterative cycles of planning, risk management, developing, refactoring, and testing. You will naturally discover flaws in your original design or be inspired to add new features throughout the project, so you can always go back to the planning phase to properly consider them. If you are trying to force a solution through code, you can return to planning. You test early and often, gaining insight from yourself and playtesters on shortcomings and successes of your design and execution. You refactor periodically to reduce complexity and review your code critically, which paves the way for smoother development in the future. You also are encouraged to keep moving – you can’t over-analyze, overdo, over-optimize any particular step of the process. AGILE AGILE is used by big important tech companies like IBM. It’s cyclical with consistent time-frames (called “sprints”) of planning, working, and evaluating. It’s different from spiral, though, as AGILE is more of a philosophy. At the end of a sprint, every team member is encouraged to review every part of the process as a group. Everyone stands up. Everyone talks candidly for a few minutes. Consider the value of your design, your tools, the length of the sprints, the nature of the review itself, everything. If any part of the process is flawed, catch it and change it early. Be flexible in your pursuit of the best process for the team. MVP Together, using a spiral methodology with AGILE, you should shoot for a minimum viable product (MVP). This could be a vertical slide, a horizontal slice, a demo, or something functional like that. Approach your project how Bob Ross approaches a painting. He doesn’t spend a season on a little tree in the corner; he works the whole canvas and builds on his happy accidents. Find the joy of programming. Your game should be playable as soon as possible – maybe ugly and dumb and pointless but playable. At any step, no matter how far you are from finishing, have something that works as a finished project. To do that, you need to decide what the most essential and defining features of your game are and work on them first. Move on to less essential features as time goes on until your game’s done. Or until you’re done working on it. Either way, you’ll have a playable game to offer people. Prototype If you're not even sure if your game is fun or possible, it's better to quickly test with a prototype. You can find a way to abstract your problem or distill it into something smaller to build or present to potential players. Use cut paper, quick sketches, action figures, free tilesets, whatever can represent your game cheaply and quickly. Maybe you can build a board or card game on paper that demonstrates your mechanic. Maybe you can make a room in your engine and spawn in too many items to test performance. Maybe you can share some key concept art or mockups with potential players and gauge responses. If you don't like your results, it's way easier to edit 20 minutes of construction paper than six months of production code. When is my concept ready? Your concept is all of your interesting ideas for your game. If it sounds like a fun game with concrete features, you’re ready. I keep my ideas in a personal wiki so I can see the inter-connectivity of my concepts. I also jot notes into a notes app on my phone. Writing it down is always better than keeping it floating in your head. Make your concept actionable Next, reword your concept into a series of unambiguous items that can be demonstrated clearly through your code. These are functional requirements. There are nonfunctional requirements, too, including the target framerate on specific hardware or the paradigm necessary to make modding more accessible. Just start writing them out in bullet points. You don’t need to know all your function requirements yet, and you will have to rework parts of your project later anyways. If you use an iterative methodology, you’ll return to evaluating and planning phases plenty of times before release. Pick a theme Build your first functional requirements around a theme that is central to your game. I think AGILE calls it a story. For an RPG, it could be combat, maybe characters… Give each requirement a code to make them easily track-able. Code your list I start with character. Down the list, I name them AA, AB, AC, AD… Functional Requirements - Character • AA - A character has a name. Demonstrate that a character has a name by making a character and printing its name. • AB - In a game, there can be multiple characters. Demonstrate that you can add a character and remove a character by printing the names of the existing characters. • AC - A character can have abilities. The abilities belong to the character. Demonstrate by having multiple characters and printing their names and abilities. • AD - There is a pool of abilities the character knows. There are abilities that they have equipped. Demonstrate by printing the abilities they know and the abilities they have equipped with their name. • AE - Abilities can be added or removed from a character. Demonstrate by printing the list of abilities you know and the list of abilities you're using. Then add a new ability from the list you know to the list you are using and print the list of abilities you're using. • AF - A character may not know all the possible abilities. Demonstrate by listing all of the abilities in the game. Then list all the abilities the character knows. • AG - The character can't use abilities he doesn't know. Demonstrate by trying to add an ability from the list of all abilities in the game that the character doesn't know to the list of abilities the character is using. Print that you cannot do that. • AH - The character can't have the same ability equipped more than once. Demonstrate by trying to add an ability the character already has equipped. Remove original from the slot it is in and add new ability to that slot. Print abilities character is using. • AI - Skills go in slots and slots can be empty. Demonstrate by having no abilities in the character's slots and printing the list of skills the character is using. Put abilities in the slots and print what abilities is in each slot. Remove abilities from the slots and print what abilities is in each slot. • AJ - When putting a skill in a slot that already has a skill, the skill is replaced. Demonstrate by having a skill in a slot then putting a new skill in that slot. Print the skill that is in that slot. • AK - An item has a name. Demonstrate by printing an item's name. • AL - There are items that can be put in a character's inventory. Demonstrate by adding an item to the character's inventory then printing what is in the inventory. •AM - Characters have equipment slots. Demonstrate by adding an item to the equipment slots then printing what is in the equipment slots. Rate by difficulty Next, assign a difficulty level to each item. Do not focus on what you know; focus on what you do not know. The goal is to express your unknowns about the task. If you need to remember how to meet a requirement, if you don’t know how to do a requirement, if you need to learn new tools in order to meet a requirement, you’ll face varying levels of unknowns. Unknowns increase risk, so they increase your difficulty rating. I use Fibonacci numbers (1, 2, 3, 5, 8, 13,...) to represent difficulty levels. 1 is no problem at all, 3 is easy but with vague uncertainty, 13 has uncertainties upon uncertainties and should be broken into less risky tasks, etc. There are two methods to rating difficulty. Assign your lowest difficult value to the easiest item on the list. (That’s what I do.) Or, find an item with an average difficulty relative to your list and assign it a middle number. If you are working on a team, you need to vote on each rating. The rating should represent the difficulty of the items for your team because you have not assigned individual work yet. Next, rate the other items relative to the it. If anything is rated conspicuously high, see if it can be broken into smaller, more manageable items. This is an entirely subjective estimate. Don’t worry too much about the exact difficulty you assign – just approximate it. You’ll give more accurate and meaningful ratings with practice. Choose length of sprints Choose a time-frame with enough time to get practical work done that is still granular. Don’t worry too much about the perfect length of time – you can always change the length of sprints at the next evaluation phase. I choose a week. Choose this sprint’s functional requirements Using the difficulty ratings, determine what is a week’s worth of work. Obviously, you can only pick items with prerequisites if you are also doing the prerequisites during the same sprint. Use the ratings to avoid being overwhelmed. You’ll get better using your ratings with practice. For a real company, you take this list and do it and no more for the duration of the sprint. You have other team members, other teams, clients, and all kinds of people who rely on the schedule. Disrupting that hurts the process of other people. If it’s just you or your team is small, you have more freedom to adjust your schedule if you severely misjudge the difficulty of your work. I finished the “week’s” worth of work in a few hours and was able to just add more requirements since it’s just me. My initial first week’s requirements... • (1) – AA - A character has a name. Demonstrate that a character has a name by making a character and printing its name. • (3) – AB - In a game, there can be multiple characters. Demonstrate that you can add a character and remove a character by printing the names of the existing characters. • (5) – AC - A character can have abilities. The abilities belong to the character. Demonstrate by having multiple characters and printing their names and abilities. • (5) – AD - There is a pool of abilities the character knows. There are abilities that they have equipped. Demonstrate by printing the abilities they know and the abilities they have equipped with their name. • (8) – AE - Abilities can be added or removed from a character. Demonstrate by printing the list of abilities you know and the list of abilities you're using. Then add a new ability from the list you know to the list you are using and print the list of abilities you're using. Next, write code that meets the requirements. Here’s some output that demonstrates meeting the requirements: Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> ========== RESTART: C:\Users\Toma\Pythons\Dungeon_Girls\src\game.py ========== AA: A character has a name: Chloe AB: There can be multiple characters. AB: Characters: [Chloe, Willa] AB: You can add a character. AB: Characters: [Chloe, Willa, Destry, Eden] AB: You can remove a character. AB: Characters: [Chloe, Willa, Destry] AC: Characters can know skills. Chloe: [Cure, Summon Archangel, Candlelight] & Willa: [Fireball, Demonspeak] AD: Characters can know skills and have skills equipped. AD:Chloe's library: [Cure, Summon Archangel, Candlelight] & skillbar: [None, Summon Archangel, Cure, Candlelight, None] AE: Skills can be added to a character. AE: Chloe: [Identify, Summon Archangel, Cure, Candlelight, None] AE: Skills can be removed from a character. AE: Chloe: [Identify, Summon Archangel, Cure, None, None] >>> Then you'll be able to evaluate your code and process, plan your next steps, maybe prototype something, maybe develop something, maybe refactor something, test, and continue the spiral. If you follow a methodology, I think your chances of finishing at least something is pretty good. Thanks for reading. Follow for more game development on Twitter @lilchimchooree. https://ift.tt/eA8V8J

Hello. I'm learning gamedev, and teaching is part of learning. I hope sharing my notes on process helps a little. Do you never actually finish projects? Software methodologies draw a road map to release something. Videogames are complex and potentially neverending projects without limitations and a thoughtful approach. Exploratory programming can be enlightening, but a lack of limitations leads to nothing anyone will ever use. Moving forward with a clear process reduces the risk of the feature creep, too much complexity, and scope issues that leads to delays and project abandonment. There are a number of software methodologies that help manage software projects in particular. I’m using a spiral methodology with AGILE. Spiral Spiral methodology’s name is self-explanatory – You work through iterative cycles of planning, risk management, developing, refactoring, and testing. You will naturally discover flaws in your original design or be inspired to add new features throughout the project, so you can always go back to the planning phase to properly consider them. If you are trying to force a solution through code, you can return to planning. You test early and often, gaining insight from yourself and playtesters on shortcomings and successes of your design and execution. You refactor periodically to reduce complexity and review your code critically, which paves the way for smoother development in the future. You also are encouraged to keep moving – you can’t over-analyze, overdo, over-optimize any particular step of the process. AGILE AGILE is used by big important tech companies like IBM. It’s cyclical with consistent time-frames (called “sprints”) of planning, working, and evaluating. It’s different from spiral, though, as AGILE is more of a philosophy. At the end of a sprint, every team member is encouraged to review every part of the process as a group. Everyone stands up. Everyone talks candidly for a few minutes. Consider the value of your design, your tools, the length of the sprints, the nature of the review itself, everything. If any part of the process is flawed, catch it and change it early. Be flexible in your pursuit of the best process for the team. MVP Together, using a spiral methodology with AGILE, you should shoot for a minimum viable product (MVP). This could be a vertical slide, a horizontal slice, a demo, or something functional like that. Approach your project how Bob Ross approaches a painting. He doesn’t spend a season on a little tree in the corner; he works the whole canvas and builds on his happy accidents. Find the joy of programming. Your game should be playable as soon as possible – maybe ugly and dumb and pointless but playable. At any step, no matter how far you are from finishing, have something that works as a finished project. To do that, you need to decide what the most essential and defining features of your game are and work on them first. Move on to less essential features as time goes on until your game’s done. Or until you’re done working on it. Either way, you’ll have a playable game to offer people. Prototype If you're not even sure if your game is fun or possible, it's better to quickly test with a prototype. You can find a way to abstract your problem or distill it into something smaller to build or present to potential players. Use cut paper, quick sketches, action figures, free tilesets, whatever can represent your game cheaply and quickly. Maybe you can build a board or card game on paper that demonstrates your mechanic. Maybe you can make a room in your engine and spawn in too many items to test performance. Maybe you can share some key concept art or mockups with potential players and gauge responses. If you don't like your results, it's way easier to edit 20 minutes of construction paper than six months of production code. When is my concept ready? Your concept is all of your interesting ideas for your game. If it sounds like a fun game with concrete features, you’re ready. I keep my ideas in a personal wiki so I can see the inter-connectivity of my concepts. I also jot notes into a notes app on my phone. Writing it down is always better than keeping it floating in your head. Make your concept actionable Next, reword your concept into a series of unambiguous items that can be demonstrated clearly through your code. These are functional requirements. There are nonfunctional requirements, too, including the target framerate on specific hardware or the paradigm necessary to make modding more accessible. Just start writing them out in bullet points. You don’t need to know all your function requirements yet, and you will have to rework parts of your project later anyways. If you use an iterative methodology, you’ll return to evaluating and planning phases plenty of times before release. Pick a theme Build your first functional requirements around a theme that is central to your game. I think AGILE calls it a story. For an RPG, it could be combat, maybe characters… Give each requirement a code to make them easily track-able. Code your list I start with character. Down the list, I name them AA, AB, AC, AD… Functional Requirements - Character • AA - A character has a name. Demonstrate that a character has a name by making a character and printing its name. • AB - In a game, there can be multiple characters. Demonstrate that you can add a character and remove a character by printing the names of the existing characters. • AC - A character can have abilities. The abilities belong to the character. Demonstrate by having multiple characters and printing their names and abilities. • AD - There is a pool of abilities the character knows. There are abilities that they have equipped. Demonstrate by printing the abilities they know and the abilities they have equipped with their name. • AE - Abilities can be added or removed from a character. Demonstrate by printing the list of abilities you know and the list of abilities you're using. Then add a new ability from the list you know to the list you are using and print the list of abilities you're using. • AF - A character may not know all the possible abilities. Demonstrate by listing all of the abilities in the game. Then list all the abilities the character knows. • AG - The character can't use abilities he doesn't know. Demonstrate by trying to add an ability from the list of all abilities in the game that the character doesn't know to the list of abilities the character is using. Print that you cannot do that. • AH - The character can't have the same ability equipped more than once. Demonstrate by trying to add an ability the character already has equipped. Remove original from the slot it is in and add new ability to that slot. Print abilities character is using. • AI - Skills go in slots and slots can be empty. Demonstrate by having no abilities in the character's slots and printing the list of skills the character is using. Put abilities in the slots and print what abilities is in each slot. Remove abilities from the slots and print what abilities is in each slot. • AJ - When putting a skill in a slot that already has a skill, the skill is replaced. Demonstrate by having a skill in a slot then putting a new skill in that slot. Print the skill that is in that slot. • AK - An item has a name. Demonstrate by printing an item's name. • AL - There are items that can be put in a character's inventory. Demonstrate by adding an item to the character's inventory then printing what is in the inventory. •AM - Characters have equipment slots. Demonstrate by adding an item to the equipment slots then printing what is in the equipment slots. Rate by difficulty Next, assign a difficulty level to each item. Do not focus on what you know; focus on what you do not know. The goal is to express your unknowns about the task. If you need to remember how to meet a requirement, if you don’t know how to do a requirement, if you need to learn new tools in order to meet a requirement, you’ll face varying levels of unknowns. Unknowns increase risk, so they increase your difficulty rating. I use Fibonacci numbers (1, 2, 3, 5, 8, 13,...) to represent difficulty levels. 1 is no problem at all, 3 is easy but with vague uncertainty, 13 has uncertainties upon uncertainties and should be broken into less risky tasks, etc. There are two methods to rating difficulty. Assign your lowest difficult value to the easiest item on the list. (That’s what I do.) Or, find an item with an average difficulty relative to your list and assign it a middle number. If you are working on a team, you need to vote on each rating. The rating should represent the difficulty of the items for your team because you have not assigned individual work yet. Next, rate the other items relative to the it. If anything is rated conspicuously high, see if it can be broken into smaller, more manageable items. This is an entirely subjective estimate. Don’t worry too much about the exact difficulty you assign – just approximate it. You’ll give more accurate and meaningful ratings with practice. Choose length of sprints Choose a time-frame with enough time to get practical work done that is still granular. Don’t worry too much about the perfect length of time – you can always change the length of sprints at the next evaluation phase. I choose a week. Choose this sprint’s functional requirements Using the difficulty ratings, determine what is a week’s worth of work. Obviously, you can only pick items with prerequisites if you are also doing the prerequisites during the same sprint. Use the ratings to avoid being overwhelmed. You’ll get better using your ratings with practice. For a real company, you take this list and do it and no more for the duration of the sprint. You have other team members, other teams, clients, and all kinds of people who rely on the schedule. Disrupting that hurts the process of other people. If it’s just you or your team is small, you have more freedom to adjust your schedule if you severely misjudge the difficulty of your work. I finished the “week’s” worth of work in a few hours and was able to just add more requirements since it’s just me. My initial first week’s requirements... • (1) – AA - A character has a name. Demonstrate that a character has a name by making a character and printing its name. • (3) – AB - In a game, there can be multiple characters. Demonstrate that you can add a character and remove a character by printing the names of the existing characters. • (5) – AC - A character can have abilities. The abilities belong to the character. Demonstrate by having multiple characters and printing their names and abilities. • (5) – AD - There is a pool of abilities the character knows. There are abilities that they have equipped. Demonstrate by printing the abilities they know and the abilities they have equipped with their name. • (8) – AE - Abilities can be added or removed from a character. Demonstrate by printing the list of abilities you know and the list of abilities you're using. Then add a new ability from the list you know to the list you are using and print the list of abilities you're using. Next, write code that meets the requirements. Here’s some output that demonstrates meeting the requirements: Python 3.6.5 (v3.6.5:f59c0932b4, Mar 28 2018, 17:00:18) [MSC v.1900 64 bit (AMD64)] on win32 Type "copyright", "credits" or "license()" for more information. >>> ========== RESTART: C:\Users\Toma\Pythons\Dungeon_Girls\src\game.py ========== AA: A character has a name: Chloe AB: There can be multiple characters. AB: Characters: [Chloe, Willa] AB: You can add a character. AB: Characters: [Chloe, Willa, Destry, Eden] AB: You can remove a character. AB: Characters: [Chloe, Willa, Destry] AC: Characters can know skills. Chloe: [Cure, Summon Archangel, Candlelight] & Willa: [Fireball, Demonspeak] AD: Characters can know skills and have skills equipped. AD:Chloe's library: [Cure, Summon Archangel, Candlelight] & skillbar: [None, Summon Archangel, Cure, Candlelight, None] AE: Skills can be added to a character. AE: Chloe: [Identify, Summon Archangel, Cure, Candlelight, None] AE: Skills can be removed from a character. AE: Chloe: [Identify, Summon Archangel, Cure, None, None] >>> Then you'll be able to evaluate your code and process, plan your next steps, maybe prototype something, maybe develop something, maybe refactor something, test, and continue the spiral. If you follow a methodology, I think your chances of finishing at least something is pretty good. Thanks for reading. Follow for more game development on Twitter @lilchimchooree.

from GameDev.net http://bit.ly/2ZDKkXr