Author: danieltjewett

This past month or so has seen quite a few additions to the game.  The most notable feature was letting the player choose which items they want to barter.  A lot of refactoring had to happen to make being able to choose what to barter work.  Before, only five distinct pause states were allowed — menuing, item, dialog, map and death.  The reason these were distinct was because the player could only be in one at a time, without overlap.  For example, when we pressed start to pause the game to go into menuing, we did so from the game state.  If we wanted to get back to the game, we’d unpause and be back into the game state.  If we were talking, it was because we did so from the game state.

A dilemma started to arise though as we began working on bartering.  So far, there was no need to account for dialog state to menuing state, then back to dialog state.  But now, if the player decided they wanted to choose what to barter, we were not coming from the game state, but rather, from a dialog state.  Because of this new complexity, we needed to rewrite the way pausing was working so that it was using stacks instead of a simple boolean toggle.

With this out of the way, we also need a way to input “how many” of a thing we wanted to barter.  For example, if we have 15 arrows, perhaps we only want to barter 5 of them.  We needed to give the player a way to input this number.  Therefore, we added a simple numeric up/down menu item.  To make it easier for the player, instead of pressing left or right for each decrease/increase of the input, we can simply hold down the direction.  Holding down the direction yields bigger increments / decrements for the input.

Practically Speaking

Enough CS talk.  What does mean for the game?  So far my initial thoughts are that it’s a bit tedious to get the item / weapon we want.  One thing that we didn’t mention yet is though the NPC still chooses randomly what to barter, they remember what they’ve already chosen, so the automatic part seems to be working well and is less tedious.  However, as soon as the player wants to choose, currently, we throw away that data.  To make this less tedious and more fun / playable, if the NPC does not like what the player chose, instead of randomly picking again, the NPC should center its “counter offer” around what the player chose, as well as factoring in what has been denied up to that point.  I think there’s still potential here, but it needs to “just work” in order for it to “feel right”.

Other Notable Features and Fixes in the Past Month

Most of the features / fixes centered around bartering.  However, with the holiday season, we were able to demo the game to a few friends and family members who haven’t seen the game in almost a year!  Therefore, we were able to take some really good notes — many centering around very simple stuff, like, how to play the game!  Therefore, we’ve begun to double down on adding more “tutorialy” things.  Here’s the list:

• Since a lot of the NPCs are placeholder and otherwise, doing nothing, we decided to give them some dialog.  Currently, that dialog is simple “how to play” things, as well as simple to in-depth mechanics of the game.
• There’s now a Dojo that teaches the player simple fighting mechanics.  This is not required for the player, but should be useful for those playing it for the first time.

  

• Whenever a player picks up an item or weapon for the first time, a quick message appears explaining how to use the weapon and showing which button to press.

  

• Many people who have played The Legend of Zelda: A Link to the Past know that Link can jump off cliffs.  The same can be done in Violet.  However, many people who have played the game don’t realize they can do so.  Therefore, when the player gets near a ledge, a simple, non-interrupting pop up appears.

  

• We added WIP doors!  There is no animation for the hero currently, so he just uses the jumping animation.  It’s kind of goofy!
• Though placedholder, and repetitive (meaning we don’t have unique portraits for ALL NPCs), we’ve added some more NPC portraits in the game.  I found while testing bartering for the fifteenth hundred time that we should get a few more portraits in the game.  I simply imported portrait graphics from PlayCraft and ZeNeRIA29.

  

• We’ve added a few more balanced weapons: Rapier, Saber and Dagger.  The Rapier has a little more durability than other balanced weapons.  The Saber has less durability, but is a tad stronger.  The Dagger‘s range is extremely small.  However, a sneak kill in the game for any weapon yields 10x the damage output for a weapon, where a dagger has a 20x multiplier.
• We’ve added a few more bows:  Recurve Bow and Great Bow.  With all bows before, if something was moving, and a bow and arrow (or any projectile, really) was shot, it may miss the target, because the direction was computed based on where the target was at, not where it was going.  Therefore, we are now accounting for that, sort of.  What we mean by that is for a Recurve Bow, it is 90% accurate when shooting at a moving target.  We take the “where it’s going part” and use a .9 multiplayer.  If an enemy is moving really fast, the player may still miss it.  The Standard Bow has a .4 multiplier on it.  These multipliers hopefully gives “uniqueness” to each bow.  If the player is moving while shooting, the multiplier is even less!  It’s best to shoot at a moving target when the hero is standing still.  Oh!  And the Great Bow can shoot three arrows at once!

  

