{"author_link":"\/users\/kylethecoder","author_name":"KyleTheCoder","author_uid":"kylethecoder","comments":[],"epoch":1683117796,"event":"LD53","format":"md","ldjam_node_id":369215,"likes":4,"metadata":{"p_key":"200641","p_author":"KyleTheCoder","p_authorkey":"1221166","p_urlkey":"433310","p_title":"The Silver Fleet method","p_cat":"LDJam ","p_event":"LD53","p_time":"1683117796","p_likes":"4","p_comments":"0","p_status":"WAYBACK","us_key":"1221166","us_name":"KyleTheCoder","us_username":"kylethecoder","event_start":"1682726400","event_key":"118","event_name":"Ludum Dare 53"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD53","removed_author":false},"_superparent":332127,"_trust":1,"author":221166,"body":"Not really a post-mortem, nor even a retrospective, just some things I did on The Silver Fleet that made all the difference for a short jam.\n\nExaggeration is key. You only have so much time, so make things _big_. Don't think you need screen shake? Include it anyway - you're a self-respecting indie dev, after all! All of your features should have a bigger impact than you'd think. For Silver Fleet, one of the key ideas I had was having to juggle enemies by hitting them with your sword, pushing them back, and them coming back. For most enemies, I made that pushback pretty large, and one I had originally made so large he'd fly off the screen. I ended up having to trim that way down because he actually flew straight off the end of the boat if you hit him even once, but he's still in there! And to counter that, I had two \"heavy\" enemies that barely moved: they are the challenging ones with the red shirts on. (I only just realized the tie-in with Star Treks redshirts, holy moly!)\n\nAs for coding it, it was much easier than you might think. Godot supports \"areas\", which are just places that physics bodies can enter and trigger a notification. Godot 4 now also supports something called Callables - a variable representation of a function. I have a Callable defined that represents what happens if you hit the one button when you're in an area. The initial\/default one is swing_sword - if you aren't in any special area at all, it defaults back to this.\n\nThe first area I made was the pit area. This is what you jump over with the rope, so I guess the rope is more the area, but you get my point: there's an area around the rope that if you hit the button, it has you swing over the pit (big hole in the boat from cannon fire, was conceptually what I was going for). That means you can't also swing your sword while swinging on the rope, but I deemed that an acceptable trade and decided I'd work around it with the design (only loosely did that come through - by the end, I had so little time that this decision ended up being really challenging). Other areas include: bowling cannonball area, level win area (doesn't switch anything, but is useful), and I think that's it.\n\nWhich leads me to my next point: use areas or your equivalent for your engine as much as possible. They are probably the most useful Godot node available and let you gain insight into what your game is doing at times. One funny trick I learned in a previous jam that I'm including here but wasn't in Silver Fleet: create areas that turn on or off other areas. This is how you can get super-complex puzzles and stuff, and you can automate turning on and off with animations, so you can open a door to the holodeck (for instance), or blow off half the ship where if you go into it, you start to lose health. \n\nYou can typically make those new areas (B\/C for future purposes) into children of the initial area (A), which sounds confusing, but lets you do something nice: instead of making A have exported nodes or node paths to B and C, which isn't scaleable at all if you need to add D, E, and F, you just make B and C children of A and then any future children can be the same type added to the node. Then A just looks at its children and works on them logically appropriately. Sometimes this will mean making parts of your game just become hidden and turn off physics (or become free), but that's not so bad. It also means, if B and C are always going to be children, that when you add A to your main scene, you just make A have editable children and move B and C to wherever they need to go. The position isn't really relevant (or shouldn't be) to A's processing logic, so B and C can really be anywhere!\n\nAnd this leads to my final point: game engines typically don't give you the ability to make games immediately. They give you the ability to make _pieces_ of a game that you can then put together to form a game. You have to get used to this concept, and build a lot of pieces, during jams (and for your real games!), and then put them together in new and interesting ways. An example of this was having enemies in the rigging in my game, so when you swing on a rope, you can hit them. I made my rope area so that if you do hit the button while in the correct area, it would swap your action back to the default action automatically. This made it so you could kill enemies up in the rigging, which added something great to the design! I wish I had used that more. Oh well.\n\nThat's all for now. If you have any Godot questions or questions about Silver Fleet specifically, let me know! I'm always happy to help anyone.","comments":0,"created":"2023-05-03T12:03:11Z","files":[],"files-timestamp":0,"id":369215,"love":4,"love-timestamp":"2023-05-03T21:29:45Z","meta":[],"modified":"2023-05-03T21:29:45Z","name":"The Silver Fleet method","node-timestamp":"2023-05-03T12:43:16Z","parent":351282,"parents":[1,5,9,332127,351282],"path":"\/events\/ludum-dare\/53\/the-silver-fleet\/the-silver-fleet-method","published":"2023-05-03T12:43:16Z","scope":"public","slug":"the-silver-fleet-method","subsubtype":"","subtype":"","type":"post","version":1139171},"node_metadata":{"n_key":"369215","n_urlkey":"433310","n_parent":"351282","n_path":"\/events\/ludum-dare\/53\/the-silver-fleet\/the-silver-fleet-method","n_slug":"the-silver-fleet-method","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"221166","n_created":"1683115391","n_modified":"1683149385","n_version":"1139171","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/53\/the-silver-fleet\/the-silver-fleet-method","text":"Not really a post-mortem, nor even a retrospective, just some things I did on The Silver Fleet that made all the difference for a short jam.\n\nExaggeration is key. You only have so much time, so make things _big_. Don't think you need screen shake? Include it anyway - you're a self-respecting indie dev, after all! All of your features should have a bigger impact than you'd think. For Silver Fleet, one of the key ideas I had was having to juggle enemies by hitting them with your sword, pushing them back, and them coming back. For most enemies, I made that pushback pretty large, and one I had originally made so large he'd fly off the screen. I ended up having to trim that way down because he actually flew straight off the end of the boat if you hit him even once, but he's still in there! And to counter that, I had two \"heavy\" enemies that barely moved: they are the challenging ones with the red shirts on. (I only just realized the tie-in with Star Treks redshirts, holy moly!)\n\nAs for coding it, it was much easier than you might think. Godot supports \"areas\", which are just places that physics bodies can enter and trigger a notification. Godot 4 now also supports something called Callables - a variable representation of a function. I have a Callable defined that represents what happens if you hit the one button when you're in an area. The initial\/default one is swing_sword - if you aren't in any special area at all, it defaults back to this.\n\nThe first area I made was the pit area. This is what you jump over with the rope, so I guess the rope is more the area, but you get my point: there's an area around the rope that if you hit the button, it has you swing over the pit (big hole in the boat from cannon fire, was conceptually what I was going for). That means you can't also swing your sword while swinging on the rope, but I deemed that an acceptable trade and decided I'd work around it with the design (only loosely did that come through - by the end, I had so little time that this decision ended up being really challenging). Other areas include: bowling cannonball area, level win area (doesn't switch anything, but is useful), and I think that's it.\n\nWhich leads me to my next point: use areas or your equivalent for your engine as much as possible. They are probably the most useful Godot node available and let you gain insight into what your game is doing at times. One funny trick I learned in a previous jam that I'm including here but wasn't in Silver Fleet: create areas that turn on or off other areas. This is how you can get super-complex puzzles and stuff, and you can automate turning on and off with animations, so you can open a door to the holodeck (for instance), or blow off half the ship where if you go into it, you start to lose health. \n\nYou can typically make those new areas (B\/C for future purposes) into children of the initial area (A), which sounds confusing, but lets you do something nice: instead of making A have exported nodes or node paths to B and C, which isn't scaleable at all if you need to add D, E, and F, you just make B and C children of A and then any future children can be the same type added to the node. Then A just looks at its children and works on them logically appropriately. Sometimes this will mean making parts of your game just become hidden and turn off physics (or become free), but that's not so bad. It also means, if B and C are always going to be children, that when you add A to your main scene, you just make A have editable children and move B and C to wherever they need to go. The position isn't really relevant (or shouldn't be) to A's processing logic, so B and C can really be anywhere!\n\nAnd this leads to my final point: game engines typically don't give you the ability to make games immediately. They give you the ability to make _pieces_ of a game that you can then put together to form a game. You have to get used to this concept, and build a lot of pieces, during jams (and for your real games!), and then put them together in new and interesting ways. An example of this was having enemies in the rigging in my game, so when you swing on a rope, you can hit them. I made my rope area so that if you do hit the button while in the correct area, it would swap your action back to the default action automatically. This made it so you could kill enemies up in the rigging, which added something great to the design! I wish I had used that more. Oh well.\n\nThat's all for now. If you have any Godot questions or questions about Silver Fleet specifically, let me know! I'm always happy to help anyone.","title":"The Silver Fleet method","wayback_source":[]}