Worked on creating a UIEntityTester that tests simple UI Entities–as opposed to Complex UI Entities, which are tested in a different way. Then I worked on the ability to change parts on a part card. Backing up, basically Part Cards are a UI Entity. UI Entities are what I’m calling “stuff that you can render onto a screen.” This means everything from a basic image to a complicated interactable thingy (technical term).
See, Monogame, the code framework I’m making Mech Retriever in, can render textures and models to the screen. For non-graphics-programmers, Models are 3D stuff. Textures are 2D stuff, and are sometimes wrapped around a model like a “skin.” But Mech Retriever doesn’t use 3D modeling, so textures just get rendered flat onto the screen. But I created a higher-level concept of UIEntities to make coding easier.
A UIEntity is a code object that knows how to render, load, and update itself. It also knows how to change it’s position and size on a 2D screen. What’s great about that is I can make subtypes of those objects that can do specific things, like visually display the data for a part. Better yet, I can make UIEntities that have UIEntities in them–for example, a PartCard that has TextBoxes and StatDisplayBoxes and Images, etc.
Now, I’ve created two classes that help me test them, UIEntityTester and ComplexUIEntityTester. The next post will talk about how I use these and the Visitor pattern to do automated testing in Monogame.