• Lastly, all the Soldier enemies now carry weapons randomly, based on their type.  For example, an OrcBalanced would randomly choose between a Sword, Rapier, Saber and a Dagger.  Not only are there weapons randomized, but now their ranking is relative to the player’s ranking.  For example, if a player is carrying a D rank sword, the OrcBalanced can rank up to D as well.  There is a cap for easier enemies, and less of a cap for harder enemies.  That way, player is not farming high ranked weapons off of easy Soldier enemies.

An idea I have had early on is bartering in a game.  Most games, and even real life, have some kind of currency where one can buy goods and services.  Money is really just a form of agreed upon currency that society has determined.  But in reality, the value of money is just made up.  When someone spends money, one is buying into the value of the good or service, relative to their own wants or needs.  For example, a $300 Nintendo Switch, which I think is “awesome”, is “worthless” to my Grandma; there is no value of a Switch for her.  So if we really think about it, we’re all just bartering goods and services with a standard exchange rate.  Therefore, early on in the game’s development, I thought “what if there was no established currency?  What kind of ‘new’ game mechanics could come out of it?”

In Violet, maybe a player perceives the agile weapons as superior, while another player likes the mechanics of the element rods better.  Instead of the game (e.g. the developer, me) determining what an item or object is worth, we’ll let the player decide.

In all economic systems, all goods and services have some kind of “value”, or mathematically, a number associated with it.  The game will still attach a “perceived value” to each item in the game as a starting point.  But with a bartering system, those you are trading with in the game can fluctuate that value.  Maybe firewood is “more valuable” in the cold mountains, where as “ice cream” is more valuable in the tropical region.  Or perhaps a NPC really likes apples, while another really likes balanced weapons.

We believe this could be an interesting mechanic for two reasons:

1. For those like me, who do not normally talk to NPCs in games, now have a reason to interact with them.  The more you get to know someone, the more you get to know their likes and dislikes.  If a particular NPC has a sword, and you know they love apples, the player can be advantageous and trade their unnecessary apples for a new sword.
2. The “collectathon” element of the game becomes more valuable, because anything could become currency.  The player may stumble upon some junk that may end up being someone else’s treasure.

One drawback is it could be tedious for the player to get goods and services in Violet.  One way we’ve remedied that is by having the NPC automatically go through your inventory and choose what to trade.  Right now it’s at random, but could easily be improved upon by adding some intelligence, such as not rechoosing something the player already rejected, or being biased based on the NPC’s preferences.

The other drawback is that there isn’t that one established collecting item (currency) that players will drive towards.  For example, there isn’t a concept of rewarding the player with “money” because, there is no money.  Getting the “collectathon” element of the game right becomes extremely important.

Right now, bartering is just in a proof-of-concept.  But so far, we really like the direction of where this mechanic is going.  We are excited to see how this feature gets better over time.

Other Notable Features and Fixes in the Past Month

This past month was more of a refactoring and cleaning up TODOs month.  I hadn’t really gone through and cleaned up anything since the beginning of the year, and there were definitely a big list of things needing cleaned up.  However, there was a few new notable features as well.  Here’s the list:

• Abstracted “Menuing” for NPCs, Pause Menu, etc.
  • If we are going to be able to barter, we need to be able to menu.  We abstracted the menuing system from the pause menu and made it is own thing that can be used anywhere.  This means NPCs are now able to respond to input from the player.
• Added “Eat to Full Health”.
  • Instead of rapid fire eating a one heart healing item, we’ve add the ability to “eat to full health”, which allows the user to menu once and eat as many of an item that is needed to be at “full health.”
• Began adding a new area — the intersection between forest and grasslands.
• Added $ to hold text injection for dynamic text for NPCs.
  • For example, the translation file has “Would you like to trade $?” and we can inject dynamic text into the $ placeholder (read “Would you like to trade 10 arrows?”).

• If a soldier enemy continues to get stunned, they will immediately attack hero.
  • This prevents the player from taking complete advantage of a stunned soldier type enemy.  We may abstract this out to only certain soldier type enemies in the future.
