Day 30 of 100 [Alex_ADEdge] – Ludum Dare!

Time to review Day 30! (Im a bit late writing this one, but it is a big post so buckle up!)

So this whole post is going to be about Ludum Dare, because thats what days 21-30 were focused on.

 

Ludum Dare 41 – Intro

Ludum Dare is a Game Jam event that can be done in 2 different ways: Either the 48 hour solo ‘Compo’ – or the 72 hour, team-allowed ‘Jam’. Ive only ever entered into the Compo in the past, but this time I teamed up with a few friends (who are also doing this challenge) to make a game for the Jam!

The event started Saturday morning at 10:30am –  with the theme ‘Combine 2 incompatible genres‘. My housemate Joel and I (Joel being the other coder for the game and myself being the coder/artist) had previously discussed the idea of working on a isometric game, perhaps with some RTS elements. So with a bit of brainstorming we decided to combine a ‘Farming Simulator’ with a ‘Beat’em Up’ and add some RTS elements as well, if possible. There were a lot of features to think about, which in hindsight should have been cut back a lot. But we got working on it!

We were also joined by Chris (who worked on the music) and Aimee (who on the final night assisted with some asset modelling) and Ryan (who did a bit of writing early on!)

 

Ludum Dare 41 – A Post Mortem

Looking at how the game progressed:

The first step after getting a basic idea of the game we were looking at was to block out the level as quickly as possible in an attempt to get a grasp on its scope! This was a great way to get into the brainstorming phase hands on. I figured there would be a farmer character (blue), a farmhouse, farmland, fences/walls that could be built and animals. There would also need to be some evil bandits that raid the farm and cause trouble for the farmer (in red). This quick bit of brainstorming got us a feature-list and a solid initial direction.

Very early on I had a brainwave to include the intro menu for the game within the game itself. This was something that evolved naturally from my failed attempt at Ludum Dare 40 at the end of 2017 since I wasted a lot of time working on menus and scene transitions during that game jam. Using this approach the entire project is much more manageable since its just 1 scene! Also I thought it would be fun for the player to physically punch the start button – which would then remove the ground and literally drop them into the game. Another benefit of doing this is that it gives you a controlled ‘test’ area to develop new features away from the game area before integrating it in.

I know I’ll be reusing this idea in future game jams, it really is a very neat way of solving a few of the time consuming areas you come across during a game jam when it comes to scene management and menus!

I had a strong idea of the visuals in mind from the start, I was wanting to aim for something fun and whimsical (in contrast to the violent aspects of the game). So I quickly whipped up the farmer asset and made a bobbing idle animation, at this point it felt like the game and idea had some momentum behind it! But at this stage Id wasted a lot of time on some other areas, such as the movement and grid system – which was still giving me some serious issues (and we hadn’t even gotten to properly implementing enemy AI at this point). Around this time Joel was finishing up the randomised island generation, which was coming along nicely.

Taking the player movement down into the test level was a good milestone. It was starting to feel like a game at this point. But with enemy implementation, resource gathering and building (among other things) still to-do, I was starting to feel like we were slipping behind.

Also at this point I implemented Joel’s creature AI script and built on top of it to get some basic random moving entities in the scene. Once that was implemented I came across a pretty major programming oversight – the grid movement/rendering system was hard-wired into the character movement – which was moving using transformations only (the alternate approach being to use forces and the actual physics system). Basically I wanted proper physics interactions  (moving characters to collide/push/block each other) but the way I’d approached the foundation wouldn’t allow it, the character movement was fighting against the physics system, which wasnt what I was aiming for.

I realised that without a major overhaul this would be unworkable – and the overhaul would likely take hours. So I had to cut the grid rendering system away from the movement, and rewrite the movement with forces to work within the physics system, which meant we lost the constrained pokemon-inspired movement (nooooooooo!). Its a minor thing, but a detail and feel I wanted (and also required to base the building system on top of), but worst of all it was a lot of wasted time.

We pressed on and the above gif was a particularly entertaining moment when I decided to drop the recently finished creature-AI script onto a placeholder rock asset in the scene. We were just using cubes for a lot of objects early on (you can see trees at this point were at least in the game). As soon as the script applied to the rock object the rock popped out of the ground and started darting about randomly. Maybe I was just a bit sleep deprived, but it was one of those moments in programming that I really enjoy – when something works so unexpectedly well its a shock. I kept the ‘pet rock’ in the scene too, its off in the world somewhere wandering around as an easter-egg 😀

