Welcome back followers to Making Valkyrie. I've got a lot to go over, so much that I'm actually going to have to split this up into 2 parts. I am as we speak stuck on a classic 90/90 situation – 90% of your code takes 10% of your time, but the remaining 10% of code gets you stuck so bad that you spend the other 90% of your time on it. Honestly I don't mind that – 90/90s are where real skill gets built and they make you a better programmer. But it is frustrating to be in it at the time. So today we'll just discuss how far I've gotten and in the next installment we will see what all that work actually gets us.

I am nearing completion on the drawable layers feature branch. Unlike previous branches I actually planned out my scope of work on paper before writing anything and the difference speed / ease of work was significant. Architectural changes to the graphics system of Valkyrie:

1 – GameScreen.OnPaintSurface() will now render a list of <IDrawable> called drawables_. IDrawable is an interface requiring the following properties:

• SKPosition (an SK Point with a Z coordinate)
• SKBitmap
• a Mirror() function
• a Scale() function

The Drawable class impelements this interface, as do all the derived classes of Drawable. Moving all the drawables to 1 list lets me get rid of some confusing duplication in the GameScreen class, it doesn't have to store lists of the /Model classes anymore, it doesn't want to know their Game Logic positions. All DeviceScreen wants to know is what to draw and where to draw it. It will be the GamePageViewModel's job to key Skpositions to the scrollbox. This was causing me trouble before because I was just asking the GameScreen to do too much and running afowl of SRP. Also the GameScreen no longer cares what the type of the object it is being passed is – the sprite could be from a prop, an obstacle or a character, as long as it satisfies the IDrawable interface it will work. The abstraction gives me a bit of dependency inversion.

2 – I have cheated and added a Z coordinate, we are no longer in the strictest sense 2D. A Z of 0 means we are in the layer where the character sprites and obstacles appear. +Z is behind this layer and -Z is in front of it. By using a coordinate plane I can draw things in any arbitrary N number of foreground & background layers. The GameScreen's drawables_ list is sorted by this criteria so that when .OnPaintSurface() is called, drawables are shown back to front. All of this work set the stage for me to add props to the Valkyrie system.

3 - The /Model.Position class has been deprecated, instead I have simply set up properties in the /Model classes that access their lower level position data. This has eliminated confusing duplication issues.

What are Props?

Props are elements which contribute to the aesthetic look & feel of a level, but are (usually) non-interactive objects. In the beginning (think Super Mario Bros., the version that came coupled with Duck Hunt in 1986) we lacked these for the simple reason that the hardware limitations didn't allow for that many sprites. Although we did already have destructible terrain.

The year is now 2020 – and my hat off to Miyamoto-san. But what can I add that has not already been done? To begin with, let's take a second to appreciate the difference in computer hardware. The 1986 NES had a Ricoh 2A03 8-bit processor with a clock speed of 1.79 Mhz, and a whole 2 kilobytes of RAM. That system had a hardware limitation of 64 on-screen sprites and had a max resolution of 256 x 240 pixels. When we moved to the SNES we got a boost to a 3.568 Mhz 16-bit processor and a whole 128 kB of RAM. This is what a prop sprite from that time looked like:

Where are we now? Any device that Xamarin can target has computing power that the early console developers could only dream of. The Android VM I am using for debugging right now – a Google Pixel 3 has a native resolution of 1,080 x 2,160 pixels, 4 GB of RAM and a 2.5 Ghz 8-core 64-bit processor. Let's look at what kind of sprite is possible to use in a frame now

This is not to say that a game dev in the year 2020 can afford to be careless, even that much computing power can get overwhelmed by poor design choices but we do have it a lot easier than they did back then. We do have other limitations to consider however, namely battery power and bandwidth which in my opinion makes 2D single player games ideal for mobile platforms. I will write a different article concerning these in the future. But we can really "go nuts" when it comes to what we populate our frame with.

Stay tuned for part 2, where we will talk about how to use props in a Valkyrie project.