• Infinite clouds during paused fixed
  • When you pause a game, you’re not really pausing the game, but rather “deactivating” things.  Apparently, I did not deactivate the controller that generates clouds when paused.  But, we were deactivating the controller that despawns clouds.  Thus, keeping the pause screen on for too long caused resuming the game to be pretty foggy.
• Fire spreads correctly again.
• Temperature with fire was incorrect when there was fire loaded.
  • Even if the player wasn’t near fire, the player was “warmed up” as if they were.
• Many TODOs completed / patched as well as other optimizations.
  • As mentioned, this was a big month of refactoring and clean up.  Hopefully we’ll have better foundation to continue building new features upon.

 

 

The game is not dead!  The radio silence the past few months was not a sign of defeat, but rather, a sign of reevaluating the direction of the game, as well as determining next steps.  Back in May, I decided to meet with an adviser to figure out marketing, as well as getting an overall impression of the game.  After sitting down and writing a vision document, then, having the document get beat up over the course of a couple months, a new and exciting direction for the game was born.

New Updates and Direction

One of the major outcomes from this was deciding on the right resolution.  In an earlier post, we were struggling on finding that right resolution.  We’ve decided on a resolution that will scale well, as well as readjusting the camera’s position for better gameplay experience.  This however means all of the artwork previously done will have to be recreated.  Much of the original art, especially character and enemy art were placeholder anyway, so this is not as drastic as it sounds.

Another new direction for the game was to polish the combat mechanics a bit more.  We revamped the stamina system, as well as introducing a new weapons merging mechanic.  This mechanic will implement a fun collection-to-merging mechanic, as well as streamline the way menuing currently works.

There are also major changes to the story.  We haven’t revealed much of the story so far, but the direction we are taking will make the gameplay and experience more cohesive.  Violets and their purpose have been completely redesigned as evident with the new logo:

There have been lots of other major updates to the game since the last post as well.  Here are some other high level bullet points of those changes:

• Fixed memory leak to maintain 60 FPS
• Tweaks to enemy AI to adjust for smaller viewport
• Update horse movement
• Heat transfer — aka arrows can catch on fire for “fire arrows”
• Revamped the temperature system — fire in cold areas will keep the player warm
• WIP Castle Town
• New NPCs as well as updated AI for NPCs

Kickstarter and the Future

Between the last post and the months leading up to September, whenever I didn’t get work done on the game during the weekends or in the evenings of weekdays, I would become mad at myself wondering why I wasted the time by not working on the game.  When in reality, I just need time in the evenings and weekends to decompress.  Sometimes that is working on the game, and other times it’s not.  If the game became a “chore” or another “job” at this point in time, I would not have the motivation to fight for this project like I want to.  I do eventually want to make this something I do full time, but not by sacrificing myself mentally in the meantime.

With that said, I might be interested in Kickstarter in the future.  However, after crunching the numbers, I may be able to slowly fund the project myself in a few months from now.  This could be paying for an artist part time, among other things.  With the new direction in mind, if I can continue to build out and refine those core features, when the time comes to begin interfacing with an artist and others to make the game come to life, I will be able to give more attention in working with others to make the game the best it can be.  Thus, I think it is wise to continue being patient, and slowly building out concepts and features at a pace that is fun and rewarding, rather than something that feels like “work”.

Conclusion

All of these conclusions didn’t happen overnight, so I apologize for not keeping the blog up-to-date.  I hope to share small, incremental updates monthly with you all moving forward.

If you have been following along, you’ll know that we’ve made tremendous progress over the last 90 days of Violet.  I am thankful for Root for giving me the opportunity to invest my time into this project.  This project that initially started out as a way to recoup from my divorce has now become a work of art that I truly believe in.

The past week has been pretty tame with the amount of new features added.  I’ve mostly been working 80 hour weeks on this project since the start of the leave of absence and simply needed to “catch my breath”.  We’ve also needed to do another round of refactoring.  Since I won’t be in the code as much, I wanted to get much of it tidied up.  That way when I come back to coding, I don’t spend hours scratching my head wondering why something was left with a TODO mark.

Tomorrow is going to be hard for me.  If you haven’t guessed by now, today is the last day of my leave of absence from Root.  I feel very much like a kid going back to school after a long summer vacation.  I am not ready to go back.

