Quite the Start

Arashi and a kittri

Since the start of 2016 I have been extremely focused on developing Shadowdawn: Genesis. The first priority was of course porting the original engine from the original XNA version to MonoGame so that I no longer faced the risk of deprecated platforms (yes, looking at you Xbox 360 and PS Mobile). I still hope to release the game on PS Vita since MonoGame supports the system, but for now the bare minimum I am aiming for is PC and Steam. Also, since development has basically begun anew on the game, any lingering programming issues such as persisting bugs, un-optimized or impossible to manage code, or missing features has been my priority as I port each section of the game over. It has been rather exciting as I accomplish each goal, finally supporting the following new features:

  • Full featured day/night cycle, with moon phases tracked over roughly a month of time. These settings are script-sensitive, meaning that AI, environmental effects, luck, and even combat statistics can be affected if so desired. NPC schedules and scripted events can also be triggered at specific times.
  • Finally implemented a proper Z-coordinate, so that flight and hovering at accurate positions is possible, as well as jumping. Objects in the world are properly sorted so that Arashi and other actors (such as flying birds) can pass under higher objects, and appear over lower objects. Objects properly stack as well without z-sorting issues.
  • Every actor, player or otherwise, on screen has a character sheet, so they can use equipment that may be unique to them. Drops can be affected by this as well, and Morsett’s rogue and Shion’s stratagem abilities will be changed. This helps to alleviate the backend issue I had coding the game, where the player, the party members, and the monsters/NPCs had three different interfaces that I had to juggle between the engine and map classes.
  • Now allowing the player to change their leader. The original design only allowed for players to play as Arashi with the party members as AI only, but the new code allows for more freedom of control. Arashi is still the only required character and can never be removed from the party (for story reasons), but she can be placed in leader, vanguard, or support positions, each with their own abilities and features, just like the other potential characters.
  • Likewise, also fixed the animation script so that the entire game is more unified. Animations are easier to implement and adjust as more content is added. Enemies are animated now as well.

And here’s the first screenshot since porting it to MonoGame. Note that not all the HUD components have been restored; however, a sun/moon tracker has been added to the upper right (it’s currently 1:30pm in-game, which can now be viewed in the main menu):

Arashi and a kittri
Arashi finds a Kittri hiding in the secret path

About Astrael

A long-time independent game developer that was lucky(?) enough to have grown up with the gaming industry. I am a programmer, a game designer, a concept and pixel artist, a music composer, and a novelist. This has been my dream for as long as I can remember, and I am determined to take advantage of every talent I hope I have to make it happen!

7 thoughts on “Quite the Start

  1. Nice to see how things are coming along!

    Out of curiosity, how were you handling the z-coordinates before compared to now? Using the y-coordinate plus some sort of height modifier? Filmation math (and other isometric approaches)? Something else entirely?

    1. I found my original sorting algorithm from the XNA engine had some backwards logic for the z-sorting algorithm when y-coordinates of objects were exactly equal, and in the old engine still had sorting conflicts (the old z-sort flipping bug that happens on some games). The “depth” of the object also wasn’t being properly included for the moment where the actor sprites passed behind the map objects officially. I didn’t make the math too complex because it has to be able to process several objects at once quickly, but it works!

  2. Aha, I see!

    So how do you handle the conflicts when y-coordinates are exactly equal now?

    1. At that point, it checks the actual z position of the object to see which is displayed on top (while adjusting the displayed y-coordinate accordingly). In the instance where two objects are on top of each other with matching y and z coordinates, it checks width, the thinner object wins. If EVERYTHING matches, then it simply goes by object ID, so that there’s no swapping issues with nothing left to sort. But for the most part, things aren’t going to be evenly matched that often.

  3. Seems like a pretty elegant solution! Good luck with the rest of the restoration!

    Oh and as always, feel free to give me a shout if you find yourself in need of an extra set of hands!

  4. Stop teasing with these wonderful images.

    LEMME PLAY THE DEMO!

    DIE, KITTRI!!!

    1. Almost there, been making some major headway the last two months and I think it’s about time for another update 😉

Comments are closed.