People keep asking me about my process. It's surprisingly not special. But, in case anyone wants to know what it looks like to ship a game to Steam starting from zero, here is what I actually do. 1. Have gameplay idea. Write it down somewhere or draw some sketches to work through a few ideas. I write down everything that comes to my mind the moment I think of it, and then I curate the list later. Oftentimes, ideas I kill end up coming back in some way later. 2.Make some sprites to communicate the basic gameplay idea. The shapes need to be readable, and they need to relate to the gameplay. The player needs to have the perception that they are looking at something interactable. There should be no decorative art this early. Art should only relate to gameplay. 3. Get the sprites/UI into the game, just making sure I can draw them in the game where they are supposed to be. Whatever rendering logic you need to write to make this happen, write it. Don't support anything more than what you need to draw the art. There is no generic "renderer." There's just specific things you need to draw. Don't plan for a future which doesn't exist yet. 4. Once things can be drawn, I then make them interactable by doing things like click areas, movement, etc. This is specific to your game idea. You actually have to make the game playable as a game, using the prototype art. Gameplay doesn't come later once you have the "engine." The "engine" gets developed as a *consequence* of making the game work. There is no separation between the two. The engine is the game and vice versa. 5. As I make more and more similar things, I just extract to a function to reuse bits and pieces of what I have to do the next thing. I'm not particularly obsessive about this, trying to remove every bit of duplication. It's more like I casually notice some repeated patterns and then clean it up. Remember you are making a *game*, not raking a zen garden for personal satisfaction. 6. Over a long period of time, a "game engine" starts to emerge. But that's nothing special. It's just leftover code. The more you do this, your skill and knowledge base grows. Even if you don't have the code lying around, you will remember how you approached certain kinds of problems. Half of the "engine" is inside your head. It's your experience solving real problems.

I came across this C tutorial series on YouTube today, seems valuable to me as someone who is learning C for the first time and the videos are quite direct and to the point. https://youtube.com/playlist?list=PL71Y0EmrppR0KyZvQWj63040UEzKQU7n8&si=JjQoyWkwhWKPLuhK

I just finished day 4 the Tile System, have been following along via raylib instead as I daily drive a Mac and my PC's not always available to me (hey we make do with the cards we have right?). General feel is that RayLib feels mostly the same to what I see on Ooga Booga. So definitely no issues following along. Has been a great exercise for me so far! Anyways, just wanted to point out that because RayLib uses source and destination Rectangles to draw the sprites, the destRect itself is already kinda like a range in itself. So you don't actually need to write range.c, and can just use the CheckCollision functions (https://www.raylib.com/cheatsheet/cheatsheet.html). The bounding range data itself is kinda encapsulated in the destRect already. Also GetMousePosition defaults to (0,0) even if the mouse isn't even active yet. So I did a 0,0 check (since it'll 99.999% not be 0,0 again once you start moving it cause floats) and cached that as a bool to check against for all the range or collision checks with the mouse. That way you don't have things highlighted in the top left corner of the window everytime you launch. Also, say hi if you're working on a Mac! So we can connect and help each other troubleshoot as we follow along! Esp if you're using raylib to follow along.

Randy just announced that he opened a discord for people who are all in making and shipping the 90-day challenge game. This is cool, but one of the requirements is: - Share your "Ooga Booga engine" fork It may just be me, but I'm "all in" without the fork since I'm using a homemade engine written in Odin and using OpenGL for Graphics. I understand that the course revolves around the C engine developed by Charlie, which may be the reason why sharing the fork is required. In conclusion, by turning the stack into a requirement you might remove some of the 1% mentioned in the video. Keep up the good work.

Hi! I'm working on a port of DOOM using oogabooga: https://github.com/g0mb4/DOOMgabooga It lacks a lot of things, but it is playable. I'm not sure if I'll have time to polish it, but the journey is quite fun.