Most people seem to use Godot or Unity. I did not. I made mine directly in HTML5 and TypeScript (and webpack).
Did anyone else make their games without a game engine? What did you learn?
Hey! I also chose to not use an engine. I coded my game using the LÖVE framework. I'm not familiar with any engines and didn't want to learn how to use one just for this. I have some experience with programming but no formal education in CS. I've been learning Lua/LÖVE for a month or two so this was a great opportunity to put my new skills to the test.
I learned that I like the logic and problem solving-process of coding from scratch. I felt like it made it easier and more interesting to reframe "game actions" into "code actions" (as one super basic example, the idea that 'moving' is really 'draw this picture each frame to these coordinates that increase/defrease when a button is pressed' ).
My sense is that using an engine as a beginner brings along issues of scope creep because it's easier to do more, but more doesn't mean good and more doesn't mean better than less. It was easy for me to avoid that problem because I had to spend more time making each thing work in the first place (not that I don't have sloppy code or numerous things I want to improve/add).
Finally, our success was built off a fair bit of pre-planning. We did not plan any aspects of our game before the jam started, but we made a development timeline (like when we will have our idea finalized, when we will have our first "shippable" version, when we will stop adding content and switch the polishing for submission), a schedule (wake up/go to sleep, meals, snacks, breaks, progress checks to make sure we're on track), and we took stock of our skills and preferences. Then, when the jam started, we made our list of need-to-haves, nice-to-haves, and assigned priorities, then we stuck to the plan! We actually really got into the project management side of things and that made it so much easier to handle the inevitable hiccups. it also made it way easier to relax and have fun because we knew what we were working on and needed to do at any moment.
Right, the project management side of game jams probably deserves a discussion and/or post-mortem of its own. I did it similarly to you two, with the caveat that I didn’t know what makes a minimal game viable, and thus planned iterative playtesting.
I have worked a fair share in Lua before, most notably for game mods (chiefly Don’t Starve and Invisible, Inc.). However, I’ve mostly ignored LÖVE thus far, thinking it is a game engine. Looking more into it, LÖVE seems much more light-weight than Godot, Fyrox, &c. It enforces no architectural constraints at all, beyond maybe adapters for the various interfaces. For example, one could build an Entity-Component-System structure on this, but choosing against this leaves no “dead code” to speak of. Neat!
Great prompt! And awesome to see someone else using TypeScript!
After dabbling with many game engines and frameworks, I highly prefer using the workflow of using a framework (like love2d or raylib) over an engine (like godot or unity). I find engines often make simple things much harder than they need to be. Using TypeScript gives me the type-safety and language server features I enjoy. I find that the built in web APIs for things like 2d rendering on context, input handling, sound, etc, all feel really similar to using a game framework .
I've been using this TypeScript, <canvas>, and built in web APIs approach for lots of projects (games and otherwise) lately, so I was able to reuse lots of knowledge for this game jam. However, for this game jam I wanted to experiment with the idea of using a "fat entity struct" which people from the handmade community recommend! This means that I have a large fixed array of entities where an entity has all the fields anything in my game could ever need. It ended up looking like this: https://github.com/onsclom/silly-jam/blob/main/src/state.ts#L5. This was a big change compared to how I would represent entities before, but I ended up really liking this approach. It helped us move really fast, removed a lot of potential code duplication, and various things I worried about (like performance) never became an issue!