Early Bandit AI was a good laugh as well, Joel had the AI performing a few behaviours, but when we imported it into my build of the game they defaulted to ‘running for the hills’. Joel also got some decent randomised spawning happening, where resource islands would generate in random locations and then randomly generate resources or bandits on the islands.

Aimee (whos also doing this 100 Day challenge) got her 3D modelling on and created the sheep model, which turned out hilariously depressed and derpy. Which meant it was perfect. I created the equally derpy cows and before we knew it we had some super depressed livestock! Yay!

Then this happened at 3am that morning – a moment where one of the sheep (for no reason at all) decided to go absolutely bonkers.

The foundations for Ventureville were coming together, but still no proper gameplay! At this point we were on the final night, and I went into a 14 hour ultra-focused game-dev marathon. I got a lot of things implemented on this night, from bandit deaths and gibs, to initial work on implementing resources, animal movement and animation. I also threw together a basic UI to give feedback on how many enemies there were in the game, and likewise how well your farm was doing. And I setup the music management system and plugged in Chris’s music which he worked on during the first 2 days!

https://soundcloud.com/anicator/ventureville

The 14 hour marathon went from the monday night (around 6pm) until 8:00am the next day when I had to submit the game and unfortunately end the jam hours early go to my day-job.

By the submission time, the main missing features were:

• Resource gathering (some of this was well on the way to being done behind the scenes, but it really wasnt that present in the game)
• Building (the game has a static farm and thats it, you cant build defences or create more farms)
• Farming (You start off with a couple of farms, they count as a few points, but ultimately dont do anything)
• Player death/Lose state (the player is invincible, so youve got a slightly unfair advantage…)
• Win state (the all important win state! No win condition was implemented, the game just keeps on going once you defeat the bandits)
• Polished bandit AI – the bandits were behaving erratically and not overly intelligently, they tended to get stuck on things a lot and couldnt destroy walls etc. AI is hard..

Ludum Dare 41 – End Review of the Game Jam

What worked:

• The menu system idea was an overall win!
• The graphics turned out better than I anticipated!
• Chris made some amazing music!
• Random generation worked well in creating a different game each time and mixing things up!
• Depressed sheep!
• An actual game that was at a level where we were happy to submit it for playtesting and voting to the LD community!

What didnt work:

• Scope was too ambitious – A problem that was clear early on. The scope of the game was massive. We needed a good few more hours and probably a third programmer to even approach the scope of the foundation of Ventureville.
• Bogged down in features for too long (should have compromised sooner or ditched things that werent working or proved themselves too difficult and moved on)
• Should have aimed to implement win/lose conditions early on in the jam
• Went against my #1 &#2 philosophy of game jam rules:
  • 1) Core Gameplay (ie having some core feature thats fun and creative. Ventureville was multiple core features slapped together and none on their own were overly creative)
  • 2) Game Foundations (One thing I always stand by is the idea of having the main foundation/feature of the game implemented in the first 24 hours, Ventureville didnt have win/lose conditions or the core feature(s) done even by the end of the 72 hours)

Overall though, Im still happy with the resulting game! And my game jam philosophy hasnt changed at all, so Im still feeling like that approach is solid. Its just a matter of applying it better. I did feel like my approach improved in some ways since Ludum Dare 40, but still suffered from some repeat issues from past jams (see what didnt work above, cause thats basically the same issues present in LD 40), but overall it was a big step forwards. Im feeling a lot more comfortable making games in Unity now, so Im looking forward to participating in Ludum Dare 42 later in 2018!

 

The official page for the game can be found here:  https://ldjam.com/events/ludum-dare/41/ventureville

Or the direct link to the playable (WebGL) game is as follows: http://www.delta-edge.com/Ventureville

 

Statistics

Looking at the stats for the Ludum Dare overall:

Unfortunately the day job got in the way on Monday, and then cut short the game jam tuesday morning as well (by 3 hours). Which is a pain! Its interesting to also compare to my Ludum Dare 40 stats (which was a 48 hour compo LD), which shows that during this recent LD I only did a few extra hours of gamedev even though there was a whole extra day available.

Stats for the 100 Day challenge as of day 30 are as follows:

 

Almost 100 hours and its only day 30! Ludum Dare obviously contributed to that number a lot, but I think in the coming weeks Im going to have to dial back the hours a bit. Ive got other things I need to be focusing on, this was meant to be a more chill challenge this time round!

 

Till next time.