What I Have Discovered

What I’ve discovered with my time off is that game development is what I want to be doing full time.  Like every job, not every minute of it is glamorous.  However, the overall common goal of making a game with a small team is something I’ve always wanted to do.  And this was fully realized during these last few months.

I’ve also discovered that I like working for myself.  I don’t think I could do game development if I was told to “build to this spec”.  I love experimenting with ideas and building out systems in such a way where ideas and game play can become integrated in a meaningful and fun way.

I love Root for its flexibility and its culture, but I’ve learned that web development is not what I want to do for the rest of my life.

What’s Next?

Though we have made a lot of progress, the game is hardly near complete.  In the next couple months we’ll probably not add major features, but rather take our existing systems and start plugging art and content into it.  Just in the last couple of weeks we’ve seen a 180 that the game has taken with world building and updated art.  We still have A TON to plug in, and much of that I can mindlessly add after a day of web development.

Also during these next couple months, we will be researching how to market the game so that we can reach everyone who could be interested in this project.  This is because I feel the next logical steps are to get funded using a crowdfunding platform, such as Kickstarter.  In order for this project to truly be successful, and for our ideas to fully blossom, we need to be dedicated on it.  The only way to be dedicated on this is to have a way for the bills to be paid.

We Need YOUR Help

This project will only be successful if YOU help share it with others.  In the next week or so, I am going to be hitting the social media platforms and getting pages/channels/etc. added.  When these are added, please like/follow/share with those you think will be interested in this project.  The more eyes on this, the better chances we have of being successful!

For those who have followed along and have helped contribute, whether with game assets, testing, or simply being supportive, THANK YOU!  We couldn’t do this without your support!

 

 

 

Much of this past week and a half has been devoted to world building and polishing.  We’ve made a lot of progress in the last few months.  However, this update really “puts it all together”.  Below are some screenshots of the current status of the game:

 

I’m going to keep this post short and sweet.  We’ve been world building the last few days.  Here are some screenshots quickly stitched together:

Legends say that when the world was created, Lake Eve, as it’s known by humans, was the starting point of creation.

It’s been quite a few days since the last post.  We’ve done lots of tedious behind-the-scenes work, mostly involving graphic updates.  Here’s a little of what we’ve done:

Updated Weapons

If there was any new real “feature” from this update, it would be changing the weapon mechanic slightly.  One thing I noticed as people were playing the game is most would use the Sword and Shield combo (myself included).  Perhaps this is because the Shield comes naturally with the Sword, but I wanted to find a way to make the Sword less “OP” so that more would be drawn to the Mace and Spear.  When the player was facing up or down, the Sword‘s hit box would span from -90° to 90°.  This would cover quite a bit of area.  We decided to shrink the range to be -45° to 45° — still covering quite a bit of area, and still feeling natural, but losing a little bit of its “edge” in range.  The Mace on the other hand would keep its -90° to 90° hitbox range.  With the Mace‘s power and range, it might make players more willing to use the weapon now.

By doing this, we obviously had to update all the animations for the weapons currently in the game.  When I was getting the initial ideas of the weapon mechanic, I used a “git-er-done” approach, and sort of faked the animations.  Though the animations currently in the game are not final, everything is now connected to the player.  If we would have in the past looked really closely, we would have noticed that most of the animations from the player and the weapon were not actually aligned.  This was most noticeable with the Mace weapon.  Now all of the weapons are properly aligned with the player.

To implement the mechanic, and fixing the “git-er-done” approach, we had to go tediously frame by frame to match them to the player’s animation.  You may have noticed I left out the player facing left or right when describing the Sword earlier.  This is because these range’s hit boxes were really off — mainly due to the drawing perspective.  Thus, we had to add these animations manually as well, which took a bit of time and patience.

Alas, we have a base for all of our weapon animations.  What does this mean?  We can now produce more weapons of the Sword, Spear or Mace type by following a few simple rules.  Of course, this is all still manual, but positioning is now less painful.

So far we’ve added a variety of different weapons.  There is plenty more to come, but I was distracted by other polishing items.  Take a look below:

New Trees

Hannah has been hard at work the last couple weeks adding new graphics.  Here area a few new trees:

WIP Cave

I forgot when I said that the updated weapon mechanic was the only “real” new feature.  We started a cave concept right on the end of the last update and the beginning of this update.

