[h2]Demo[/h2] On March 25th, the Deckbuilder Fest begins and will go on for a week. I'll be participating in this event with an early demo of A Witch's Game. If I can add more I will, but the demo will only have 8 cards. The purpose of entering this fest is to test out the core mechanics, so I'm not too worried about the amount of content on display (even if that may hurt people's perception of the game). [h2]Roadmap[/h2] The game currently has the core mechanics finalized in code, but not in visuals. If you're familiar with the Model View Controller (MVC) paradigm, I've finished the Model and am now working on the View, in regards to the core mechanics. Below is a screenshot of the current in-game View: [img]https://clan.cloudflare.steamstatic.com/images/44893654/6925aadf9be470447d798184740e0947181f84db.png[/img] The marketing material is just smoke and mirrors: the in-game mechanics have been placeholder hexagons up until now. But in the screenshot above, I've implemented the tiles along with visuals depicting the health of the unit currently on the tile (which you can't see). This process was pretty straightforward-- I went from placeholder visuals to this in a couple hours-- and the rest of the visuals should take a day's worth of work. After the View, I'll start working on the auxiliary mechanics, like deck-building, win conditions, and AI. I could have started on those systems first to get the entire game working with placeholder aspects, but I decided it would be better to work on the depth of the core system first. Here's why: [olist] [*] Motivation: When I thought about whether to work on more code or to work on implementing visuals, I was motivated by the idea of being able to actually see the game function. I'm just a dude, and I like to see cool things on my screen. [*] Strong Foundation: The designs of the auxiliary mechanics rely on the design of the core system, but the core system doesn't rely on the designs of the auxiliary mechanics. So if I change something with the core system [i]after[/i] creating the aux mechanics, then I'll have to go back and change those mechanics too. For instance, if I craft the AI with the intention that the witch must be killed but then I change the win condition to be something else, I'll have to redesign the entire AI to match the change of the win condition. [*] Clear Testing: By diving into the visuals of the core system, I'll get a better idea of how I want to the core gameplay to function. I can play out the whole game visually and follow the rules of aux mechanics in my head-- drawing cards at random and pretending to be the AI. [/olist] With the View finished and the aux mechanics done, I'll do some polishing and then sit on the demo until release (assuming I'm not working until the very last moment to get the demo done). [h2]Scope[/h2] I've had to cut back on this project a lot throughout development. It was originally going to be a POV game like Inscryption, but after realizing how long the project would take, I reduced it to a simple top-down, 2D perspective (if you're interested in what those visuals may have looked like, you can see my [url=https://astrobeef.itch.io/diner-duel]game jam[/url] that inspired this project). While all of these cutbacks have been disappointing, I feel more confident in my ability to get this demo done in time. I'm going to be working overtime for sure, but I can get it done. This is the start of a monthly update on the game, so see you next month when the demo is live!