File > New

Starting is always hard. A blank canvas can paralyze you with choice. The solution? Just do something - anything - because as soon as you do the canvas isn't blank anymore; now you have something you can build on, and that's a far less daunting task.

Technically the first step is picking an engine. I chose Godot (currently 4.2) because I had some experience with it in the past and I personally really value open source projects, also it's pretty lightweight and fast to use which is nice. This was before the unity fiasco but I did feel somewhat vindicated by it. That said you should pick whichever engine fits your needs, be it for comfort reasons or because you want to experiment with new tech; there is no wrong answer. You could even build your own, but I personally wouldn't unless you have a very good reason to (eg, standard engines not being able to support what you need for your game), or you're doing it for fun, that's always a valid reason.

Hello World

For myself, the first month of development went something like this. Task #1 was to put something on the screen, I started with an animated sprite I found off opengameart.org to represent the player. It didn't do anything but it's good to start with something small and easy to ramp into the bigger stuff. The first real code I wrote for the game was to begin the "database" for the game, which is just a collection of all the static information about the game, for now just the data for a handful of cards and enemies to later implement.

At this point in development the player didn't actually "exist", as far as the code was concerned the player was simply a hp bar I made, we don't need anything else for the time being. From there I started building the Enemies. Once both of those were done the game was just a wizard on one side with an hpbar, and an enemy on the other. You could press a button to decrement hp to test and "end turn" to verify that the enemy intents updated correctly.

Next I made a little test for the logic of controlling and pouring the cards (for the simple character), and configured the way your cards would fan in your hand and behave when hovered. I then got to work on actually implementing the cards themselves, first getting them to load their stats from the DB file, the process has lead me to redesigning things several times in how the cards are actually implemented, for example I separated the description from one into two richTextLabels so as to better control the spacing and such. It was around this time that I decided to cut having 3 possible card effects; the space requirement was unwieldly.

Journal

Beside my source directory I also have one for journals, one file per month (sometimes one for a couple if I didn't do much). The main objective with this is to track my progress and note any bugs or issues I find so that I don't forget them and can fix 'em when I finish whatever I'm currently doing instead. Originally I wasn't planning on having a site or newsletter like this, but in hindsight I'm glad I documented things because it makes talking about the early stages of the project in detail significantly easier. 

Additionally it's nice to have a resource that documents old bugs I encountered in case I ever find it again and forget what I did to fix it. It's also a nice tool for accountability, if your journal has no entries this month it might help motivate you to get some work done to fill it. It doesn't need to be formal, whenever I stop working for the day I note what I did and whenever I see something I need to fix I jot it down to not forget, which leads us to the next topic below.

Bugs & Polish

Every project has bugs, I do my best to stomp them out when I see them but there are always more hiding... Lurking...  Anyway, some might be interested in this so I figured I'd include a section for 'em in these updates. I'll also be talking about little polish things because frankly I treat 'em the same; if something is causing UX friction then it's a bug, that's all there is to it.

Now, you might be thinking, quite fairly, "But David, aren't you super early on in development and minor bugs and polish don't matter yet because you might scrap it all later on while prototyping anyway?" To which I say yea probably. But more importantly to me is that I find it much more pleasant to build and test things that feel good, games are more fun if they don't fight you while you play them. Additionally if I focus on the game feel from the beginning then by the time I'm done the game will feel good to people picking it up for the first time, and I didn't need to go through the process of fixing code I haven't touched in a year or overlooked UX problems that I've just grown accustomed to (problems that users will most certainly not be accustomed to). Also we all know games are spaghetti code, I might as well fix things before they're tangled in 12 other systems and the bug has become loadbearing in some way. That said I'm only doing it this way because I'm fully committed to the game I'm currently making, If I was prototyping 20 ideas and planning to scrap 19 of them then much of this would be a waste of time.

Now, with that preamble out of the way, the bugs this month were as follows:

• I spent 1.5 days tracking down an issue with my card drop area (used to play cards). For a reason I still don't understand, the area was taking the position of its sibling node, not the parent, and the visual collider debug option was showing it where I told it to be, not where it actually was. I fixed it by reparenting to the sibling it wanted for whatever reason and adjusting accordingly. Very strange.

• Added the trig I mentioned in the previous blog post to make the fill bars resize when they'd be otherwise obscured by the screen edge

  • Several bugs here that were fixed, the line2Ds used would get messed up during the draw/discard animations, not entirely sure why but fixed via different parents for the horizontal and vertical lines 

• Made it so the cards lerp their positions when moving, makes things feel much better to control

• Added an invisible panel to the top left of the cards such that when you hover over one you avoid selecting the card clipping up behind it first while they're fanned out in your hand

Don't forget to sign up for the Closed-Beta and join the newsletter here!