{"author_link":"\/users\/sean-esopenko","author_name":"Sean Esopenko","author_uid":"sean-esopenko","comments":[],"epoch":1664947067,"event":"LD51","format":"md","ldjam_node_id":308642,"likes":18,"metadata":{"p_key":"168638","p_author":"Sean Esopenko","p_authorkey":"1298673","p_urlkey":"396396","p_title":"Godot's features we loved using when making Clique Hell High","p_cat":"LDJam ","p_event":"LD51","p_time":"1664947067","p_likes":"18","p_comments":"0","p_status":"WAYBACK","us_key":"1298673","us_name":"Sean Esopenko","us_username":"sean-esopenko","event_start":"1664496000","event_key":"114","event_name":"Ludum Dare 51"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD51","removed_author":false},"_superparent":296586,"_trust":2,"author":298673,"body":"[![logo_large_color_light.png](\/\/\/raw\/1be\/84\/z\/523ca.png)](https:\/\/godotengine.org\/)\n\nNone of us on our team made a game before, let alone participated in a game jam, so we were quite nervous participating in Ludum Dare 51. [Godot](https:\/\/godotengine.org\/), an open source and free game engine, was the tool that we decided on using and we wouldn't have completed [Clique Hell High](https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high) if we a different engine.\n\n![map_prototype_in_godot.png](\/\/\/raw\/1be\/84\/z\/523ce.png)\n*The final gauntlet of our game built in Godot 3.5.1 with custom tooling created during the weekend jam*\n\n## We were able to animate cut scenes for Clique Hell High right in Godot\n\n![animatin_player_example_short.gif](\/\/\/raw\/1be\/84\/z\/523db.gif)\n*Animations were composited right in Godot for the opening and cut scenes, speeding up our workflow*\n\nAs the jam progressed we started to get the hang of the essential functions of Godot's animation system. Godot lets you animate \"everything,\" meaning any property of any node could be animated such as:\n\n* Visibility of a node\n* Position\n* Opacity\n\nKeyframes could be dropped in, animation frames of an animated sprint chosen, then the resulting animated scene dropped in the game. It was quick enough to work with to rule out using secondary software for compositing our animations.\n\n## It's free (but not that kind of free)\n\nLet's be honest, free is good, and by free, I don't mean monetary free.  I mean zero control over how we use the software. With 6 of us sharing the wifi, our internet was a little spotty at times, and if we had to deal with license\/registration servers glitching out right in the middle of our jam, we'd have failed entirely.  Godot has no licensing servers so you don't have to worry about a poor internet connection preventing your use of the tool. Oh and it doesn't cost money.\n\n## Killer App: Scenes Inside Scenes\n\n![final_room_in_editor.png](\/\/\/raw\/1be\/84\/z\/523d5.png)\n*The final room as a scene, which ended up being instanced in the main level as a node itself*\n\nGit version control let multiple team members work on the project at the same time and Godot takes advantage of this with scenes being useable as regular nodes. One team member could be declared as the current owner of a scene (such as the ending area of our game) and hands off for other team members.  Then another team member could drop an instance of said scene in the master level scene, and both team members could thus contribute to the level without merge conflicts.  Game engines which don't let the designers instance scenes inside scenes reduce the ability to team up and work simultaneously on problems, because merge conflicts can arise when working on the same scene. This let us work faster, as a result.\n\n## GDScript is easy to learn\n\n![gdscript_snippet.png](\/\/\/raw\/1be\/84\/z\/523d6.png)\n*GDScript has been easy to pick up and sophisticated enough to solve problems*\n\nIt's python-like meaning that the syntax is quick to pick up on if one's used python, and quick to pick up on if one hasn't.  No curly braces to miss which means newer devs on the team don't have to troubleshoot syntax errors due to missing closing braces. The textual `not` `and` keywords are easy to read. Not only is it syntactic sugar, but the editor itself is quite powerful, adequate for small projects without having to reach for other tools. No need to install 3gb of dot.net SDKs, no worry about C++ linkers misbehaving on different systems.  Download it and program right away.\n\n## It has an HTML5 export\n\n![html5-topper.png](\/\/\/raw\/1be\/84\/z\/523d7.png)\n\nThere are just too many games to go through during the jam to download and install games and being able to export to HTML5 was key to letting people play our game with ease. We didn't run into any major problems that wouldn't have happened in Unity any ways. Loading of content was done in loading scenes before playing said content, to ensure that stuttering didn't occur during gameplay or cut scenes. We used the GDNative mode for the HTML5 exporter and the game played well enough in browsers to not hear any complaints from players so far.\n\n## We built tools for our designers with `tool`\n\nIn a gdscript file, if the keyword `tool` is placed at the top, then it exposes whether the node is rendered in the editor or in the game with a simple `if Engine.editor_hint:` conditional. This was used for a few key game components which allowed our level designers to tweak the level components and see the results right in the enditor.\n\nThe most useful one was the editor hint to determine if a cat or dog should be rendered right in the game engine editor, letting our designers see visually which enemies were toggled as dogs and which as cats.\n\n```\nfunc _process(_delta):\n\tif not Engine.editor_hint:\n\t\t_handle_facing()\n\t\t\n\tif Engine.editor_hint:\n\t\t_set_visual()\n\t\tvar should_show_aim_line:bool = not aim_at_player\n\t\tif not show_aim_line and should_show_aim_line:\n\t\t\tshow_aim_line = true\n\t\t\t$LineFireDirection.show()\n\t\tif not should_show_aim_line and show_aim_line:\n\t\t\tshow_aim_line = false\n\t\t\t$LineFireDirection.hide()\n\t\tif show_aim_line:\n\t\t\tcalc_line_dir()\n```\n*Checking whether it's the editor that's rendering and if so, rendering visual aids for the level designers*\n\nThe custom script variables accessible for the enemies were picked up on by the editor, and visuals were rendered accordingly.\n\n![enemy_variables.png](\/\/\/raw\/1be\/84\/z\/523cf.png)\n\nSome of the enemies aim directly at the player, while others fire in a fixed direction.  This was done with an `aim_at_player` variable, which was then picked up on in the editor to render a visual guide.\n\n![editing_enemy_with_tool.gif](\/\/\/raw\/1be\/84\/z\/523d1.gif)\n\nThen with a simple function, if `aim_at_player` is false, it determines the direction based off the angle configured.\n\n```\nfunc _get_line_fire_dir()->Vector2:\n\tvar r := deg2rad(aim_direction)\n\tvar p :=  (Vector2(cos(r), sin(r)).normalized() * aim_guide_length) as Vector2\n\treturn p\n```\n\n## The command line interface is build pipeline friendly\n\nWe set up an automated build pipeline using github actions (which you can read about in my previous article, [We released Clique Hell High 112 times and this is how we did it...](https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high\/we-released-clique-hell-high-112-times-and-this-is-how-we-did-it). Godot has a sophisticated command line interface that lets you do most everything related to exporting directly from the command line without special tooling. The selection of ready-to-use github actions was large enough for us to find one that worked well within an hour.\n\n## Summary\n\nOverall, Godot exceeded our expectations. Most folks on the team who used godot over the jam had never used it before, but were able to contribute to the game effectively. It's easy enough to learn \"on the job\" and Godot never really got in our way as we worked on the game. For anybody who hasn't tried it out, give it a whirl, because it was more than adequate for us and key to being able to deliver [Clique Hell High](https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high) and all of the content in it within the 72 hour time constraint.","comments":8,"comments-timestamp":"2022-10-06T12:00:22Z","created":"2022-10-05T04:25:29Z","files":[],"files-timestamp":0,"id":308642,"love":18,"love-timestamp":"2022-10-05T09:08:52Z","meta":[],"modified":"2022-10-06T12:00:22Z","name":"Godot's features we loved using when making Clique Hell High","node-timestamp":"2022-10-05T05:47:25Z","parent":300633,"parents":[1,5,9,296586,300633],"path":"\/events\/ludum-dare\/51\/clique-hell-high\/godots-features-we-loved-using-when-making-clique-hell-high","published":"2022-10-05T05:17:47Z","scope":"public","slug":"godots-features-we-loved-using-when-making-clique-hell-high","subsubtype":"","subtype":"","type":"post","version":960442},"node_metadata":{"n_key":"308642","n_urlkey":"396396","n_parent":"300633","n_path":"\/events\/ludum-dare\/51\/clique-hell-high\/godots-features-we-loved-using-when-making-clique-hell-high","n_slug":"godots-features-we-loved-using-w","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"298673","n_created":"1664943929","n_modified":"1665057622","n_version":"960442","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high\/godots-features-we-loved-using-when-making-clique-hell-high","text":"[![logo_large_color_light.png](\/\/\/raw\/1be\/84\/z\/523ca.png)](https:\/\/godotengine.org\/)\n\nNone of us on our team made a game before, let alone participated in a game jam, so we were quite nervous participating in Ludum Dare 51. [Godot](https:\/\/godotengine.org\/), an open source and free game engine, was the tool that we decided on using and we wouldn't have completed [Clique Hell High](https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high) if we a different engine.\n\n![map_prototype_in_godot.png](\/\/\/raw\/1be\/84\/z\/523ce.png)\n*The final gauntlet of our game built in Godot 3.5.1 with custom tooling created during the weekend jam*\n\n## We were able to animate cut scenes for Clique Hell High right in Godot\n\n![animatin_player_example_short.gif](\/\/\/raw\/1be\/84\/z\/523db.gif)\n*Animations were composited right in Godot for the opening and cut scenes, speeding up our workflow*\n\nAs the jam progressed we started to get the hang of the essential functions of Godot's animation system. Godot lets you animate \"everything,\" meaning any property of any node could be animated such as:\n\n* Visibility of a node\n* Position\n* Opacity\n\nKeyframes could be dropped in, animation frames of an animated sprint chosen, then the resulting animated scene dropped in the game. It was quick enough to work with to rule out using secondary software for compositing our animations.\n\n## It's free (but not that kind of free)\n\nLet's be honest, free is good, and by free, I don't mean monetary free.  I mean zero control over how we use the software. With 6 of us sharing the wifi, our internet was a little spotty at times, and if we had to deal with license\/registration servers glitching out right in the middle of our jam, we'd have failed entirely.  Godot has no licensing servers so you don't have to worry about a poor internet connection preventing your use of the tool. Oh and it doesn't cost money.\n\n## Killer App: Scenes Inside Scenes\n\n![final_room_in_editor.png](\/\/\/raw\/1be\/84\/z\/523d5.png)\n*The final room as a scene, which ended up being instanced in the main level as a node itself*\n\nGit version control let multiple team members work on the project at the same time and Godot takes advantage of this with scenes being useable as regular nodes. One team member could be declared as the current owner of a scene (such as the ending area of our game) and hands off for other team members.  Then another team member could drop an instance of said scene in the master level scene, and both team members could thus contribute to the level without merge conflicts.  Game engines which don't let the designers instance scenes inside scenes reduce the ability to team up and work simultaneously on problems, because merge conflicts can arise when working on the same scene. This let us work faster, as a result.\n\n## GDScript is easy to learn\n\n![gdscript_snippet.png](\/\/\/raw\/1be\/84\/z\/523d6.png)\n*GDScript has been easy to pick up and sophisticated enough to solve problems*\n\nIt's python-like meaning that the syntax is quick to pick up on if one's used python, and quick to pick up on if one hasn't.  No curly braces to miss which means newer devs on the team don't have to troubleshoot syntax errors due to missing closing braces. The textual `not` `and` keywords are easy to read. Not only is it syntactic sugar, but the editor itself is quite powerful, adequate for small projects without having to reach for other tools. No need to install 3gb of dot.net SDKs, no worry about C++ linkers misbehaving on different systems.  Download it and program right away.\n\n## It has an HTML5 export\n\n![html5-topper.png](\/\/\/raw\/1be\/84\/z\/523d7.png)\n\nThere are just too many games to go through during the jam to download and install games and being able to export to HTML5 was key to letting people play our game with ease. We didn't run into any major problems that wouldn't have happened in Unity any ways. Loading of content was done in loading scenes before playing said content, to ensure that stuttering didn't occur during gameplay or cut scenes. We used the GDNative mode for the HTML5 exporter and the game played well enough in browsers to not hear any complaints from players so far.\n\n## We built tools for our designers with `tool`\n\nIn a gdscript file, if the keyword `tool` is placed at the top, then it exposes whether the node is rendered in the editor or in the game with a simple `if Engine.editor_hint:` conditional. This was used for a few key game components which allowed our level designers to tweak the level components and see the results right in the enditor.\n\nThe most useful one was the editor hint to determine if a cat or dog should be rendered right in the game engine editor, letting our designers see visually which enemies were toggled as dogs and which as cats.\n\n```\nfunc _process(_delta):\n\tif not Engine.editor_hint:\n\t\t_handle_facing()\n\t\t\n\tif Engine.editor_hint:\n\t\t_set_visual()\n\t\tvar should_show_aim_line:bool = not aim_at_player\n\t\tif not show_aim_line and should_show_aim_line:\n\t\t\tshow_aim_line = true\n\t\t\t$LineFireDirection.show()\n\t\tif not should_show_aim_line and show_aim_line:\n\t\t\tshow_aim_line = false\n\t\t\t$LineFireDirection.hide()\n\t\tif show_aim_line:\n\t\t\tcalc_line_dir()\n```\n*Checking whether it's the editor that's rendering and if so, rendering visual aids for the level designers*\n\nThe custom script variables accessible for the enemies were picked up on by the editor, and visuals were rendered accordingly.\n\n![enemy_variables.png](\/\/\/raw\/1be\/84\/z\/523cf.png)\n\nSome of the enemies aim directly at the player, while others fire in a fixed direction.  This was done with an `aim_at_player` variable, which was then picked up on in the editor to render a visual guide.\n\n![editing_enemy_with_tool.gif](\/\/\/raw\/1be\/84\/z\/523d1.gif)\n\nThen with a simple function, if `aim_at_player` is false, it determines the direction based off the angle configured.\n\n```\nfunc _get_line_fire_dir()->Vector2:\n\tvar r := deg2rad(aim_direction)\n\tvar p :=  (Vector2(cos(r), sin(r)).normalized() * aim_guide_length) as Vector2\n\treturn p\n```\n\n## The command line interface is build pipeline friendly\n\nWe set up an automated build pipeline using github actions (which you can read about in my previous article, [We released Clique Hell High 112 times and this is how we did it...](https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high\/we-released-clique-hell-high-112-times-and-this-is-how-we-did-it). Godot has a sophisticated command line interface that lets you do most everything related to exporting directly from the command line without special tooling. The selection of ready-to-use github actions was large enough for us to find one that worked well within an hour.\n\n## Summary\n\nOverall, Godot exceeded our expectations. Most folks on the team who used godot over the jam had never used it before, but were able to contribute to the game effectively. It's easy enough to learn \"on the job\" and Godot never really got in our way as we worked on the game. For anybody who hasn't tried it out, give it a whirl, because it was more than adequate for us and key to being able to deliver [Clique Hell High](https:\/\/ldjam.com\/events\/ludum-dare\/51\/clique-hell-high) and all of the content in it within the 72 hour time constraint.","title":"Godot's features we loved using when making Clique Hell High","wayback_source":[]}