AkimBear was just featured on this website! Check out their review and impressions here :bear: https://www.freegameplanet.com/akimbear-browser-game/

And play and rate here! https://ldjam.com/events/ludum-dare/43/akimbear

https://www.youtube.com/watch?v=gPRk38sGu9I

Check it out: https://ldjam.com/events/ludum-dare/43/just-delete-them/

Hello! My name is Alex, and it is my first Ludum Dare. It was veeery interesting three days, we didn't created all, that we thought, but it is preety good game, it have bugs, doesn`t have a lot of levels, but it is interesting. Thanks for all who read this. Game: https://ldjam.com/events/ludum-dare/43/bloody-path unknown.png

Thanks to Abortion Boy, I reached 1000 downloads on my itch.io account! It might not be a big number for some of you, but it's still a pleasure! Make sure to try the game if you didn't already !

Also you can share your games in the comments, I'll play and rate as much as I can tomorrow ! :)

Hi All, just dropping a note to say that I'll be live streaming more playthroughs of LD43 games tonight at 8:00 EST. You can submit your game into my play queue directly from the stream!

Here is a link to the Twitch Event https://www.twitch.tv/events/pNpvdef_RnO8uzYtvxv4wQ

Once again, Tech Valley Game Space will be live-streaming tonight at 8:30 - 11:00 PM EST on twitch.tv/techvalleygamespace! To have your game in consideration for playing and judging, you can sign up on the form below:

goo.gl/forms/zQAhArQG3Lfp2imS2

As the form already states, we do enforce a Code of Conduct in our live-streams. As such, we do reserve the right to cancel streaming and rating a game for any reason. Otherwise, come join us when the stream starts!

I'll be playing and testing games now! Come by if you want!

My stream: https://www.twitch.tv/syrapt0r

Your sacrifice.

My game needs more ratings and reviews, so please go check it out: https://ldjam.com/events/ludum-dare/43/the-gods-are-angry I've been busy recently and haven't been able to play as many games as I'd like, which hasn't helped, but I'm slowly getting round to them all.

I finally got round to making a timelapse of the creation of my game. I made it using Vegas Pro 15 (I got it today for $25 off a humble bundle). Anyway, please take a few minutes to play my game and leave a rating! :)

Game: https://ldjam.com/events/ludum-dare/43/more-sacrifices

Video: https://m.youtube.com/watch?v=ewPoFkNz3fg

PS: I'm especially proud of this one, as I actually took time to polish it, and focus on making it feel good to control and play, rather than focusing on just getting content in.

Gold Digger is on the first page for top html5 games on itch.io!

https://itch.io/games/html5

Not sure how it happened though... If anybody knows how the algorithm works, I'd be glad to know more.

Also, you might want to try it, it's fun! ;-)

Hi, Everyone!

I'm going to be playing and rating throughout the day today!

Please post a link to your jam submission in the comments. I will indicate with a <3 next to your comment when your game has been played and rated!!

Show your support and play/rate our game as well! There is a post-jam version in the blog, if you're interested in the idea but having any issues!

https://ldjam.com/events/ludum-dare/43/the-tearable-three

https://youtu.be/CUTThEnC-XE

It's not like I expected it to miss out on having enough votes, but still I'm always happy to have one less thing to worry about 😄

🎉 PARTY TIME 🎉

Hoping to write a postmortem this weekend. Lots of things happened, good and bad, so it's always useful to get those out onto paper.

Anyway, if you're looking for more players on your game, just drop me a comment and I'll take a look.

Alternatively, you can play Food Chainz, my weird whacky cute rap game, over here: https://ldjam.com/events/ludum-dare/43/food-chainz

The first week of the Ludum Dare rating and judging season has passed! Time certainly flies when you're busy playing and rating different entries, preparing material to be posted, and recovering sleep due to the unescapable claws of self-inflicted game jam crunch. Sounds like our usual way of doing things here at Whales And Games indeed!

