I’ve finally written a DevLog for Expedition Viridian. It’s kind of strange to come back to it as I’m describing the work I’ve done in late-January and early-February this year. The following topics will be covered:

• Reflection
• Inspiration
• What is added in the v1_1 build

Reflection:

First of all I want to thank those who have played the Expedition Viridian prototype I built for My First Game Jam: Winter 2022.

Everyone’s entries look very cool. Be sure to check them out! Here’s the link for easy access:  https://itch.io/jam/my-first-game-jam-winter-2022/entries

I didn’t expect the positive reception and feedback, and again, thank you very much for that. Although I do admit to feeling guilty for never delivering a playable game. I noticed a certain interest when I described the premise: play as a wildlife biologist who tags animals through photographing them. And while it’s not implemented yet, the gameplay loop is to look for all the creatures in the stage and be rewarded with ‘fun’ data in a bestiary.

Pre-Jam:

After coming up a game concept that fits the jam's 'Nature' theme it was to think about what genre the game should be.

I knew that I didn’t want to be writing any story script because I wanted a change of pace from visual novels. Therefore it is that type of story that is told through the gameplay action.

As for gameplay, I chose a genre which has many Unity video tutorials made about it. It should have an art style where I can make my own art assets for it. I've never done pixel art before but it seems to be fun to learn. To fit both criteria, I’ve settled for a  2D platformer that has a retro look.

During Jam:

So the process is as follows: I took it relaxingly in the first week by watching a tutorial series from Coding in Flow:  https://www.youtube.com/watch?v=Ii-scMenaOQ&list=PLrnPJCHvNZuCVTz6lvhR81nnaf1a-b67U

I’ve never built a 2D platformer before and it’s quite a long time ago I’ve dabbled in Unity. And for the rest of the week I drew the art assets and code the remaining gameplay features. I fell ill in the second week, so I rushed and submitted what I already had. At least the prototype gave the general idea of the basics of what kind of game Expedition Viridian is going to be.

Nevertheless I still consider it a successful jam and look back at it fondly, because I learned a lot thanks to your comments and would not have received them if I did not submit this entry even in its incomplete form.

Post-Jam:

With this I have to admit that I didn't really have much of a chance to play the other jam entries, because I’ve been really under the weather around that period. And when I was doing better, my first instinct was to continue working on the game. Unfortunately I never made quite meaningful progress on this project, because level design is the most important part for a platformer but I haven't got to this part. I was stuck in the prototyping phase of wanting to get the feel of the game right and every new gameplay feature addition tends to bring its own problems to fix. 

Eventually I forgot about this jam project altogether when I picked up the development again of other personal projects that were already on-going. The sole reason I came back now is because I hadn’t updated the old build for months despite having new content. It’s to wrap it up so I can move on to practice coding for new challenges in other type of projects. And even by the rare case that I ever continue with Expedition Viridian, at least I can do a new sprint after pushing this build v1_1.

Inspiration:

Narrative:

Surprisingly it initially wasn’t inspired by Pokémon Legends: Arceus, despite similarities like being tasked with missions like catching the same Pokémon species multiple times to learn more about them. I only played this game after this jam and I didn’t watch many trailers to know anything beyond it being a real-time action RPG in ancient Sinnoh setting. Pokémon Snap would be closer to the original inspiration with the concept of photography. The tagging mechanism is not realistic at all with a magical camera, like in Pokémon it’s not properly explained how the Pokéballs work.

The idea that you try to find animals who have fixed locations in a stage where the goal is to capture them all is definitely from Ape Escape.

Gameplay:

I’ve always enjoyed the exploration part in Metroidvanias and I love the sense of atmosphere these games always capture, but I have to confess that I’m not terribly good at playing them. I’m usually passable at traversing most of the platforming sections, but not skilled at boss battles.  Hence if I were to create a 2D platformer, it should be of accessible difficulty or else I can’t even playtest my own game. Wario Land series might be one of my favourite 2D platformers, because these were the few I could beat. Wario Land II stood out to me in particular because it felt unique as how it's a platformer where you can't even die so it's not particularly hard, but I remember that it was still fun to explore the different routes to find all the treasures.