The reason why this is still WIP is because it’s using a mixture of two mechanics — the building mechanic and the layerDepth mechanic of bridges.  Originally, buildings were decided not to have “roofs”.  If one went inside a building, the walls and roofs would simply fade out — there was no collision on them.  However, with a cave, we could technically be able to walk on the tops of them (at least, that’s how I envision them working).  To make this possible, I ported over some of the layerDepth mechanics.  The idea works, but there is quite a bit of polishing to do.  I wanted to wait on polishing because I knew we would be adding…

Infinite Tileable Cliffs

Hannah’s has been a beast with these cliffs!  We added cliffs originally for concept, but we really needed a way for them to be able to stack as tall as we wanted to them to be — so we could not only build hills, but mountainscapes.  These almost finished, but we wanted to share the progress of what we had so far:

Conclusion

With most of the basic landscape assets in place, we are beginning to create a more realistic game world.  It’s really awesome to see all of this art starting to come together!  Stay tuned!

When 10 days go by without a post, you know something is cooking!  Hold on tight — I’m about to drop a ton of new features:

Polishing

Okay, I guess this isn’t really a feature.  But the last 10 days have seen quite a bit of improvements and polishing.  The main reason for this is we’ve had quite a few people play test the game in the past week, and we wanted the experience to be as good as possible.  There are many, many more improvements not listed here — an exhaustive list would be many pages long, and probably quite boring.  Here are a list of notable, exciting (from my perspective) improvements:

Fatal Error Fixes

There have been several game breaking errors that have been occurring.  Most of them I originally thought were because of objects going inside / outside of the loading zones.  However, this wasn’t the case.  They were mostly due to a pointer to instances being destroyed not getting nulled (or in Game Maker, set to noone).  We have one nagging fatal bug left that I cannot for the life of me figure out where it’s coming from.  We’ll eventually squash it though. 🙂

Masking on Weapons

Many objects use invisible masks to represent collisions.  One of these objects were weapons.  Game Maker has a limit in that an animation cannot turn on and off masks for a given sprite animation.  We can specify per frame collisions based on the sprite image itself.  But if pixels exists for a certain frame, the collision will be on those pixels.  Why this matters is, for example, the sword animation should not have collisions on the first two images of the animation, because they are “wind up” frames.

Behind the scenes, we wrote a script that every frame of the animation would check which frame the animation was on and swap the mask for a certain specific separate masking image for each frame.  The code became quite a case statement mess.  Though Game Maker’s turning on / off masks limitation still exists, I found that swapping for a specific separate masking image was redundant as we could simply swap for the actual image in the animation at a given frame.  Though there are still a few case statements, we were able to condense them by saying:

switch (image_index)
{
  case 0:
  case 1:
    mask_index = spr_MaskNone;
    break;

  case 2:
  case 3:
  case 4:
    mask_index = -1; //which means the actual sprite image
    break;
  
  default:
    mask_index = spr_MaskNone;
    break;
}

vs.

switch (image_index)
{
  case 0:
  case 1:
    mask_index = spr_MaskNone;
    break;

  case 2:
    mask_index = spr_SwordMask1;
    break;

  case 3:
    mask_index = spr_SwordMask2;
    break;

  case 4:
    mask_index = spr_SwordMask3;
    break;

  default:
    mask_index = spr_MaskNone;
    break;
}

As we can see, we no longer have to maintain specific images for specific frames.  This will scale much better as well.

Shooting Fixes

When shooting arrows, fire or ice, sometimes where the arrow spawned was a little inaccurate.  This was most noticeable with enemies.  This issue has now been fixed.

The other shooting fix was objects like bushes or rocks were preventing these objects from continuing flight.  This is no longer the case, and seems more natural as these objects are drawn to be “smaller”.

Bottom Buttons Multiple Buttons

One of the new features added is the ability to shield bash (continue reading for more information).  To do a shield bash, the user must press L Trigger plus Xbox B on a classic layout.  Before now, the bottom button tutorial only supported one button.  Now we can supply infinite amount of button combinations (not practical, of course) for the player to learn how to do certain moves / tasks.

Enemies Attacking Outside View

I am not entirely sure when this bug came into the system, but the code to determine whether an enemy can “see” the player was broken.  This code is made up of three overarching checks:

