{"author_link":"\/users\/djfariel","author_name":"djfariel","author_uid":"djfariel","comments":[],"epoch":1556654977,"event":"LD44","format":"md","ldjam_node_id":155228,"likes":6,"metadata":{"p_key":"131521","p_author":"djfariel","p_authorkey":"1001375","p_urlkey":"347715","p_title":"Why You Need A Manager - A Ludum Dare Postmortem","p_cat":"LDJam ","p_event":"LD44","p_time":"1556654977","p_likes":"6","p_comments":"0","p_status":"WAYBACK","us_key":"1001375","us_name":"djfariel","us_username":"djfariel","event_start":"1556236800","event_key":"75","event_name":"LD 44"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD44","removed_author":false},"_superparent":139254,"_trust":4,"author":1375,"body":"This is a write up detailing my personal experiments, trials, and tribulations of Ludum Dare 44. For the uninitiated, Ludum Dare (to give a game) is a 48 or 72 hour game jam where participants are given a theme and then tasked with building a game from start to finish in the allotted time frame. The compo portion is 48 hours, no teams, and published source code. The Jam portion is 72 hours, teams, and source code is not a requirement.\n\n## The Goals\n\nI set some interesting goals this time around.  First and foremost, I wanted to see how well our team would do with noone leading the charge.  I didn\u2019t take notes, write tasks, document plans or features, or set goals.  Second, I wanted to work in 3d, as we haven\u2019t published anything in 3d yet. Very straightforward.\n\n![CoinusAccumulus-LDTitle.png](\/\/\/raw\/f55\/z\/23e9a.png)\nhttps:\/\/ldjam.com\/events\/ludum-dare\/44\/coinus-accumulus\n \n\n## Brainstorming\n \nThe theme this time around was \u201cYour life is currency.\u201d  The inclusion of the word \u201cyour\u201d in the theme was a huge sticking point for a lot of people, including us.  Our brainstorming session, or as we like to call it in-house: mindphooning, went fairly quickly, lasting only about 2 hours. Ludum Dare has a theme selection process that involves three rounds of theme voting, and then a final round for the winners from the last three. Our process is to take the list and jot down some quick and dirty first impressions before the event starts. This gives us a base to work with, where we can immediately start talking about mechanics. \n\n![brainstorm.PNG](\/\/\/raw\/f55\/z\/23e9f.png)\n\nOnce the theme was released, we reviewed the list and saw that we had\u2026 Well, we had basically nothing. The best idea from the list was \u201cpitfall but your bodies persist\u201d and the next idea was \u201chealth insurance simulator.\u201d We ended up scrapping the entire list and ran with something on a whim. The conversation was something along the lines of:\n\u201cSo you\u2019ll play as a coin.\u201d\n\u201cAnd do what, pick up currency?\u201d\n\u201cKatamari style?\u201d\n\u201cOk let\u2019s just go with this.\u201d\n\n## The First Night\n\nWe did a small bout of pre-planning. DJ mentioned he would jump on enemies. Dan started modeling out a coin or two, then to valuables. I started with the character controller.  We had decided that the quickest way to do the art pipeline was with vertex colors on simple meshes.\n\nBy midnight we had a working prototype. You were a coin. The coin rolled around and picked things up. As you picked things up, you grew larger and could pick up more things.  Everything with a mesh calculated its volume and requirements thus could be picked up. We had a game and all we had to do was add more stuff.  \n\nAfter these basics I worked on getting the movement to feel right. This was actually some pretty intense tomfoolery. The player, a simple coin, is actually five objects: \n- The player itself, which housed the controller and rigidbody. \n- The Z pivot, which was used for tilting the coin left and right as you turned to give you a proper sense of movement.\n- The X pivot, which was used to rotate the coin as you moved to give you a sense of forward or backwards momentum.\n- The collider.\n- The ground check trigger. \n\nI started with a full physics implementation of the coin. Anyone who has written a character controller in Unity knows that physics is your enemy. Real world gravity and friction just don\u2019t feel good to play in. Starting with the physics implementation told me what I needed to do, which I then pulled out of real physics and tried to make it feel good.  The player itself doesn\u2019t actually spin as it\u2019s moving forward, but the X pivot (which has the mesh renderer) does. The player doesn\u2019t actually tilt when turning, but the Z pivot does. The player object itself only moves forward, backward, turns, and jumps.  \n\nIn retrospect, the collider and trigger should have been moved up to the root level so that they weren\u2019t affected by the non-physics actions like tilting and rotating. This would have helped with FPS for the physics simulation, though the impact was negligible for this particular project. \n\n\n\n## The Rabbit Hole\n\nAfter I had a working character, Dan handed me the first round of models. Two coins and a few jewels. I dropped the coin in for the player and realized that Unity doesn\u2019t have a built in shader for vertex colors. This threw a wrench in the whole \u201cspeedy art pipeline\u201d idea. So I started writing a shader. Getting this basic vertex color shader up and running only took a couple hours at best. One major weakness in my skill set is writing shaders.  But I did it. I had a working vertex color shader, and I was proud. I called Dan over to have him take a look and he said \u201cThe coin isn\u2019t shiny.\u201d  Oh.\n\n![coinamari1.gif](\/\/\/raw\/f55\/z\/23ea8.gif)\n\nThus began my descent into madness, which lead into the next morning. It took me an embarrassing amount of time to get shininess to work on the shader.  After it was all said and done, I had spent about eight hours working to get the coin shiny.  This wouldn\u2019t be my first foray into wasting time, either.  Immediately after this, I spent another six hours or so trying to get diffuse lighting working on this shader. As a little aside - we didn\u2019t end up with specular or diffuse in the final game. This was over half a day wasted.  Giving up on lighting, I decided to press forward on the gameplay. \n\nDan had a whole slew of items ready to go, including a whole dungeon kits with tiles and walls. I mapped out a basic level and we liked where it was going overall.  Unbeknownst to us, there was a major problem brewing that we wouldn\u2019t address until the next day. \n\n## A Bit About Katamari\n\nIn any Katamari game, you play as a sticky ball. The object of the game is to roll up as much stuff and reach a set goal size for the level, usually accompanied by a timer for pressure. As you collect items, you increase in size, which allows you to pick up larger items. The cycle repeats.  Everyone once in awhile you reach a \u201cbreakpoint\u201d where your katamari levels up, accompanied with a zoom-out of the camera and a pop-up telling you that you can enter a new area. Why does this happen?\n\nAs it turns out, this is used to get the game back to sane values, load in larger areas, and generally do maintenance on the game state so things stay in control and reasonable. Well, as reasonable as a Katamari game can be. \n\n![661588_katamari-damacy-computer-wallpapers-desktop-backgrounds_1280x1024_h.jpg](\/\/\/raw\/f55\/z\/23eab.jpg)\n\n## A Wasted Day\n\nDuring the level design process I kept running into one issue over and over again. The player got out of control. There were a number of contributing factors to this: movement speed, camera position, number size limits on objects with large volumes, player scale. The one thing I couldn\u2019t answer was how to reel the player in. I spent the better part of the second day tweaking numbers, adding multipliers to change value scales, and generally failing.  I was focusing on the details and not the game.  \n\nA small part of me wanted to give up on the idea, call the whole project a wash and change the game idea.  I stepped back and laid on the couch, taking the opportunity to watch some gameplay from various Katamari games to see what secret sauce I was missing.  That\u2019s when it dawned on me - our player never leveled up. \n\nFrom an architectural perspective, this level up system is pretty advanced. It involves loading in new, large objects and unload old, small objects. It also involves resetting camera values, player scale and volume settings, and any other maintenance that needs done.  Unity has some support for this built in with additive scene loading and unloading, but this is at best a partial solution for the whole problem. We were reaching the end of the second day. \n\nSunday night. Very little had changed the entire day, and I didn\u2019t think I\u2019d have time to change the architecture of the project at this point. So I asked what the team thought. Should we go for pure katamari and focus on the systems, scrapping all of the AI work DJ had done and shifting all focus on getting loading working, or should we scrap most of the katamari system?  We decided the best route for the success of the game was to do the latter, and thus it became a 3D platformer. \n\n## Super Secret Shader Stint\n\nOur game looked terrible.  During the previous day, one of the largest complaints was \u201cI can\u2019t see through this stupid bookshelf.\u201d I had extended the shader a bit to discard geometry that was close to the camera, but after I wrote it I realized I could just increase the near clipping plane in Unity to get the exact same effect.  I knew I could do better, so I got up in the middle of the night. With my newly grown shader muscles, I set out to add dithering to the cut. This worked marvelously and made me think of the latest Mario and Zelda games, which made me want to try my hand at the lighting again.  This time around I discovered how to write custom lighting, so I wrote up a bit of toon lighting. Then I went back to bed. \n\n![dither.gif](\/\/\/raw\/f55\/z\/23eae.gif)\n\n## The Final Push\n\nWith a fresh vision we hit the ground running, trying to glue as much of this together as possible. We really rode this one out to the max. Thanks to Unity\u2019s timeline feature, we were able to put together an opening cutscene in about 30 minutes. DJ\u2019s enemy system wasn\u2019t implemented in the main level until about 3 hours before the deadline, where we had to pause with level design so that he could implement it. We then rode level design out right up until submission hour.  The game wasn\u2019t even able to be won until about an hour before the deadline. \n\n## Why Are You Telling Me Your Life Story\n\nThis was all leading up to the big takeaway from this Ludum Dare: You need a manager.  Whether that person is yourself or someone dedicated to the role, it is vital to the success of a project. \n\nThere were many moments where I found myself flying blind, problems in front of me but no guidance or priorities. There were moments where Dan didn\u2019t know what to work on next because he didn\u2019t know what was important or what would make the cut. There were moments where DJ wanted his work to get implemented but we weren\u2019t ready to add it because the scene was checked out willy nilly. \n\nA manager\u2019s role is to give you the tools you need to be effective at your role. They\u2019re to provide you with direction when you\u2019re lost. A manager should identify potential issues and work to find a solution before the problem presents itself. We didn\u2019t have any of these things. \n\nIt\u2019s easy to get lost in a sea of \u201cwhat if\u201d scenarios, but I can confidently look back and say that we would have had almost a full extra day of development had I taken any time at all to lead the team. \n\n## So How Was The Game\n\nOverall, I think we succeeded. We\u2019re all very competent in our own areas and, at the end of the day, we were able to pull it together to make something that was largely enjoyable. While looking over the comments we\u2019ve received so far, a few points stand out that very clearly illustrate our running out of time, not having priorities, and not thoroughly testing. Had I stepped back to assess the situation, those would have been improved. \n\nOn future projects I intend to make sure someone is holding the reigns at all times, even if that someone isn\u2019t me. \n\n![post.gif](\/\/\/raw\/f55\/z\/23eb8.gif)\n\n","comments":3,"comments-timestamp":"2019-04-30T21:00:35Z","created":"2019-04-30T19:53:30Z","files":[],"files-timestamp":0,"id":155228,"love":6,"love-timestamp":"2019-05-03T02:35:08Z","meta":[],"modified":"2019-05-03T02:35:08Z","name":"Why You Need A Manager - A Ludum Dare Postmortem","node-timestamp":"2019-04-30T20:23:31Z","parent":141529,"parents":[1,5,9,139254,141529],"path":"\/events\/ludum-dare\/44\/coinus-accumulus\/why-you-need-a-manager-a-ludum-dare-postmortem","published":"2019-04-30T20:09:37Z","scope":"public","slug":"why-you-need-a-manager-a-ludum-dare-postmortem","subsubtype":"","subtype":"","type":"post","version":465415},"node_metadata":{"n_key":"155228","n_urlkey":"347715","n_parent":"141529","n_path":"\/events\/ludum-dare\/44\/coinus-accumulus\/why-you-need-a-manager-a-ludum-dare-postmortem","n_slug":"why-you-need-a-manager-a-ludum-d","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"1375","n_created":"1556654010","n_modified":"1556850908","n_version":"465415","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/44\/coinus-accumulus\/why-you-need-a-manager-a-ludum-dare-postmortem","text":"This is a write up detailing my personal experiments, trials, and tribulations of Ludum Dare 44. For the uninitiated, Ludum Dare (to give a game) is a 48 or 72 hour game jam where participants are given a theme and then tasked with building a game from start to finish in the allotted time frame. The compo portion is 48 hours, no teams, and published source code. The Jam portion is 72 hours, teams, and source code is not a requirement.\n\n## The Goals\n\nI set some interesting goals this time around.  First and foremost, I wanted to see how well our team would do with noone leading the charge.  I didn\u2019t take notes, write tasks, document plans or features, or set goals.  Second, I wanted to work in 3d, as we haven\u2019t published anything in 3d yet. Very straightforward.\n\n![CoinusAccumulus-LDTitle.png](\/\/\/raw\/f55\/z\/23e9a.png)\nhttps:\/\/ldjam.com\/events\/ludum-dare\/44\/coinus-accumulus\n \n\n## Brainstorming\n \nThe theme this time around was \u201cYour life is currency.\u201d  The inclusion of the word \u201cyour\u201d in the theme was a huge sticking point for a lot of people, including us.  Our brainstorming session, or as we like to call it in-house: mindphooning, went fairly quickly, lasting only about 2 hours. Ludum Dare has a theme selection process that involves three rounds of theme voting, and then a final round for the winners from the last three. Our process is to take the list and jot down some quick and dirty first impressions before the event starts. This gives us a base to work with, where we can immediately start talking about mechanics. \n\n![brainstorm.PNG](\/\/\/raw\/f55\/z\/23e9f.png)\n\nOnce the theme was released, we reviewed the list and saw that we had\u2026 Well, we had basically nothing. The best idea from the list was \u201cpitfall but your bodies persist\u201d and the next idea was \u201chealth insurance simulator.\u201d We ended up scrapping the entire list and ran with something on a whim. The conversation was something along the lines of:\n\u201cSo you\u2019ll play as a coin.\u201d\n\u201cAnd do what, pick up currency?\u201d\n\u201cKatamari style?\u201d\n\u201cOk let\u2019s just go with this.\u201d\n\n## The First Night\n\nWe did a small bout of pre-planning. DJ mentioned he would jump on enemies. Dan started modeling out a coin or two, then to valuables. I started with the character controller.  We had decided that the quickest way to do the art pipeline was with vertex colors on simple meshes.\n\nBy midnight we had a working prototype. You were a coin. The coin rolled around and picked things up. As you picked things up, you grew larger and could pick up more things.  Everything with a mesh calculated its volume and requirements thus could be picked up. We had a game and all we had to do was add more stuff.  \n\nAfter these basics I worked on getting the movement to feel right. This was actually some pretty intense tomfoolery. The player, a simple coin, is actually five objects: \n- The player itself, which housed the controller and rigidbody. \n- The Z pivot, which was used for tilting the coin left and right as you turned to give you a proper sense of movement.\n- The X pivot, which was used to rotate the coin as you moved to give you a sense of forward or backwards momentum.\n- The collider.\n- The ground check trigger. \n\nI started with a full physics implementation of the coin. Anyone who has written a character controller in Unity knows that physics is your enemy. Real world gravity and friction just don\u2019t feel good to play in. Starting with the physics implementation told me what I needed to do, which I then pulled out of real physics and tried to make it feel good.  The player itself doesn\u2019t actually spin as it\u2019s moving forward, but the X pivot (which has the mesh renderer) does. The player doesn\u2019t actually tilt when turning, but the Z pivot does. The player object itself only moves forward, backward, turns, and jumps.  \n\nIn retrospect, the collider and trigger should have been moved up to the root level so that they weren\u2019t affected by the non-physics actions like tilting and rotating. This would have helped with FPS for the physics simulation, though the impact was negligible for this particular project. \n\n\n\n## The Rabbit Hole\n\nAfter I had a working character, Dan handed me the first round of models. Two coins and a few jewels. I dropped the coin in for the player and realized that Unity doesn\u2019t have a built in shader for vertex colors. This threw a wrench in the whole \u201cspeedy art pipeline\u201d idea. So I started writing a shader. Getting this basic vertex color shader up and running only took a couple hours at best. One major weakness in my skill set is writing shaders.  But I did it. I had a working vertex color shader, and I was proud. I called Dan over to have him take a look and he said \u201cThe coin isn\u2019t shiny.\u201d  Oh.\n\n![coinamari1.gif](\/\/\/raw\/f55\/z\/23ea8.gif)\n\nThus began my descent into madness, which lead into the next morning. It took me an embarrassing amount of time to get shininess to work on the shader.  After it was all said and done, I had spent about eight hours working to get the coin shiny.  This wouldn\u2019t be my first foray into wasting time, either.  Immediately after this, I spent another six hours or so trying to get diffuse lighting working on this shader. As a little aside - we didn\u2019t end up with specular or diffuse in the final game. This was over half a day wasted.  Giving up on lighting, I decided to press forward on the gameplay. \n\nDan had a whole slew of items ready to go, including a whole dungeon kits with tiles and walls. I mapped out a basic level and we liked where it was going overall.  Unbeknownst to us, there was a major problem brewing that we wouldn\u2019t address until the next day. \n\n## A Bit About Katamari\n\nIn any Katamari game, you play as a sticky ball. The object of the game is to roll up as much stuff and reach a set goal size for the level, usually accompanied by a timer for pressure. As you collect items, you increase in size, which allows you to pick up larger items. The cycle repeats.  Everyone once in awhile you reach a \u201cbreakpoint\u201d where your katamari levels up, accompanied with a zoom-out of the camera and a pop-up telling you that you can enter a new area. Why does this happen?\n\nAs it turns out, this is used to get the game back to sane values, load in larger areas, and generally do maintenance on the game state so things stay in control and reasonable. Well, as reasonable as a Katamari game can be. \n\n![661588_katamari-damacy-computer-wallpapers-desktop-backgrounds_1280x1024_h.jpg](\/\/\/raw\/f55\/z\/23eab.jpg)\n\n## A Wasted Day\n\nDuring the level design process I kept running into one issue over and over again. The player got out of control. There were a number of contributing factors to this: movement speed, camera position, number size limits on objects with large volumes, player scale. The one thing I couldn\u2019t answer was how to reel the player in. I spent the better part of the second day tweaking numbers, adding multipliers to change value scales, and generally failing.  I was focusing on the details and not the game.  \n\nA small part of me wanted to give up on the idea, call the whole project a wash and change the game idea.  I stepped back and laid on the couch, taking the opportunity to watch some gameplay from various Katamari games to see what secret sauce I was missing.  That\u2019s when it dawned on me - our player never leveled up. \n\nFrom an architectural perspective, this level up system is pretty advanced. It involves loading in new, large objects and unload old, small objects. It also involves resetting camera values, player scale and volume settings, and any other maintenance that needs done.  Unity has some support for this built in with additive scene loading and unloading, but this is at best a partial solution for the whole problem. We were reaching the end of the second day. \n\nSunday night. Very little had changed the entire day, and I didn\u2019t think I\u2019d have time to change the architecture of the project at this point. So I asked what the team thought. Should we go for pure katamari and focus on the systems, scrapping all of the AI work DJ had done and shifting all focus on getting loading working, or should we scrap most of the katamari system?  We decided the best route for the success of the game was to do the latter, and thus it became a 3D platformer. \n\n## Super Secret Shader Stint\n\nOur game looked terrible.  During the previous day, one of the largest complaints was \u201cI can\u2019t see through this stupid bookshelf.\u201d I had extended the shader a bit to discard geometry that was close to the camera, but after I wrote it I realized I could just increase the near clipping plane in Unity to get the exact same effect.  I knew I could do better, so I got up in the middle of the night. With my newly grown shader muscles, I set out to add dithering to the cut. This worked marvelously and made me think of the latest Mario and Zelda games, which made me want to try my hand at the lighting again.  This time around I discovered how to write custom lighting, so I wrote up a bit of toon lighting. Then I went back to bed. \n\n![dither.gif](\/\/\/raw\/f55\/z\/23eae.gif)\n\n## The Final Push\n\nWith a fresh vision we hit the ground running, trying to glue as much of this together as possible. We really rode this one out to the max. Thanks to Unity\u2019s timeline feature, we were able to put together an opening cutscene in about 30 minutes. DJ\u2019s enemy system wasn\u2019t implemented in the main level until about 3 hours before the deadline, where we had to pause with level design so that he could implement it. We then rode level design out right up until submission hour.  The game wasn\u2019t even able to be won until about an hour before the deadline. \n\n## Why Are You Telling Me Your Life Story\n\nThis was all leading up to the big takeaway from this Ludum Dare: You need a manager.  Whether that person is yourself or someone dedicated to the role, it is vital to the success of a project. \n\nThere were many moments where I found myself flying blind, problems in front of me but no guidance or priorities. There were moments where Dan didn\u2019t know what to work on next because he didn\u2019t know what was important or what would make the cut. There were moments where DJ wanted his work to get implemented but we weren\u2019t ready to add it because the scene was checked out willy nilly. \n\nA manager\u2019s role is to give you the tools you need to be effective at your role. They\u2019re to provide you with direction when you\u2019re lost. A manager should identify potential issues and work to find a solution before the problem presents itself. We didn\u2019t have any of these things. \n\nIt\u2019s easy to get lost in a sea of \u201cwhat if\u201d scenarios, but I can confidently look back and say that we would have had almost a full extra day of development had I taken any time at all to lead the team. \n\n## So How Was The Game\n\nOverall, I think we succeeded. We\u2019re all very competent in our own areas and, at the end of the day, we were able to pull it together to make something that was largely enjoyable. While looking over the comments we\u2019ve received so far, a few points stand out that very clearly illustrate our running out of time, not having priorities, and not thoroughly testing. Had I stepped back to assess the situation, those would have been improved. \n\nOn future projects I intend to make sure someone is holding the reigns at all times, even if that someone isn\u2019t me. \n\n![post.gif](\/\/\/raw\/f55\/z\/23eb8.gif)\n\n","title":"Why You Need A Manager - A Ludum Dare Postmortem","wayback_source":[]}