jeywilkerson

As it turns out, the process of adding a shader in MonoGame is rather simple – so I added a basic monochrome shader to the game whenever you pause or game over.

After finishing the slime-segment logic today, I’m finally done with the game part of the tutorial. After completing the shader segment, the project will be available on itch.io.

I’ve added UI and sound effects to the game. These are probably going to be the most useful pieces of information to have going into my main project, as it’s going to borrow many things from traditional turn-based RPGs, which are mostly just menus. I’m excited to finish this tutorial and implement the actual gameplay of the game!

I added a tileset and tilemap system to store and place tiles, respectively, while working on Chapter 13 of the tutorial, and now my game is ✨aesthetic✨.

I’ve added a collision system with three different types of collision detectors: circle, axis-aligned bounding box, and container, which is just AABB but inverted. I’ve also added a PhysicsSprite class and an AnimatedPhysicsSprite class to handle sprite acceleration and velocity. Along with the collision types, I’ve added collision reactions: Block, AnchoredBlock, Bounce, Trigger, BounceTrigger, BlockTrigger, and AnchoredBlockTrigger. Block and AnchoredBlock prevent the colliding sprites from intersecting, with the difference being that sprites that use AnchoredBlock will not be moved in this process. Bounce will mirror the vector of the sprite with it when it collides, and Trigger will trigger the other sprite’s _trigger<Sprite, Sprite> Action delegate. BlockTrigger, AnchoredBlockTrigger, and Bounce do their base actions while also triggering the other sprite’s action delegate.

The problem that I’ve been having is that it seems that Block() has a bug where when an AABB and a Container collide, Block() will push the AABB out of bounds. There also seems to be an inconsistency with how Bounce() handles colliding with containers

Through steps 9 and 10 of the tutorial, you’re guided through the capabilities of MonoGame’s input handler and the process of making additions to it. I added several ways to read the state of any keyboard, gamepad, or mouse that may come my way. I also added a non-tutorial class to link a delegate action to a set of inputs so that you can skip the rather un-elegant if statement barrage that usually comes with input handling.

4 Hours later… I have animations. xml is a scourge upon humanity that must be reformed or removed. for if we are to reach greener pastures we cannot sully it with the stains of my blood, sweat, and tears that this format has reaped.

…Anyway, I’ve added a Sprite class to streamline the rendering process, an Animation class to store the frames of a TextureAtlas animation and an Anmiated Sprite class to boot. I’m going to sleep.

I followed the tutorial until chapter 7, where I coded a texture atlas parsing system. This helps with sprite organization and prevents repeated texture swaps, preventing the performance issues that may come with that by allowing us to use one texture file for multiple sprites. This is how many sprite systems work and it will be helpful for tiling systems. I also added systems for using XML files to more neatly define the bounds of individual sprites.

(bat, AND slime !?! you’re getting spoiled.)

After following steps 1-5 of the MonoGame 2D tutorial I’ve familiarized myself with the basics of the program. I’m beginning step 6 which guides you through the sprite rendering pipeline and it’s a rather unique system that take some time to get used to. I do like the low-level control that the system gives you over how the GPU renders the sprites while also being simple enough.