1. Is there a solid wall between the enemy and the hero?
2. Is the hero in the enemy’s field of vision?
3. Is the enemy in the viewport?

The last check was broken.  Somehow the location we were checking for the viewport was always the hero’s location instead of the enemy’s location.  Thus, the hero is always in the viewport and this check would return true.

The side effects of this were that enemies would attack the hero even when the player couldn’t see the enemy.  This was “unfair”.  The other was that hoards of enemies would come attacking the hero — to the point of overwhelming.  An enemy’s vision might be able to see the player, but the player couldn’t “see” the enemy due to the viewport not showing the enemy.  Again, this was “unfair”.  However, this is now resolved! 😀

Alright, onto new features!

Shield Bash

One of my friends since conception of the game has wanted the ability to attack with the shield.  I’ve liked the idea, but wasn’t sure the best way to go about it.  Finally, a year or so later, the ability to shield bash has been implemented.

Shield bashing is meant to be more of a defense of tactic.  If the player can time the attack right, the hero will parry the attack and cause the enemy to stop their attack and be stunned.  However, the player can deal damage with their shield if the shield collides with the enemy.  However, attacking with the shield is slower and will degrade the shield very quickly.

Coming up with this tactic was a very interesting problem to solve for.  Originally we were checking to see if the shield bash object was colliding with the weapon object.  However, as we were play testing this, it didn’t feel right.  I whipped out The Legend of Zelda:  Breath of the Wild to see how they implemented countering.  What I ended up discovering was that to perform a successful parry, the player had to anticipate the attack coming — almost performing the inputs of the parry before the enemy’s attack had happened.

To implement such a tactic, we could no longer perform collision events on the attacking weapon and the shield bash object, since the attack and input was not in “anticipation”, but rather as it was happening, or had happened.  Thus, we had to check if the attack was going to happen to see if a parry was happening.

How do we predict the future?  Magic.

No, just kidding.  In the polishing section of this post where we summarized the masking updates (you didn’t skip that, right? 😉 ), there are a couple frames were collisions are purposely turned off.  What we check for is:

1. An enemy is within the vicinity and is currently holding a weapon.
2. If the above is true, we check to see if the above weapon is in the initial part of the animation.
3. If the above is true, and we are shield bashing, a parry can be performed.

There’s enough frames before the attack happens, that this feels “right”.  There currently is a “/” above the enemy’s head, so the player knows they are about to attack.  With this knowledge, a player can shield bash at the right time to perform a parry.

Updates to the Soldier AI

Since the hero has the ability to perform a parry, it was decided that the enemies who carry shields should be able to do the same.  This was implemented much like how the dodge counter works in the Updated Enemies and AI section.  If an enemy carries a shield, the more often the player uses their weapon, the more chances the enemy will perform a shield bash themselves.

The other update to the Soldier AI was after a Soldier gets stunned, they have the ability to either perform a dodge or a shield bash.  There is a science to this, but we don’t want to spill all the beans on how it works.  You’ll have to figure it out yourself!

Resolution and Camera

In the post “Audio Controller and More“, it was mentioned that there was an ability to pan the camera.  The more I played with the feature in the game, the more I disliked it.  This was mainly due to trying to play the game with a camera that snapped back — it just didn’t feel right.  However, I thought it was still important to be stealthy in this regard.

The other big problem we were trying to solve for in the last couple weeks was defining the screen resolution of the game.  This is an important thing to nail down as it decides game play, as well as device support.

Pixel art does not scale very well when using multiples other than integers.  For example, we can scale pixel art up by 2x, 3x, etc., but distortion will happen when using non integer values (1.5 for example).  When coming up with the original game play, we were using 1440 x 810 as the resolution.  We knew this was not going to be the final resolution, but kept with this as it was easy to see code with the the game window up (made for easier debugging).

When figuring out resolutions, we started with 960 x 540.  This felt like a good resolution because it could be scaled to 1920 x 1080 since multiplying by 2 is a whole number.  However, since the viewport was shrunk down, the combat felt “claustrophobic” to me.  However, when people were play testing, it didn’t seem to bother them.  I am sure the bug fix with the enemies and the view certainly did help, but something was still missing.

