Weapons - Pro Unity Game Development with C# - page 193

The problem that exists now is that despite being pixel perfect, the punch weapon appears too
large for the resolution of 1024×768. But even if you change the resolution to 1920×1080, the punch
weapon appears too large to the same degree. This is because the orthographic size is resolution
dependent. If we change the resolution from one size to another, we'll also need to recalculate the
Size value. If we don't, then the Size value always scales the graphics at that size to fit the target
resolution, whatever it may be. This gives us a critical clue to achieving a certain kind of resolution
independence for CMOD. Since we know the weapon should show pixel-perfect at 1920×1080,
the size should be set to 1080 / 2 / 200 . By using and keeping this value, regardless of the game
resolution, we'll always know the Player's weapons will appear at the correct size and scale
(see Figure 6-16 ). Of course, this can involve a nonuniform scaling issue concerning aspect ratio .
We'll return to that issue later in the topic, in Chapter 8, when considering GUIs.

Figure 6-16. Weapons now display correctly

Note Repeat this process for the gun weapon, too.

Weapon Implementation: Punching
Let's now return to the specific implementation of the punch weapon ( Weapon_Punch.cs ), which
we started coding earlier in the chapter, in Listing 6-2. Now that we've coded a sprite animation
component, as well as configured the weapon sprites to render correctly for an orthographic
camera, we can make progress. Sometimes, like here, it's helpful to develop multiple classes in
parallel, jumping back and forth, testing their interoperability. Take care when doing this, however, as
interoperability between classes can lead to dependency injection . In other words, it can lead you to
create inhibiting and unnecessary dependences between classes, leaving your code scattered across
multiple source files, so that it's difficult to ever change one of the classes in isolation. When that
happens, changing the implementation of one class has implications for the other dependencies, and
so on. This can cause a nightmare of spaghetti logic. Try, wherever possible , to make your classes as