My little brother convinced me to enter, so here I am.
This is my first LD and I’m not even sure whether I’ll even complete my game but I’ll try to make it, right now I’m on Windows and can’t really be bothered to install something better before it starts so I’ll be using Notepad++, Löve2D, probably Paint for graphix (or Notepad++/browser if I want svg) and sunvox for sound.
About 3 hours from the end of the comp with one of the most important systems still in the works, it became clear to me that I wouldn't be able to write all the enemy AIs and finish the combat system in time... So I just decided to bail the comp and go to sleep. That'll teach me not to leave the harder parts for last.
But today's a new day and I can still make the jam, time to finish my first ever game for my first ever ludum dare!
Now you too can wait for jungle records to come in the mail.
https://ldjam.com/events/ludum-dare/48/waiting-for-jungle-records-to-come-in-the-mail
This was my first time doing a jam. I couldn't make the comp but at least I think I ended up with something I can be proud with. For the next time I'll definitely prepare a small library for handling loading data and textures and give some structure to the code, because it ended up being a huge mess. Maybe I'll bring a friend to share the ~~pain~~ fun with too.
I wrote it in F# with MonoGame, which I'm guessing is not a very popular choice. Any other jammers out there using unusual languages/stacks?
I'm going to get some sleep now, but I'm looking forward to trying other games starting tomorrow. Good night!
Yes your game may function, but is it functional? I wrote our game in MonoGame and F# -- a mostly functional programming language -- and I did it mostly using pure functions and following a sketch of The Elm Architecture.
Ok, maybe the view function is effectful because encoding your .Draw calls in a discriminated union feels like too much, even for me, and maybe I left a few bits of extremely mutable state in there because I couldn't be bothered to include them in the state type, but I think I did better than the last time.
So, we do have a GameStateMachine union this time. It defines all the states that the game could be in:
fsharp
type GameStateMachine =
| SplashScreen of int
| Menu
| Intro of int
| Day of int * DayState
| Interim of int
| EndScreen
| Credits of int
All this state is held in a mutable state variable. There's no real enforcement of read/write permissions in the methods, but .Update is the only one that was allowed to actually write to any of the variables while .Draw could only read.
Both of these functions are just very big pattern matches on the state variable. .Update is supposed to be a function that takes a GameStateMachine and returns the next GameStateMachine (in practice it updates it in place) and .Draw takes a GameStateMachine and issues side effects to the MonoGame APIs.
Why is this relevant, you ask? Well, I think having such a simple architecture enables for fast prototyping and few bugs. We had some friends playtest our game for the first time just an hour and a half before the submission deadline and it was surprisingly bug-free! Except for the intended level of jank, that is. In fact, the only actual bug I've found so far was due to the few bits of mutable state I left in because I was strapped for time.
There's this ethos of making invalid states unrepresentable in typed functional programming, and that goes a long way in solving logic bugs in your game. Do give it a try if you're into functional programming and are working in an engine that lets you write code in a language with discriminated unions/variants/whatever you wanna call them. It just works!
Please 🅱️ike and 🅱️ub🅱️cribe and 🅱️mash that 🅱️ell 🅱️utton
I hope we remember to make a game this year