We were expecting to post a blog post going in-depth about how the characters for our latest entry, Super Sellout (which has just smashed our last entry's record!) were created in terms of art, but unfortunately, our artist has gone internet-less for the weekend and just recently recovered it, meaning that probably for the first time ever, our first in-depth blogpost will be about the programming instead!

So let's dive right in! This post goes into the technical deeps on how the different Sponsors in Super Sellout were made, how the scoring system of the game works, and the overall benefits of Scriptable Objects and why we keep using Unity! Hope you're ready, because it's a long one!

We're still in :blue_heart: with Unity

In case you haven't seen our latest in-depth programming post from Jazzy Beats, our team at Whales And Games mostly develops projects through Unity. At least for me personally, it has been my engine of choice for five years and, as expected, I've grown comfortable with it in terms of workflow. Our other programmer, @kroltan, has also got some experience in Unity but also has his own hand-full of qualms with it. Our IDE of choice is Visual Studio, and @kroltan utilizes ReSharper on top of it. Visual Studio is pretty much the standard IDE for everything related to programming, being utilized together with other game engines beyond Unity (such as the Unreal Engine) as well.

For this edition of the jam in specific, we decided to risk it and utilize the beta of Unity 2018.3, hopefully to get accustomed to utilizing the new nested prefab workflows that are being introduced in this version (at long last!!) for development. While we did catch a few crashes here and there, and a lot more of them than usual, if we hand't decided to stick with this version, we probably wouldn't have been able to properly complete the game during the allocated jam time.

While our post on Jazzy Beats was mostly about Inheritance and how different behaviours were inherited by different characters to perform different actions, with @kroltan's inclusion in the Whales And Games team we've been trying to do things a lot more through composition. This means, breaking much more behaviours into Components and more specifically, some very underrated data containers in Unity called Scriptable Objects, which allow for fast data management and insertion without necessarily affecting the rest of the game's structure.

Scriptable What? :confused:

If you've been following Unity in the past years, then certainly you must have already seen them trying to promote the concept of Scriptable Objects through articles, tutorials and talks especially during the last year. While they certainly have been around for a while, there's still a lot of potential case-scenarios where people could be using them but end up utilizing the standard tools instead. We were guilty of this too, and only recently with us rewriting one of our past Ludum Dare projects for a future update we're planning did we realize just how handful they can be.

In a short explanation (you can read everything about them in the documentation), Scriptable Objects are essentially instances of classes that can be stored and re-used as if they were assets. If you're already accustomed with C# and using it in Unity, you're probably already accustomed to the idea that you can have classes dedicated to holding data without them necessarily having to inherit from Monobehaviour.

Scriptable Objects take this concept further by allowing you to create these data classes as if they were project assets, rather than having them be created by either code, or exposed to an inspector through Monobehaviour. These data assets can then be added to other behaviours, read from the project, etc.

Our Sponsors in Super Sellout utilize Scriptable Objects. Each different sponsor is a different asset, composed of their name, icon, explanation, how many rounds they take to unlock the sponsor, etc. While you can add logic to Scriptable Objects, we strive to keep all of the logic that is not relevant to the concept of the object itself (such as creating objects on the scene, storing runtime values associated with it) on the Scriptable Object class itself. This allows these objects to be independent on their own, serving only as data references, meaning that all of the state related to them (such as if a Sponsor is equipped or not) is stored elsewhere, and not keep with the Scriptable Object when it is serialized and deserialized.

(It should be noted that *Scriptable Objects* show the Unity standard asset icon by default, whereas we display icons thanks to the *Asset Icons* extension available on the *Asset Store*.)

As such, what we do is add all of these sponsors to our GameManager and then utilize that list through the game. The sponsors screen is the best example of this. All of the buttons for the different sponsors are created at runtime, and the icon and name of the sponsor are filled-in at the start. This would allow us to scale this screen and system infinitely if we wanted. We'd have to make graphical changes to accommodate, but we wouldn't have to directly change anything in the logic itself if we were to add more sponsors.

Each sponsor is delegated to these buttons by creating their EventTrigger when the buttons are instantiated, keeping all the logic in a single place. Sponsors that are picked by the player are then added to another list that keeps track of the sponsors that the player has equipped, and removed accordingly (such as if the player changes their mind on the sponsor equip screen). This list is frequently checked, and helps establish the magic of the following section.

Sponsor Behaviours :dog2:

With the sponsor system in place, and with the UI and GameManager wired in, the next part is to wire the different sponsors to actually affect the different facets of the game related to them.

If you have played Super Sellout by now you will have understood the whole gimmick of the game is that you sacrifice movement and your comfort while playing (which we so called sacrificing your integrity) by enabling different sponsors that cause a variety of different effects and obstacles to react to you in exchange of getting an higher score when you rescue people throughout the game (and depending on some sponsors, even based on time you have left).

It's also worth noting that most Sponsors also have different cosmetics that are overlaid on top of the character. These are stored in arrays together with the rest of the scriptable object, and are checked every frame to check if the cosmetic frame matches the one of the current player's frame.

There are a few gimmicks that are standard and re-used through the game due to the limited time-frame that we had to put the whole game together. For each of these sponsors, their logic is kept in different places, most notably being the ones that the sponsor affects. Sponsors that affect a player's abilities or controls are kept together with the player, while sponsors that affect objects are kept with those objects.

One of the most standard gimmicks, for example, is the speed reduction gimmick with different sticker sponsors you can add to you which reduce your character speed (while keeping the world speed increasing as always) in exchange of score over time. Being a sponsor that affects the player, the logic for the sticker sponsors are kept together with the rest of the player's scripts under a PlayerAffects class.

When the game begins, the scripts checks through each of the sponsors to check if they're activated, and applies the correspondent speed reduction, reducing the player's speed on the spot. The same is done for other sponsors that also affect the player, such as the Dog Sitters sponsor which applies random forces on the player's velocity at regular intervals.

As for other behaviours that are affected by sponsors, such as metal objects following you, the check is done on each individual behaviour instead. One such example is the MoveToPlayerBehaviour which causes both metal objects and the dogs to follow the player if their sponsors are active. These perform a similar check to the previous speed-affecting behaviours, checking if the sponsors that are needed to run that behaviour are equipped by the player, before actually executing it's logic in Update.

Finally, there are the sponsors that make certain objects appear on the stage if they are enabled, such as the billboards and the different puddles. Just as you might expect given the way the logic of the previous objects is checked, these are actually placed on the different rooftop segments ahead of time (or are spawned in at randomly on places dedicated to random obstacles). Once the game starts, they make the same check on ConditionalObjectSpawn likewise to the following behaviour, and depending on the result, choose to disable the object (if the sponsor is not equipped) or leave as it is (if the sponsor is equipped).

If we were to look back and think of a few ways we could have improved the way sponsors are managed and utilized throughout behaviours, we could have potentially done a single SponsorBehaviour class (for objects other than the player) to hold the checks if a sponsor is active or not in a single-place, and then inherit that class to add each specific behaviour.

Inheritance isn't inherently (heh) bad, however it can very quickly lead to a complicated upkeep of classes and deeper-than-they-need-to-be inheritance levels on top of the classic diamond problem. However, depending on very specific situations, they can potentially reduce project complexity as well, making it a double-edged sword. However, that's beyond the scope of this post, and instead we will be talking about dough, moolah, simoleans, money, because at the end of the day, that's the scoring of our game.

Money Dough' and Scoring :moneybag:

Similar to the Sponsors, Score Types are also a Scriptable Object in our project. This allowed us to create different score types and rates that are affected by the different behaviours and actions without having to individually declare each of them by code and creating adequate functions. Instead, having them as Scriptable Objects allow us to re-use the different score types, and even derive score types from each other.

We wanted to have a score breakdown screen, and for that the game needed to track where each amount of score came from. We started by making some Scriptable Objects that had some basic information about each score source, where, for example, one “Grandma Saved” would be worth $10. That worked perfectly for simple proportions, but for anything more complicated it was a bit limited.

When sponsors started being implemented, we carefully employed inheritance and created a new kind of Derived Score Type, which in addition to the base multiplication-based monetary value (where each score-type adds a certain amount of score each time) can query the value of other score types to calculate its final value. This was used in some sponsors, which awarded money proportionally to a specific type of heroic act or time.

This approach allowed quick balancing by non-programmers, as well as a clean implementation for the graphical interface, which didn’t need to differentiate between derived and pure score types. It also allowed us to quickly connect any given Sponsor or character in need of rescue to a score-type, and implement them on the scoreboard without any new overhead. Of course, even with such systems in place, there was still a lot of content ideas that had to be cut.

The Cutting Room Floor :scissors:

Even with all these systems in place, there were still a lot of ideas for different sponsors and modifiers that didn't make the final cut into the game due to it's scope. Here are some highlights of these ideas in order to not extend this post by much longer but that we still wanted to share for pure curiosity:

• Sponsors that would invert or change your controls to random keys.
• Sponsors that would make you be followed by bees or ghosts, stunning the player when they caught up with them.
• Sponsors that would play startling sounds every now and then to keep the player on their toes.
• Sponsors that would cause characters to randomly interrupt the game and talk over it, allowing as little visibility as possible.
• Sponsors that would add way more visual modifiers to the game, such as making the whole game grayscale, make it look retro, etc.
• Sponsors that would hid how much money you have achieved or how much time you have left.

With the current system in place, we could theoretically add these new effects and scenarios without much challenge other than creating their respective Scriptable Objects and adding-in their respective behaviours where it'd make the most sense to keep their functionality.

At the moment we have no plans to do an this nor update the game with new sponsors and content. However, if that was to ever become the case, the introduction of several of these ideas would definitely be one of the plans for an expansion!

Phewsh, and that ends that! I hope for those that are into programming this post is at least an interesting read or that it sheds some light in the way that we have decided to handle things with creating our sponsors in our entry, Super Sellout. Likewise to our previous jams, we still have our usual post-mortem on the way, not to mentioned the aforementioned art-cantered post.

In behalf of our team, thank you once again for all the support you have given us so far in terms of ratings and coverage. Ludum Dare is a very important and heartful event for us, and it's specially thanks to it that we are able to grow as a team and spread our word around. :whale: If you haven't had the chance to play Super Sellout, we invite you to do so, and make sure to send us your game too!

Finally, we also invite you to join us at our team's Discord server! We have a whole room dedicated to #gamedev and for talking about this type of technical jargon, and we'd love for you to share your own entries with us there!

If you've managed to reach this far, cheers, and thank you for reading! :whale2::tada:

Hi guys, first of all THANK YOU for all the nice feedback you gave.

I updated my little game with an android port.

For the moment this is just the same game as the other versions. There are no improvements or fixes... yet. I´m planning to work on a post ludum version next.

Link to my game: https://ldjam.com/events/ludum-dare/43/volcano-island

20 rating points received!

and i just want to say everyone! thanks for yours votes!

We are having a review party tonight! We are getting the crew back together to review some of your games in the hopes that you will give ours a whirl! We had fun making it together, and now we are going to have fun playing some others together. If you are in Salt lake, drop by tonight for some fun playing LD43 games! classEgames: 3333 S. 900 E., Suite 220, Millcreek, Utah 84106

Link to our game: https://ldjam.com/events/ludum-dare/43/something-evil-is-brewing

In this post I'll be describing the implementation of some of the platformer elements in Welcome to the North Pole.

Perhaps this can serve as inspiration for others or as a way to start exchanging tips. We made the game using Unity but these concepts apply elsewhere.

See also: * Part 2 - Building snowmen

Detectors

Each snowball has 4 detectors that report contact with the ground or other characters. We use them to detect whether a snowball can jump and what shape a snowman has.

Detectors are configured as trigger and only react to contact with other characters or the environment:

Our layer setup, note that it avoids inter-collisions between static layers or between triggers

This is the simplified code for the collision detection:

csharp private void OnTriggerStay2D(Collider2D other) { // Layers is defined by hand. if (other.gameObject.layer == (int) Layers.GROUND) { GroundContact = true; lastGroundContactTime = Time.time; } }

Contacts are reset in FixedUpdate(), which executes just before the physics loop (where OnTriggerStay2D is called). We moved CharacterGroundDetector last in the script execution order to make sure that the correct value can be read from other scripts' Update() or FixedUpdate() loops.

```csharp void FixedUpdate() { // Do not clear contact if the rigidbody is sleeping, // otherwise it won't be re-registered until the rigidbody wakes up. if (controller.rb.IsSleeping()) return;

// Allow some tolerance after the last contact before clearing the flag.
// This allows e.g. jumping slightly after leaving a platform.
if (Time.time > lastGroundContactTime + ContactTimeTolerance) {
  GroundContact = false;
}

} ```

Detectors are children of an "Upright" GameObject that preserves its orientation even though the snowball rotates:

csharp void FixedUpdate() { transform.rotation = Quaternion.identity; }

Visual vs physical size

Two size 1 snowballs: before accumulating snow (left) and about to grow (right)

Main ideas: * The physical size of a snowball is fixed for each stage (small/medium/large). * The visual sprite grows slowly as you accumulate snow.

This let us balance the game for a fixed collider size while giving a visual feedback that a snowball changes size (coherent with the world).

We kept the ball diameter below the size of one tile to make sure a snowball can easily fit through a gap of the corresponding size (collider diameters are 0.8, 1.8 and 2.6, a tile is 1x1).

Because snowballs are made of snow, the default visual size is already slightly bigger than the collider because a slight overlap looks more natural than having snowballs touch the ground right along their edge.

Momentum

We took the movement principles from this Sonic physics guide. Another helpful resource was this blog post by Yoann Pignole.

Main ideas: * Each snowball has a maximum speed and an acceleration factor (the bigger the snowball, the slower it is). * While a direction is held, we increase the snowball's velocity in that direction up to the maximum speed. * Velocity is not reduced if it's above the maximum speed. This lets you gather a lot of momentum on the ground and keep it while jumping, or as a small snowball and preserve it as you grow bigger (adds a nice flow and is actually helpful for one of the challenges). * The ball does have some amount of friction that we let the physics engine resolve. This is helpful to make the snowball rotate naturally as it rolls along the ground.

Translated into code, it looks something like this:

csharp private void MoveSideways() { var currentSpeed = Mathf.Abs(rb.velocity.x); var currentDirection = Mathf.Sign(rb.velocity.x); // Air speed is lower than ground speed to allow less control in the air than on ground, // but momentum is preserved if you hold the direction. var maxSpeed = Grounded ? stats.GroundSpeed : stats.AirSpeed; var targetSpeed = currentSpeed; if (currentDirection == Direction) { // Accelerate up to maxSpeed, but do not decelerate while holding the key. targetSpeed += Mathf.Min(stats.Acceleration * Time.deltaTime, Mathf.Max(maxSpeed - targetSpeed, 0)); } else if (Direction == 0) { // Decelerate up to 0 if no key is held. targetSpeed -= stats.IdleDeceleration * Time.deltaTime; targetSpeed = Mathf.Max(targetSpeed, 0); } else { // Decelerate faster until we flip direction if the opposite key is held. targetSpeed -= stats.OppositeDeceleration * Time.deltaTime; } // Apply the velocity change through a force on the rigidbody. rb.AddForce(Vector2.right * currentDirection * (targetSpeed - currentSpeed) * rb.mass, ForceMode2D.Impulse); }

Long jump

Holding the jump key makes you jump higher:

This is implemented as a combination of forces: * JumpImpulse is applied right as you press the jump key. * JumpHoldForce is applied over time, while the jump key is held, up to a maximum duration (0.35s).

In code, it looks something like this:

```csharp private void HandleJump() { // Trigger jump if (Grounded && input.Jump && !Jumping) { Jumping = true; jumpEndTime = Time.time + stats.MaxJumpDuration; // Cancel vertical velocity and jump up. // Vertical velocity must be canceled because the snowball may still be falling // when the ground detector triggers. rb.AddForce(Vector2.up * (stats.JumpImpulse - rb.velocity.y) * rb.mass, ForceMode2D.Impulse); }

    if (Time.time > jumpEndTime) {
        Jumping = false;
    }

    if (Jumping && input.JumpHold) {
        rb.AddForce(Vector2.up * stats.JumpHoldForce * rb.mass, ForceMode2D.Force);
    } else {
        // Stop jump hold force when input is released.
        Jumping = false;
    }
}

```

We later added a small tweak: moving against a wall while holding jump gives you a small additional boost (ClimbHoldForce) to counteract the added friction and because it feels satisfying:

This allows you to clear 4-high walls without building a snowman :)

End of Part 1

Thanks for reading!

See also: * Part 2 - Building snowmen

In the next parts we plan to describe: * Art style and implementation * Music and sound effect design

Feel free to post other suggestions in this thread.

@fre and @catie-jo

Hi guys after a week of catching up at work I finally got that @^#&^$@#&@&$# html build working of my game. Check it out at : https://ldjam.com/events/ludum-dare/43/cheela ! I am now also ready to play some games, I have some catching up to do!! COmment below if you want me to play your game :D

Hi guys after a week of catching up at work I finally got that @^#&^$@#&@&$# html build working of my game. Check it out at : https://ldjam.com/events/ludum-dare/43/cheela ! I am now also ready to play some games, I have some catching up to do!! COmment below if you want me to play your game :D

Tonight, I am going to be streaming working on some improvements and suggestions given by the LD community. Here is the game I will be working on.

I will begin streaming noon (EST) on Thursday, 12/13/2018.

Come stop by the stream!