Nevertheless for researching purposes I should scout for other (indie) games to see which are simple enough even for me. For example I've heard of Cave Story and could tell from looking at screenshots that it could server as a good inspiration, but I have never played it until after this jam. Then I got stuck because some parts were a bit hard for me, haha. It did give me a better idea what kind of key/button-action mappings make sense or how such games implement the camerawork as it's crucial to always see where you end up when you perform a jump.

V1_1 Build:

Cancelled implementations:

• Pixel Perfect:
  • After some playtesting, I seem to notice that the character sprite leaves some kind of black trail behind it when it moves.
  • So I set the task to find out what is causing it.  Since I'm aware that there is also a Pixel Perfect setting I wanted to see if this improves the game’s look. I painstakingly found out that using Pixel Perfect adds an extra jittery effect to the sprite when it moves, so eventually I reverted this change. Later on I read that a lot of popular pixel art games made in Unity do not even apply Pixel Perfect.
  • Turns out that the effect is most likely caused by monitor ghosting. Oh well, I learned the hard way that I should not have been trying this hard to optimise the graphical look at this stage. I didn’t really find solutions for it other than suggestions to pick colours where the effect would be less noticeable.

• Cone Collider for the camera tag box:
  • In the current implementation, the camera shoots a rectangular box that can pass through all objects.
    Everything that overlaps with the box will be checked if it is a critter so that it can be tagged (in the jam build, I actually have implemented a hidden catch rate and random number throwing for each photoshoot; the catch rate is set at a number that it never misses though).
  • Originally it's not meant to be a box. I envisioned it to be a cone collider which also shouldn't traverse beyond obstacles. I didn't get it to work when I was following the tutorial steps. Therefore as a placeholder I decided for a less complicated rectangular box, since I know how this one works without looking it up, and I can move on with implementing the next features. 

Changes:

• Changed the jump physics and movement speed:
  • Special thanks to SaceMakesGame to suggest 'Coyote Timer'.  The closely related concept of 'jump buffer' has been added as well.
  • Using AddForce() for jumping (upwards push) instead of manipulating velocity.
  • The goal is to make the jump weightier so an extra downwards AddForce() push is applied when the player is falling again to accelerate it.
  • Character jumps higher (about 3x character height).
  • Character moves faster.

• Moved some physics related actions to FixedUpdate() instead of having everything done in Update().

• Changed the scripts for collision detection & collision settings. 

• Changes the key/button-action controls. 

• Changed the camera implementation. This is under construction as I pushed the build earlier without finishing the feature as how I want to be.
  • It now uses Cinemachine to follow the player instead of always having the camera locking onto the player in the center. There has been articles written about how a camera should behave in a platformer. While having the camera moving with player technically works, the background will constantly move with every movement which is not graphically pleasant. There are easy settings for the Cinemachine to only adjust the camera when you move outside a certain field box. However, with this new update, it brings an issue that it is hard to see the area beneath the player and you can't tell whether it's safe to jump down.
  • Added ‘binocular feature'. This switches to a different camera which you can move around. It has a visibly choppier movement and I do not like how it abruptly jumps back to the previous position when toggling it off.
  • Changed the view zoom-in to be closer to the game because the sprite was in fact off-model in the original jam build.
    • Camera > Lens > Ortho Size : [set it to a smaller value]
  • Conclusion: with the new issues, I have considered to perhaps change the camera implement again. Such as have the zoom be put further, so there is a far bigger field view. In adjacent with this, the screen resolution should be increased or simply allow monitor full screen. Issues like not seeing the platforms well might disappear by themselves.

Additions:

• Walking and Climbing animation for the player character

• Slope Logic : Slopes can be added to the level

• Pause Screen that shows the Controls Manual (which is also shown at the start of the game)