Instead of panning the camera, I thought “what if we could zoom out the camera instead”?  Originally I tied moving the R-Stick up and down to zooming in and out.  However, this seem to conflict when trying to target enemies in lock on mode.  We decided to make pressing in the R-Stick to be a zoom toggle:

As we can see, zooming the camera out “scratches that itch” to be able to see more around the player, giving the stealthy player more area to view.  You may have noticed that we’re using 1280 x 720 instead of 960 x 540.  I felt 1280 x 720 gave the player more view area by default, which made combat feel less daunting.  However, 1280 x 720 is possibly the worse number to chose for our resolution, since a graphics card has to decide what a 1.5 pixel is supposed to be.

One thing we noticed though when scaling our art is that the art Hannah has drawn scales pretty well, even at non integer numbers.  I am not sure what magic is happening there, but I will be doing some pixel art research to figure out why that is.  The hero and enemies do distort, but it is hardly noticeable, especially when viewing from longer distances, such as playing on a TV.  Because of this, I think the game play outweighs the slight distortion one would see when zooming in / out.  Plus, we are using 64 x 64 graphic tileset in most cases, which I believe gives us more leeway in how art scales.

The only other issue we were having was since 1080 is the maximum “zoomed out” resolution, all of our surfaces must be drawn to that scale, since we never know when the player will “zoom out”.  Because of this, I noticed some slow down in the drawing events.  This is something I will keep my eye on, but the issue seems to be better with the 2.2.2.308 Beta Runtime version of Game Maker Studio.

Map Screen

The next WIP feature that we added was a map screen.  There is still a lot to do with this feature as the map that has been present is just the “playground” map.  Pressing Xbox Back or Select will pop up the map screen:

For one, it does not fill the entire screen.  We figured since the real map will be much larger, this will not be a problem.  However, the map WILL BE MUCH LARGER, which means the texture will probably need to be split into several surfaces to be drawn on screen.  This will be an interesting problem to solve for.  The other is we’ll most likely want to be able to zoom in and out of the map, pan, and set “interesting stamps” or waypoints the player can follow.  Right now they yellow dots simply represent where the violets or at, but they can really be anything.  Really, the only thing the map feature does right now is display, and lets the player be able to go to the main “pause” screen and back again without any issues.  Hence, WIP. 🙂

Water Rod

The water rod is the newest item to be added to the game.  It’s the missing link to our “rock, paper, scissors” concept, where fire beats ice, ice beats water, and water beats fire.  The water rod will blast a gush of water into enemies and pushes them back.

The water that comes out of the water rod automatically stuns enemies, as well as pierces shields.  It’s damage dealt is generally not much, but works great as a defensive powerhouse.  It will also put out fires and grow / restore plants that were being burnt from fire.  Finally, in the future, we may even add the ability for the water rod to push blocks or other objects (to potentially solve puzzles).

Bridges / Layers

The final feature that we want to share is the concept of bridges.  In a 2D perspective, we are only given x and y variables for positioning.  Thus, anything above or below the character is faked.  For example, if the hero’s position occupies a position on a bridge, is the character on the bridge, or under the bridge?  It’s a tricky problem to solve for sure!

I spent quite a bit of time thinking and looking at games like The Legend of Zelda, A Link to the Past (LoZ aLttP) to figure out how they “faked it”.  I kept looking at this image to figure out how this was solved.  In the image, there are several spots where there are overpasses Link can travel on.  When examining the image, I noticed the only way to get to the above section of the overpasses was by climbing stairs.  My guess then was in LoZ aLttP, the stairs was used as a flag internally because when moving up or down the stairs, the player loses control as Link goes up or down these stairs.  This flag, we’ll call layerDepth would be set to 1 when going up the stairs, and 0 when going down the stairs.  If Link’s layerDepth is equal to 1, he would be considered on the overpass, thus drawn on top of it, and collisions on the overpass would occur (probably checking if collision and layerDepth == 1).  If Link’s layerDepth is 0, collisions on the overpass would be ignored so that the player could “pass under” the overpass, and thus be drawn underneath.

The layerDepth concept was implemented in a similar way, except we didn’t want to be bound to stairs to set the flag.  Thus, we added a Ramp object — an invisible object before an overpass, or bridge, that increments the hero’s layerDepth.  The way the ramp works is if the player is traveling in a certain direction range towards the bridge (for example, down, we check the direction between 225 – 315), we would increment the layerDepth variable.  If the player is traveling in a certain direction range away from the bridge, we would decrement the layerDepth variable.  Thus, what we get is the hero standing on top of a bridge, because we incremented the layerDepth to be 1.

