{"author_link":"\/users\/jorgegamedev","author_name":"JorgeGameDev","author_uid":"jorgegamedev","comments":[],"epoch":1514424939,"event":"LD40","format":"md","ldjam_node_id":71848,"likes":19,"metadata":{"p_key":"107807","p_author":"JorgeGameDev","p_authorkey":"1000094","p_urlkey":"323617","p_title":"Building the Character Logic in Jazzy Beats!","p_cat":"LDJam ","p_event":"LD40","p_time":"1514424939","p_likes":"19","p_comments":"0","p_status":"WAYBACK","us_key":"1000094","us_name":"JorgeGameDev","us_username":"jorgegamedev","event_start":"1512086400","event_key":"70","event_name":"LD 40"},"node":{"_collation":{"body_sanitizer":"TextUtils::SanitizeHTML via existing importer","event":"LD40","removed_author":false},"_superparent":49883,"_trust":3,"author":94,"body":"![ProgrammingBanner.png](\/\/\/raw\/e5\/z\/ec49.png)\n\nThese weeks certainly went fast, didn't they? It's kind of amusing to think that judging phase ends in less than 24 hours! However, we at [Whales And Games](https:\/\/twitter.com\/WhalesAndGames) still feel like there's still so much we could talk and post about the game's development that we didn't get the chance to cover during this judging phase (for a multitude of reasons).\n\nIn similar fashion to how our graphics designer [has written a devlog about creating the characters and the art direction](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/2-days-of-drawing-characters-for-jazzy-beats) and to how our music's composer [wrote another in-regards to his workflow and challenges in composing music](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/dropping-the-musical-beat-on-jazzy-beats), now it's my turn to talk about the programming structures and methodologies I used for developing the different character's logic in our _Ludum Dare 40_ game - [**Jazzy Beats**](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats).\n\n## Whales And Games :heart: Unity\n\n![Programming1.png](\/\/\/raw\/e5\/z\/ec4a.png)\n\nFor *Jazzy Beats*, we decided to stick to what we know and use ***Unity*** as the engine to develop the game once again. It's been my tool of choice for almost four years now and I've used it on the past four _Ludum Dare_'s we've participated on. As such, it's an engine I've grown comfortable with, both in terms of workflow, as well as in terms of it's scripting structure (built on top of _C#_). As for the IDE itself, I use ***Visual Studio***, not only because of all the tools and integrations it offers when paired with *Unity*, but also because of how standard of an IDE it is for pretty much everything programming, be it standalone programming, be it with other game engines.\n\nEven so, after all these years using the _Unity_ engine and programming, I still find myself learning better and different ways of getting around, and improving my methodologies when it comes to managing code. Looking back to just a few months ago, when we were updating our _Ludum Dare 36_ game, [_Colossorama_](http:\/\/whalesandgames.com\/colossorama\/), for it's anniversary update I ended up spending a great amount of time just restructuring some of it's early code in order to optimize it and make it easier to introduce the new mechanics we wanted to add with the new update. \n\n![ProgrammingVS.png](\/\/\/raw\/e5\/z\/ec4b.png)\n\nThe point is, even while working with the same engine for years, you always end up learning more and further stuff that always helps you refine your future projects as you go, and the past projects we've developed were what allowed us to develop _Jazzy Beats_ as it currently stands. One of the programming aspects that ended up being the most important for the game's development that I only really understood the flexibility as off recently, for example, was _Inheritance._\t\n\n## The Power of Inheritance\n\nAlthough _Jazzy Beats_' behaviours and characters aren't anything ground-breaking or extraordinary, without some code management and methodologies, it would have been hard to develop and iterate on every single character's behaviours at the iteration rate necessary during a _game jam_. \n\nAs a consequence, one of my priorities when it came to the game's development was the code's re-usability, especially when several of the character's actions are shared between all of them - be it the Player, the Enemy, or the Fans. One basic example of these actions was the basic punch, which all of these past three characters feature. In order to aid with this re-usability, one of the things I turned too was _abstraction_ and _inheritance_.\n\n![Programming2.png](\/\/\/raw\/e5\/z\/ec4c.png)\n\nSome of the most basic actions are shared between all of the characters, be them controlled by the player or not. For example, all of the characters use and require components such as a `Rigidbody2D`, and have variables such as `health`, `damageDealt`, `velocity` and feature functions such as `TakeDamage()`and `Knockback()`. All of these functions are shared between all of these characters and feature no differences. However, functions that require more specific functionality depending of the character, such as `Movement()`and `Attacking()`are marked as `abstract` and are later overridden, and filled in depending on the character we're working on.\n\nAs such, all of the characters on the game derive from one base and template abstract controller known as the `CharController` which has all the base fields and functionality for a working character. This controller is later inherited and expanded into new and more specific controllers such as the `PlayerController` in which, for example, the abstract function `Movement()`is overridden with the code used for recognizing the player's input. These controllers are also expanded with new functions exclusive to that character, such as `ApplySparkAttack()` function, which allows the player to use their ranged attack and which is exclusive to their controller only.\n\n![ProgrammingSpark.png](\/\/\/raw\/e5\/z\/ec5b.png)\n\nThis allowed any specific base check or tweaking to be made to all the characters at once, if justified, or specifically tweaked according to the functionality of each individual character. With this structure, I was able to save time with several of the programming tasks that would have been needed if I tried to make separate individual controllers for each of the characters.\n\nHowever, inheritance is always a mold-able and relative. While writing this section, I can think of several points in which this design and template could be improved further upon. However, given the time limit, you can't be a perfectionist in regards to it either. Don't let code perfectionism hold you back while there are features you could be implementing at that moment, but make sure that your code is maintainable to the point you can quickly make changes and adaptations to it.\n\n## Character Controllers & Pseudo-AI\n\nWith inheritance applied to the characters, the next step was to start connecting this controller structure to the actual gameplay logic of the characters. As referred in the last section, since the base `CharController` class `Movement()`and `Attacking()`functions are marked as `abstract`, each of the extended controllers have their own different logic for that same function.\n\nFor the `PlayerController` these functions mostly check which input the player has done, such as applying a velocity to the `Rigidbody2D` depending on the axis that the player is currently inputting, and deploying different attacks depending on their button presses. Not too shabby and a set of controls most likely similar to what most _Ludum Dare_ contestants did with their games as well. \n\nIt's worth side-noting that, for the concern of getting up to speed with Player input and being able to include _Gamepad Support_ out of the box, we used the _Unity_ plugin [**Rewired**](https:\/\/www.assetstore.unity3d.com\/en\/#!\/content\/21676) as an input wrapper, instead of the default one. It's a great extension that I absolutely recommend to everyone that has been struggling with expanding _Unity_'s input for a while now.\n\n![ProgrammingRewired.png](\/\/\/raw\/e5\/z\/ec4d.png)\n\nHowever, it's when it comes to other characters that the controllers need to be thought of differently. As opposed to the Player, neither Enemy nor Fans have a direct input, meaning that all their actions and decisions needed to be made through code. As such, both of these feature what I like to call a _pseudo-AI_ through a set of checks that are made to see what types of actions the controller should make depending on their situation. I call it _pseudo-AI_ because their decisions are made up of conditional statements, rather than an adaptive artificial intelligence algorithm (such as machine learning ~~which would be insane for a game jam~~). \n\nThe most basic example of these condition checks is with the `EnemyController`. For Bluessom's movement and attack patterns, she will check for any opposing-affiliation Fans (in this case, Player fans) in a wide zone around her and target the one closest to her. Depending on the attacks that are currently available and not on cooldown, she will roll a random number to decide which attack she should use on the currently target fan, and will continue attacking them until they eventually turn over to her side again. Since the amount of fans quickly ramps up during the game, eventually, one Bluessom's attack will hit more than one fan at a time, converting multiple fans in one ago.\n\n![ProgrammingAI.gif](\/\/\/raw\/e5\/z\/ec4e.gif)\n\nThe `FanController` works in a similar fashion to the Enemy one, except instead of Fans moving only when one of the idols is near them, they'll will always be walking towards the idol opposed to their affiliation (Bluessom's - the Enemy - fans will always move towards Jazzchan - the Player). They'll stop when it's time to perform an attack, at which point they'll perform the same base attack (the punch) that both the main characters have, followed by a cooldown to avoid them constantly doing the attack. Fans don't have any other attacks such as the kick or a ranged attack as to avoid having the player having to think on dodging different Fan attacks, making their main focus avoiding and converting fans as fast as possible.\n\nOne of the earlier issues we faced upon once the fan count started increasing was that all the fans targeting a specific idol would eventually converge into a single moving line since they'd all be moving towards a single point (the Player's position) at the exact same velocity. In order to circumvent this, we introduced a slight random variation in their movement speeds (rolled when the fan is spawned), together with a position displacement that's added to their target's position, making each fan target a point around the character, rather than the character's absolute position itself. These two variations alone are enough to make Fans walk and 'mob' in a much more believable fashion.\n\n![ProgrammingMovement.png](\/\/\/raw\/e5\/z\/ec4f.png)\n\nFinally, for the actual hit-checking when one of the characters performs an attack, each of the controllers will perform a box cast in front of their feet to check for any opposing-affiliation colliders in a small zone in front of them. These box casts are placed by their feet as due to the game world's perspective, as making a box cast of the same size as of the player would make the check return characters that, perspective-wise, seem above the player.\n\nPictured is the example of these box casts for the different attacks performed by the player. The yellow box represents the zone checked when the player performs a basic punch and the red one for the kicking. Finally, the green circle shows the area of fans converted when the player performs a _Ultimate Sax Drop_.\n\n![ProgrammingHit.png](\/\/\/raw\/e5\/z\/ec50.png)\n\nAs a somewhat trivia piece, one of the original designs we had in mind for the _Ultimate Sax Drop_ involved the play having to perform multiple combos in order to charge it before being able to use it. However, concerned that it could create a contrasting design with the other abilities, we eventually decided to stick with having a cooldown for it. \n\nUnfortunately, this ended up making the Ultimate a safe-guard ability, causing most players to just stick to just using it by late-game, and avoid using it during the remainder of the game. Most of the feedback in regards to the game turns around this, which goes on to prove that, sometimes, playing risky in terms of the design can be a much more rewarding, and it's a note we will take in mind for future jams.\n\n## The Game Manager & State Management\n\nAnd, finally, the last thing important to the management of the characters is the ~~dungeon master~~ `GameManager`! The _Game Manager_ is a singleton entry that is responsible for managing the overall state of the game and keeping references to other, single-entity objects that are used through the game. \n\nOne example of these objects is the `FanSpawner` which will continuously spawn more Fans (which always start with affiliation to the Enemy) as to ramp up the game's difficulty as the game progresses. Having the game starting with only a single Fan allows the player to get a general understanding of the controls before reaching late-game where they have to take multiple Fans into consideration. The `FanSpawner` will stop spawning new Fans when the total count of them in-game reaches 40 - because y'know, it's _Ludum Dare 40_.\n\n![ProgrammingFans.png](\/\/\/raw\/e5\/z\/ec59.png)\n\nTo avoid performance and other issues - especially in _WebGL_ - as the amount of Fans spawned increases, the higher the chance of them spawning without an `AudioSource` becomes higher. This not only saves a lot of memory allocated exclusively to audio (which was causing some music cut-off issues in early development), but also stops the player from hearing 40 different `AudioSource`s all playing footsteps at the same time.\n\nFinally, the `GameManager` also keeps track of the current `GameState` which check what state the game is currently on between three different states (`Starting`, `OnGoing` and `Over`). These states exist to stop the remaining objects in the game of performing certain tasks when they're not supposed too (like the `FanSpanwer` spawning Fans after the game is `Over` or `Starting`). Likewise, the character controllers also check this state for this very same reason, and will, for example, stop characters from moving once the game is `Over`.\n\n![ProgrammingGame.png](\/\/\/raw\/e5\/z\/ec5a.png)\n\nSome food for thought for the future is creating a state system for game characters. This would allow for more complex logic and conditions that are not exclusively limited to conditional statements, without potentially creating much additional workload when it comes to programming character and character actions during a game jam. \n\n![ProgrammingFlair.png](\/\/\/raw\/e5\/z\/ec51.png)\n\nAnd that pretty much wraps up this overall programming post! Getting it out in time was one big challenge due to the snowball of occurrences that happened during the whole of the judging period, but here it is, even if it's just a few hours from the end of judging phase. We still have our _Timelapse_ and _Post-Mortem_ on the way which we hope to make available as soon as we can. However, those will most likely have to wait until after the judging to see the light of day.\n\n[In behalf of our team](https:\/\/twitter.com\/WhalesAndGames) thanks for keeping up with us during this _Ludum Dare_. Yesterday, when @Moski made a [post about the coverage we got during this edition](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/coverage-appreciation), we were baffled that we had almost made it to 200 ratings. However, as of today, we've managed to smash that very goal! A whale of thank you to everyone who has made that possible and to everyone which has played our game during these last three weeks. The feedback and engagement by all of the other developers was amazing and completely broke all of our expectations. :trumpet: [**If you haven't had the chance to play and rate Jazzy Beats yet, now would be the perfect time to do it!**](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats)\n\n[If you'd like to keep up with us at Whales And Games after this _Ludum Dare_ ends, we have our very own Discord channel! It'd be wonderful to see you there!](https:\/\/discord.me\/wag) Again, Thank you! :whale:","comments":0,"created":"2017-12-28T00:39:08Z","files":[],"files-timestamp":0,"id":71848,"love":19,"love-timestamp":"2017-12-31T09:10:50Z","meta":[],"modified":"2017-12-31T09:10:50Z","name":"Building the Character Logic in Jazzy Beats!","node-timestamp":"2017-12-28T01:36:05Z","parent":59382,"parents":[1,5,9,49883,59382],"path":"\/events\/ludum-dare\/40\/jazzy-beats\/building-the-character-logic-in-jazzy-beats","published":"2017-12-28T01:35:39Z","scope":"public","slug":"building-the-character-logic-in-jazzy-beats","subsubtype":"","subtype":"","type":"post","version":211656},"node_metadata":{"n_key":"71848","n_urlkey":"323617","n_parent":"59382","n_path":"\/events\/ludum-dare\/40\/jazzy-beats\/building-the-character-logic-in-jazzy-beats","n_slug":"building-the-character-logic-in-","n_type":"post","n_subtype":"","n_subsubtype":"","n_author":"94","n_created":"1514421548","n_modified":"1514711450","n_version":"211656","n_status":"WAYBACK"},"source_url":"https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/building-the-character-logic-in-jazzy-beats","text":"![ProgrammingBanner.png](\/\/\/raw\/e5\/z\/ec49.png)\n\nThese weeks certainly went fast, didn't they? It's kind of amusing to think that judging phase ends in less than 24 hours! However, we at [Whales And Games](https:\/\/twitter.com\/WhalesAndGames) still feel like there's still so much we could talk and post about the game's development that we didn't get the chance to cover during this judging phase (for a multitude of reasons).\n\nIn similar fashion to how our graphics designer [has written a devlog about creating the characters and the art direction](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/2-days-of-drawing-characters-for-jazzy-beats) and to how our music's composer [wrote another in-regards to his workflow and challenges in composing music](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/dropping-the-musical-beat-on-jazzy-beats), now it's my turn to talk about the programming structures and methodologies I used for developing the different character's logic in our _Ludum Dare 40_ game - [**Jazzy Beats**](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats).\n\n## Whales And Games :heart: Unity\n\n![Programming1.png](\/\/\/raw\/e5\/z\/ec4a.png)\n\nFor *Jazzy Beats*, we decided to stick to what we know and use ***Unity*** as the engine to develop the game once again. It's been my tool of choice for almost four years now and I've used it on the past four _Ludum Dare_'s we've participated on. As such, it's an engine I've grown comfortable with, both in terms of workflow, as well as in terms of it's scripting structure (built on top of _C#_). As for the IDE itself, I use ***Visual Studio***, not only because of all the tools and integrations it offers when paired with *Unity*, but also because of how standard of an IDE it is for pretty much everything programming, be it standalone programming, be it with other game engines.\n\nEven so, after all these years using the _Unity_ engine and programming, I still find myself learning better and different ways of getting around, and improving my methodologies when it comes to managing code. Looking back to just a few months ago, when we were updating our _Ludum Dare 36_ game, [_Colossorama_](http:\/\/whalesandgames.com\/colossorama\/), for it's anniversary update I ended up spending a great amount of time just restructuring some of it's early code in order to optimize it and make it easier to introduce the new mechanics we wanted to add with the new update. \n\n![ProgrammingVS.png](\/\/\/raw\/e5\/z\/ec4b.png)\n\nThe point is, even while working with the same engine for years, you always end up learning more and further stuff that always helps you refine your future projects as you go, and the past projects we've developed were what allowed us to develop _Jazzy Beats_ as it currently stands. One of the programming aspects that ended up being the most important for the game's development that I only really understood the flexibility as off recently, for example, was _Inheritance._\t\n\n## The Power of Inheritance\n\nAlthough _Jazzy Beats_' behaviours and characters aren't anything ground-breaking or extraordinary, without some code management and methodologies, it would have been hard to develop and iterate on every single character's behaviours at the iteration rate necessary during a _game jam_. \n\nAs a consequence, one of my priorities when it came to the game's development was the code's re-usability, especially when several of the character's actions are shared between all of them - be it the Player, the Enemy, or the Fans. One basic example of these actions was the basic punch, which all of these past three characters feature. In order to aid with this re-usability, one of the things I turned too was _abstraction_ and _inheritance_.\n\n![Programming2.png](\/\/\/raw\/e5\/z\/ec4c.png)\n\nSome of the most basic actions are shared between all of the characters, be them controlled by the player or not. For example, all of the characters use and require components such as a `Rigidbody2D`, and have variables such as `health`, `damageDealt`, `velocity` and feature functions such as `TakeDamage()`and `Knockback()`. All of these functions are shared between all of these characters and feature no differences. However, functions that require more specific functionality depending of the character, such as `Movement()`and `Attacking()`are marked as `abstract` and are later overridden, and filled in depending on the character we're working on.\n\nAs such, all of the characters on the game derive from one base and template abstract controller known as the `CharController` which has all the base fields and functionality for a working character. This controller is later inherited and expanded into new and more specific controllers such as the `PlayerController` in which, for example, the abstract function `Movement()`is overridden with the code used for recognizing the player's input. These controllers are also expanded with new functions exclusive to that character, such as `ApplySparkAttack()` function, which allows the player to use their ranged attack and which is exclusive to their controller only.\n\n![ProgrammingSpark.png](\/\/\/raw\/e5\/z\/ec5b.png)\n\nThis allowed any specific base check or tweaking to be made to all the characters at once, if justified, or specifically tweaked according to the functionality of each individual character. With this structure, I was able to save time with several of the programming tasks that would have been needed if I tried to make separate individual controllers for each of the characters.\n\nHowever, inheritance is always a mold-able and relative. While writing this section, I can think of several points in which this design and template could be improved further upon. However, given the time limit, you can't be a perfectionist in regards to it either. Don't let code perfectionism hold you back while there are features you could be implementing at that moment, but make sure that your code is maintainable to the point you can quickly make changes and adaptations to it.\n\n## Character Controllers & Pseudo-AI\n\nWith inheritance applied to the characters, the next step was to start connecting this controller structure to the actual gameplay logic of the characters. As referred in the last section, since the base `CharController` class `Movement()`and `Attacking()`functions are marked as `abstract`, each of the extended controllers have their own different logic for that same function.\n\nFor the `PlayerController` these functions mostly check which input the player has done, such as applying a velocity to the `Rigidbody2D` depending on the axis that the player is currently inputting, and deploying different attacks depending on their button presses. Not too shabby and a set of controls most likely similar to what most _Ludum Dare_ contestants did with their games as well. \n\nIt's worth side-noting that, for the concern of getting up to speed with Player input and being able to include _Gamepad Support_ out of the box, we used the _Unity_ plugin [**Rewired**](https:\/\/www.assetstore.unity3d.com\/en\/#!\/content\/21676) as an input wrapper, instead of the default one. It's a great extension that I absolutely recommend to everyone that has been struggling with expanding _Unity_'s input for a while now.\n\n![ProgrammingRewired.png](\/\/\/raw\/e5\/z\/ec4d.png)\n\nHowever, it's when it comes to other characters that the controllers need to be thought of differently. As opposed to the Player, neither Enemy nor Fans have a direct input, meaning that all their actions and decisions needed to be made through code. As such, both of these feature what I like to call a _pseudo-AI_ through a set of checks that are made to see what types of actions the controller should make depending on their situation. I call it _pseudo-AI_ because their decisions are made up of conditional statements, rather than an adaptive artificial intelligence algorithm (such as machine learning ~~which would be insane for a game jam~~). \n\nThe most basic example of these condition checks is with the `EnemyController`. For Bluessom's movement and attack patterns, she will check for any opposing-affiliation Fans (in this case, Player fans) in a wide zone around her and target the one closest to her. Depending on the attacks that are currently available and not on cooldown, she will roll a random number to decide which attack she should use on the currently target fan, and will continue attacking them until they eventually turn over to her side again. Since the amount of fans quickly ramps up during the game, eventually, one Bluessom's attack will hit more than one fan at a time, converting multiple fans in one ago.\n\n![ProgrammingAI.gif](\/\/\/raw\/e5\/z\/ec4e.gif)\n\nThe `FanController` works in a similar fashion to the Enemy one, except instead of Fans moving only when one of the idols is near them, they'll will always be walking towards the idol opposed to their affiliation (Bluessom's - the Enemy - fans will always move towards Jazzchan - the Player). They'll stop when it's time to perform an attack, at which point they'll perform the same base attack (the punch) that both the main characters have, followed by a cooldown to avoid them constantly doing the attack. Fans don't have any other attacks such as the kick or a ranged attack as to avoid having the player having to think on dodging different Fan attacks, making their main focus avoiding and converting fans as fast as possible.\n\nOne of the earlier issues we faced upon once the fan count started increasing was that all the fans targeting a specific idol would eventually converge into a single moving line since they'd all be moving towards a single point (the Player's position) at the exact same velocity. In order to circumvent this, we introduced a slight random variation in their movement speeds (rolled when the fan is spawned), together with a position displacement that's added to their target's position, making each fan target a point around the character, rather than the character's absolute position itself. These two variations alone are enough to make Fans walk and 'mob' in a much more believable fashion.\n\n![ProgrammingMovement.png](\/\/\/raw\/e5\/z\/ec4f.png)\n\nFinally, for the actual hit-checking when one of the characters performs an attack, each of the controllers will perform a box cast in front of their feet to check for any opposing-affiliation colliders in a small zone in front of them. These box casts are placed by their feet as due to the game world's perspective, as making a box cast of the same size as of the player would make the check return characters that, perspective-wise, seem above the player.\n\nPictured is the example of these box casts for the different attacks performed by the player. The yellow box represents the zone checked when the player performs a basic punch and the red one for the kicking. Finally, the green circle shows the area of fans converted when the player performs a _Ultimate Sax Drop_.\n\n![ProgrammingHit.png](\/\/\/raw\/e5\/z\/ec50.png)\n\nAs a somewhat trivia piece, one of the original designs we had in mind for the _Ultimate Sax Drop_ involved the play having to perform multiple combos in order to charge it before being able to use it. However, concerned that it could create a contrasting design with the other abilities, we eventually decided to stick with having a cooldown for it. \n\nUnfortunately, this ended up making the Ultimate a safe-guard ability, causing most players to just stick to just using it by late-game, and avoid using it during the remainder of the game. Most of the feedback in regards to the game turns around this, which goes on to prove that, sometimes, playing risky in terms of the design can be a much more rewarding, and it's a note we will take in mind for future jams.\n\n## The Game Manager & State Management\n\nAnd, finally, the last thing important to the management of the characters is the ~~dungeon master~~ `GameManager`! The _Game Manager_ is a singleton entry that is responsible for managing the overall state of the game and keeping references to other, single-entity objects that are used through the game. \n\nOne example of these objects is the `FanSpawner` which will continuously spawn more Fans (which always start with affiliation to the Enemy) as to ramp up the game's difficulty as the game progresses. Having the game starting with only a single Fan allows the player to get a general understanding of the controls before reaching late-game where they have to take multiple Fans into consideration. The `FanSpawner` will stop spawning new Fans when the total count of them in-game reaches 40 - because y'know, it's _Ludum Dare 40_.\n\n![ProgrammingFans.png](\/\/\/raw\/e5\/z\/ec59.png)\n\nTo avoid performance and other issues - especially in _WebGL_ - as the amount of Fans spawned increases, the higher the chance of them spawning without an `AudioSource` becomes higher. This not only saves a lot of memory allocated exclusively to audio (which was causing some music cut-off issues in early development), but also stops the player from hearing 40 different `AudioSource`s all playing footsteps at the same time.\n\nFinally, the `GameManager` also keeps track of the current `GameState` which check what state the game is currently on between three different states (`Starting`, `OnGoing` and `Over`). These states exist to stop the remaining objects in the game of performing certain tasks when they're not supposed too (like the `FanSpanwer` spawning Fans after the game is `Over` or `Starting`). Likewise, the character controllers also check this state for this very same reason, and will, for example, stop characters from moving once the game is `Over`.\n\n![ProgrammingGame.png](\/\/\/raw\/e5\/z\/ec5a.png)\n\nSome food for thought for the future is creating a state system for game characters. This would allow for more complex logic and conditions that are not exclusively limited to conditional statements, without potentially creating much additional workload when it comes to programming character and character actions during a game jam. \n\n![ProgrammingFlair.png](\/\/\/raw\/e5\/z\/ec51.png)\n\nAnd that pretty much wraps up this overall programming post! Getting it out in time was one big challenge due to the snowball of occurrences that happened during the whole of the judging period, but here it is, even if it's just a few hours from the end of judging phase. We still have our _Timelapse_ and _Post-Mortem_ on the way which we hope to make available as soon as we can. However, those will most likely have to wait until after the judging to see the light of day.\n\n[In behalf of our team](https:\/\/twitter.com\/WhalesAndGames) thanks for keeping up with us during this _Ludum Dare_. Yesterday, when @Moski made a [post about the coverage we got during this edition](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats\/coverage-appreciation), we were baffled that we had almost made it to 200 ratings. However, as of today, we've managed to smash that very goal! A whale of thank you to everyone who has made that possible and to everyone which has played our game during these last three weeks. The feedback and engagement by all of the other developers was amazing and completely broke all of our expectations. :trumpet: [**If you haven't had the chance to play and rate Jazzy Beats yet, now would be the perfect time to do it!**](https:\/\/ldjam.com\/events\/ludum-dare\/40\/jazzy-beats)\n\n[If you'd like to keep up with us at Whales And Games after this _Ludum Dare_ ends, we have our very own Discord channel! It'd be wonderful to see you there!](https:\/\/discord.me\/wag) Again, Thank you! :whale:","title":"Building the Character Logic in Jazzy Beats!","wayback_source":[]}