{"author_link":"\/users\/pushxtonotdie","author_name":"pushxtonotdie","author_uid":"pushxtonotdie","comments":[],"epoch":1602017604,"event":"LD47","format":"md","ldjam_node_id":229345,"likes":6,"metadata":{"p_key":"150296","p_author":"pushxtonotdie","p_authorkey":"1023075","p_urlkey":"366801","p_title":"Things I learned from Ludum Dare 47","p_cat":"LDJam ","p_event":"LD47","p_time":"1602017604","p_likes":"6","p_comments":"0","p_status":"WAYBACK","us_key":"1023075","us_name":"pushxtonotdie","us_username":"pushxtonotdie","event_start":"1601596800","event_key":"76","event_name":"Ludum Dare 47"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD47","removed_author":false},"_superparent":212256,"_trust":2,"author":23075,"body":"I feel pretty positive about my latest LD entry: [Eat. Sleep. Rave. Repeat.](https:\/\/ldjam.com\/events\/ludum-dare\/47\/eat-sleep-rave-repeat) I decided to do this jam solo (although I did have animation help from my friend Raj). Each jam comes with a number of lessons learned, ranging from technical to project management to design. So here are my key takeaways:\n\n# Narrative is fun. Flavor is fun.\n\nOn friday night I wanted to end with some concepts and a succinct pitch. A vision that I can use for the rest of the jam. I spent friday night drawing, writing, and gathering reference. Here's my ref board I used for the rest of the jam:\n\n![ref_board.png](\/\/\/raw\/32a\/5\/z\/39393.png)\n\n# Keep It Moving \n\nPart of jamming for me in the past sometimes revolves around finding the Holy Grail of game mechanics. A unique hook that will drive the game and get people hooked. This is a totally legitimate direction, but I decided instead to focus on a number of small, simple mechanics: dialog, interactions, and light platforming.\n\nThe game starts in your bedroom, where we teach the basics of interaction. It unlocks a new interaction, which unlocks another, which unlocks another. This keeps things moving forward, and bringing in bigger and wackier events. \n\n\n# State Machines: My Unsung Hero\n\n![state_machines_everywhere.png](\/\/\/raw\/32a\/5\/z\/39386.png)\n\nMan, did I use a lot of finite state machines(FSM) in this game. A big thanks to MonsterLove for the simple state machine setup I used. Practically everything was a state machine. And I don't really think I Golden Hammer-ed it much.\n\nIn the past I might have said something like\n'If the DJ's dance counter is greater than a threshold, then move the bouncer out of the way.'\n\nBut in the FSM paradigm instead I'd say:\n'If the DJ is in the Jamming state, then move the bouncer out of the way.'\n\nAt first glance this doesn't seem like a big change. But what it does is define everything as interacting black boxes. We're less interested in specific variables, and more interested in the abstract state of a unit. This is easier to work with, and also way easier to communicate. \n\nAnd I don't mean communicate to team members, but to your players. I mean that a state of 'jamming' vs. an arbitrary collection of variables means much more to the player. I can communicate to the player visually a 'jamming' state in a much more interested way than a bland UI defining that he has X dances out of Y.\n\n# Even More State Machines\n\nIn addition to the state machines for the various objects, I made a number of state and sub-state machines using Animators that corresponded to the FSM states.\n\n![animator_fsm.png](\/\/\/raw\/32a\/5\/z\/39388.png)\n\n# Using Prefab Variants for Data!\n\n\nThere is a school of thought that ScriptableObjects in Unity are really great. I believe this stems from Schell games' tutorials on the matter. I personally could never understand why I couldn't just prefabs with monobehaviours instead. And i've been doing that for years without issue. It has a number of advantages to using Scriptable Objects which may make for a great article someday, but suffice to say that in both inheritance and composition it has advantages.\n\nBut this weekend I realized: You can create a *data template* with a prefab, then override vars with prefab variants! This allowed me to define the defaults for how 'crowd emitters' would enter the dance floor, and create variants for each stage. I will most likely be using this technique more moving forward.\n\n![prefab_variant_templates.png](\/\/\/raw\/32a\/5\/z\/39385.png)\n\n\nWell this is already longer than I wanted, but hopefully this was interesting. Thanks a lot and I hope you enjoy playing Eat.Sleep.Rave.Repeat.\n\n","comments":0,"created":"2020-10-06T20:46:21Z","files":[],"files-timestamp":0,"id":229345,"love":6,"love-timestamp":"2020-10-07T20:53:15Z","meta":[],"modified":"2020-10-07T20:53:15Z","name":"Things I learned from Ludum Dare 47","node-timestamp":"2020-10-07T00:56:49Z","parent":225199,"parents":[1,5,9,212256,225199],"path":"\/events\/ludum-dare\/47\/eat-sleep-rave-repeat\/things-i-learned-from-ludum-dare-47","published":"2020-10-06T20:53:24Z","scope":"public","slug":"things-i-learned-from-ludum-dare-47","subsubtype":"","subtype":"","type":"post","version":697245},"node_metadata":{"n_key":"229345","n_urlkey":"366801","n_parent":"225199","n_path":"\/events\/ludum-dare\/47\/eat-sleep-rave-repeat\/things-i-learned-from-ludum-dare-47","n_slug":"things-i-learned-from-ludum-dare","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"23075","n_created":"1602017181","n_modified":"1602103995","n_version":"697245","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/47\/eat-sleep-rave-repeat\/things-i-learned-from-ludum-dare-47","text":"I feel pretty positive about my latest LD entry: [Eat. Sleep. Rave. Repeat.](https:\/\/ldjam.com\/events\/ludum-dare\/47\/eat-sleep-rave-repeat) I decided to do this jam solo (although I did have animation help from my friend Raj). Each jam comes with a number of lessons learned, ranging from technical to project management to design. So here are my key takeaways:\n\n# Narrative is fun. Flavor is fun.\n\nOn friday night I wanted to end with some concepts and a succinct pitch. A vision that I can use for the rest of the jam. I spent friday night drawing, writing, and gathering reference. Here's my ref board I used for the rest of the jam:\n\n![ref_board.png](\/\/\/raw\/32a\/5\/z\/39393.png)\n\n# Keep It Moving \n\nPart of jamming for me in the past sometimes revolves around finding the Holy Grail of game mechanics. A unique hook that will drive the game and get people hooked. This is a totally legitimate direction, but I decided instead to focus on a number of small, simple mechanics: dialog, interactions, and light platforming.\n\nThe game starts in your bedroom, where we teach the basics of interaction. It unlocks a new interaction, which unlocks another, which unlocks another. This keeps things moving forward, and bringing in bigger and wackier events. \n\n\n# State Machines: My Unsung Hero\n\n![state_machines_everywhere.png](\/\/\/raw\/32a\/5\/z\/39386.png)\n\nMan, did I use a lot of finite state machines(FSM) in this game. A big thanks to MonsterLove for the simple state machine setup I used. Practically everything was a state machine. And I don't really think I Golden Hammer-ed it much.\n\nIn the past I might have said something like\n'If the DJ's dance counter is greater than a threshold, then move the bouncer out of the way.'\n\nBut in the FSM paradigm instead I'd say:\n'If the DJ is in the Jamming state, then move the bouncer out of the way.'\n\nAt first glance this doesn't seem like a big change. But what it does is define everything as interacting black boxes. We're less interested in specific variables, and more interested in the abstract state of a unit. This is easier to work with, and also way easier to communicate. \n\nAnd I don't mean communicate to team members, but to your players. I mean that a state of 'jamming' vs. an arbitrary collection of variables means much more to the player. I can communicate to the player visually a 'jamming' state in a much more interested way than a bland UI defining that he has X dances out of Y.\n\n# Even More State Machines\n\nIn addition to the state machines for the various objects, I made a number of state and sub-state machines using Animators that corresponded to the FSM states.\n\n![animator_fsm.png](\/\/\/raw\/32a\/5\/z\/39388.png)\n\n# Using Prefab Variants for Data!\n\n\nThere is a school of thought that ScriptableObjects in Unity are really great. I believe this stems from Schell games' tutorials on the matter. I personally could never understand why I couldn't just prefabs with monobehaviours instead. And i've been doing that for years without issue. It has a number of advantages to using Scriptable Objects which may make for a great article someday, but suffice to say that in both inheritance and composition it has advantages.\n\nBut this weekend I realized: You can create a *data template* with a prefab, then override vars with prefab variants! This allowed me to define the defaults for how 'crowd emitters' would enter the dance floor, and create variants for each stage. I will most likely be using this technique more moving forward.\n\n![prefab_variant_templates.png](\/\/\/raw\/32a\/5\/z\/39385.png)\n\n\nWell this is already longer than I wanted, but hopefully this was interesting. Thanks a lot and I hope you enjoy playing Eat.Sleep.Rave.Repeat.\n\n","title":"Things I learned from Ludum Dare 47","wayback_source":[]}