If we were to continue moving down past the bridge, our layerDepth would be set to 0.  Thus, if we were to jump into the water, the collisions of the bridge would be ignored (since they are checking for collision and layerDepth == 1), and thus, our hero would pass under the bridge.

There are still a few kinks to work out as well as needing to apply this to all other objects because the hero is the only object that works right now.  However, this concept seems to be working well, and theoretically scales beyond layerDepth‘s of 0 and 1 (though not sure how practical going more than two depths actually is).

Conclusion

If you made it through all the way, give yourself a gold star, because that was a lot of information to take in.  I think we are about a week out from beginning to build an actual game.  Stay tuned!

This past week was a bit lighter on new additions.  This was mostly from catching up on tasks related to adulting, as well as the power outage on Tuesday afternoon due to the ice storm.  Nevertheless here’s what’s new:

Forest and Swamp Updates

Two Saturday’s ago we had a team meeting, discussing updates to the story line, listening to new music, and of course discussing updated game play.  One of our discussions was over the current swamp graphics.  We decided that it wasn’t “swampy” enough.  Below is the updated swamp graphics:

We decided to add some more browns and have less greens.  Obviously when other assets are on the screen, such as water, trees, etc., the area will feel even more like a swamp.  The good news is the time spent on old swamp graphics were not in vain, as we are re-purposing that art to be for the forest area now.

Item Dialog, Collectibles and Chests

The majority of the week was spent on adding items and updating weapons.  Currently, the only “items” in the game before this past week was weapons.  We needed a mechanism that all items could handle.  However, not all items behave like weapons.  We needed to insert an Item object at the top of the hierarchy.  Now, Items have two children:  Weapons and Collectibles.  Weapons work the same way as they did before, while Collectibles at the moment are just things the player collects.  Ultimately, there will be a purpose to collecting these collectibles.  But for now, they don’t have any function.  The beauty is now that we have a system in place, it should make adding these functions go very quick.

Since we have our new Item object, we were able to make a Chest object, which can contain treasure (an Item object).  If a treasure is a Collectible object, the treasure can have a quantity associated with it.  For example, an arrow that is not shot is considered to be a collectible.  One might open a chest and find 15 arrows inside.  Wahoo!

When a chest is opened, a new dialog screen pops up, informing the player the name of the item, the stat (damage for weapons, for example), the description, and a picture.  The same dialog screen appears for items being picked up for the first time as well:

Pause Screen

The last major addition to the game this past week was adding a pause screen.  The game actually had a pause screen before, but it was just a placeholder, and was not very functional.  Though the new pause screen is not final, it at least is now usable.

I had the hardest time coming up with an adequate pause screen.  This is not because the programming was difficult — rather — trying to come up with a user interface that has a good user experience.  I studied Breath of the Wild’s pause screen for quite some time and concluded that pause screen was mostly perfect for what they were trying to accomplish.  Here are my reasons:

1. Items, weapons, materials, etc. are put into their own categories or buckets.  These buckets are conveyed in a “mobile-like” tabular approach, where the name of the bucket is shown, as well as the bucket being highlighted (vs the other icons being dimmed).  Buckets with multiple “pages” are represented with a little “mobile-like” circle (not implemented currently).  This idea makes finding and sorting items and weapons quick and easy.
2. Content is on the left and descriptions is on the right.  Since most languages are read left to right, it also makes sense that the buckets (or selections) are on the left, and what it does is on the right.
3. The three main top level menus are controlled separately.  Currently, only “inventory” is built in the screenshot above, so it hasn’t made sense to build the functionality of the top level menus.  But I love the idea that L and R move these top level menus, since they are on the “top” of the controller.

Breath of the Wild’s pause menu is purposely simplistic, and feels like you’re on a mobile device, but the inputs are with a controller instead of gestures.  This is something I will continue to try to capture with our menu, and thus continue to iterate with these ideas in mind.

Conclusion

We are a little over halfway done with February.  These next couple weeks we hope to wrap up the bulk of the main “system” for the game.  From there, we will begin using these assets to start building out the actual game.  Stay tuned!