Author: danieltjewett

Over the past few weeks I’ve been trying to figure out how I can accomplish making a game on my own.  There is a lot that goes into creating a game.  When you consider art, programming, music, and all the other details, it can become overwhelming.  I decided it was in the best interest of the game to begin looking for individuals who could help contribute on this unique journey with me.  Today was an especially exciting day as it was the first time “the team” could all get together and meet each other, share ideas, play some games (Super Smash Brothers Ultimate anyone?) and simply have fun.

It was amazing to see and hear all the new ideas.  We first were able to share feedback of the creation, the Centaur.  The team concluded that though some animation was needed for the anticipation frames, it was challenging and fun to play.  We also talked updated story ideas, and let me tell you — the updated story plot completely “floored” me — this is going to be good stuff!  Next we listened to a few music samples for the game.  Though I am a hard rock guy myself, I was digging the “Accordion Song” with a Cave Story, Mimiga Town vibe to it.  We finally checked out some amazing concept art from old and new ideas alike.

One of the plans for the day was to play through The Legend of Zelda:  A Link to the Past.  To my surprise, no one on the team had ever played this amazing game (seriously though, if you haven’t played, do yourself a favor and play it!).  After booting up my Wii U, I realized I no longer owned a Classic Controller for the Wii Virtual Console because I owned GameCube controllers, which worked on the Wii, but not on the Wii U.  So, I ran over to my parents to pick up the legend. 🙂

I personally haven’t played through the game in a while, and it was great to hear criticism of a game from first time players that sometimes I can be blinded by nostalgia.  My most interesting discussion take away was how a games’ difficulty wasn’t necessarily due to well programmed AI, but rather dropping in a ton of enemies who’s objective was to simply move in your direction.  It is easy in 2019 to be critical of this attack pattern when games that ran on the SNES and similar hardware during that time couldn’t be computing real time paths for hundreds of enemies — so they made due with simple and fast.  Looking back though, this can be frustrating for a player to feel “ambushed” — especially when the method of an enemy’s attack is simply to run into you.

Anyway, I digress.  The original reason for this post is to introduce and praise on my team.  So without further ado:

Hannah Boellner – Artist

Hannah’s been actually helping with art back in May or June of last year.  A couple friends of mine had mentioned how talented of an artist she is.  After “Facebook Stalking” a few of Hannah’s artwork, I decided to ask her if she would be interested in the project.  Though she hadn’t done pixel art before, she was willing to try.  She first started with some concept art of the Violet.  After I was completely impressed with her skill, we decided to try doing a tree in pixel art.  After a few rounds, we nailed down the style and since has continued to impress me day after day with amazing and awesome art.  The thing that impresses me most about Hannah is how she is willing to give anything a try, with 110% effort.  I want to conclude by admittedly waiting WAY too long to publicly give her credit, where credit is rightfully due.  Without Hannah, we would not be as far along as we are today.

Tyler Shipley – Composer

In my early twenties, I started really getting into composing with FL Studio with some pretty solid tracks.  However, compared to the musical genius mind of Tyler, it pales in comparison.  I’ve actually got to know Tyler pretty well in the last couple months.  We both have a love for really good video game music and love listening to it on a regular basis.  Of course, I am listening to metal remixes while Tyler is listening to more relax, ambient soundtracks.  But this contrast is great as we both share thoughts and ideas to make each other better (though, frankly, I just inputting notes into FL Studio while Tyler is flawlessly composing and playing on his digital keyboard).  I feel like we’re scratching the surface of what Tyler is capable of.  So, watch out world — we have an upcoming David Wise on the horizon!

In my first post, I mentioned that I would be taking a leave of absence from Root.  Well, this past week was the official start of that journey.  I’ve been getting into the routine and have made some good progress.  This past week has been about adding a few more enemy types.

The main current enemy type so far has been a Soldier type enemy.  This enemy type, without getting too nerdy, uses logic to find the best path to the target (in most cases, the hero).  It uses the A* algorithm to compute a path, and some “magic” to not feel so stiff.  This enemy has been great, and can even wield single-handed sword and/or shield combo, single-handed spear, two-handed big weapon, and a bow and arrow.

I wanted to add some more unique enemies that are a ton of fun, but much less “smart”, thus being quicker to develop and less CPU intensive because it is not trying to “compute a path” in real time.

The first I named Reveel:

I wanted an enemy type that could “reveal” — appearing and disappearing, much how the Leever works in the original Legend of Zelda game.  Now that the codebase is there, and I can essentially replace this graphic with my own art.  We can add other types of Reveel objects too by creating a child object of the Reveel object.

Next is a Centipede type enemy:

If you have ever played any of the Snake games, the movement of this enemy is very similar to that.  The idea here is every time we deal enough damage to the Centipede, it will lose a piece, until there is nothing left.  This guy isn’t fully built, but enough of him is there to take a screenshot. 😀

Next is the Minotaur:

This guy has quite the story.  As I mentioned, I wanted some less “smart” enemies.  Originally, the Minotaur was that.  But as I began playing against him, he was just too stupid for the attacks I gave him.  I originally gave him a dash attack and a projectile (fire ball) attack.  Though the attacks worked well, his movement and lack of being smart was weird.  I moved on because I wanted to make the ultimate baddie…

Meet the Centaur:

Anyone who’s played the Legend of Zelda: Breath of the Wild knows that the Lynel is one of the meaner enemies in the game.  However, Nintendo didn’t just make the Lynel tough to be cruel.  They created the Lynel to feel a sense of accomplishment when beating it, as well as getting a ton of loot from what they drop when defeated.  I wanted to create an enemy type that was just as tough and rewarding.

I thought about creating a brand new enemy type. However, after thinking for a while, I decided to merge the above Minotaur enemy with the Soldier enemy.  I took what was good with the Minotaur, the attack patterns, and added the path finding ability of the Solider, and got and even more robust Soldier enemy.  Soldiers can now wield weaponry that was already mentioned and also can perform dash and projectiles attacks as well.  The best part is if I wanted to update the current Solider enemies with these new attacks, it is as simple as adding graphics for them.

It’s pretty cool to see something like the original roughly developed Minotaur become an awesome dynamic enemy by taking a few concepts and merging them together!

I wanted to post a few screenshots of some smaller items I have been working on the last month.  First, fire:

Currently the only way to create fire is using a “fire rod”.  Fire cast from a fire rod has a uncontained property, meaning that it can burn things that are burnable, such as brush, trees and stumps.  Fire can spread and catch other burnable objects on fire too!  If set in the right spot, it could cause a forest fire effect.  Fire that is contained (such as in torches) cannot spread.  However, an idea to be built upon is taking an arrow, lighting the tip with fire, and now the arrow has fire that is contained to the arrow, but shot at a burnable object could catch it on fire as well.  Finally, when it rains, fire will be put out.

Next, water:

I spent WAY too much time goofing around with shaders, blend modes and other nonsense. Unfortunately, this is all I have to show for it.  But at least I learned a little bit — I think. 🙂 Water currently has a ripple around the edges, and reflection with objects that are underneath and above.  I currently want to optimize this, because the current approach is pretty expensive.  I also want to put a “shallow end effect” near the edges of the water, basically coloring the graphic with a lighter shade of blue.

Oh!  This screenshot reminded me, we can also shoot arrows off cliffs.  For example, shooting the arrow would go across the pond here.  Before, it would collide immediately into the edge of the cliff, because it is considered a wall object.

Finally, Chickens:

Honestly, this little guy is just a placeholder for an enemy I’ve been working on.  But it did get me thinking — I need to add animals that roam around eventually.  I started creating an Animal object that all Animal’s will inherit from (I just realized I have gone full circle in my programming career now).

Also in this screenshot, you’ll notice the tree is colored differently.  We are now able to do a color palette swap.  This will keep the file size down by not having to recreate a ton of art with different colors, and of course, save time 🙂

That’s all for now.  Thanks for reading!

I was leery to make my second post be a more technical one.  However, it’s been a little over a month since my first post, and I wanted to give an update on what I have been doing.

In my about page, I mentioned that I started building the game in Game Maker Studio (GMS) 1.4.  I did this because of how similar GMS 1.4’s interface was to what I used to use when I was a kid.  When I was first coming up with the initial ideas of the game, I wanted to quickly get my ideas in code, much like how writers gets their thoughts down on paper.  The last thing I wanted to do was learn a new interface while building out game ideas.  Thus, I started making the game originally in GMS 1.4.

I decided about a month ago that it would be a good time to start porting.  For one, my leave of absence is coming up soon.  I figured it would be a good time to start using GMS 2 and learning the new interface.  Secondly, GMS 2’s device support is much better than GMS 1.4.  Being very ambitious, GMS 2 supports the Nintendo Switch — and I would love for Mario to play my game someday.  Finally, there were a few new core features that GMS 2 has that I was really needing.

GMS 2 completely redid the way they handled tiles, and for the better.  Violet the Game is using a tile grid, much like many games in this genre.  Tiles are exactly what they sound like, squares in a game that represent some graphic.  The tile engine in GMS 2 is much faster now, supporting tile maps too.  This is really useful for the game as I can start using tiles for backgrounds, and not take a performance hit, which was happening in GMS 1.4.

Along the lines of tiles, I had created a concept called decor tiles.  Decor tiles are pretty similar to standard tiles, except these tiles can be scaled and animated, unlike traditional tiles that are on a standard grid.  When coming up with the idea of the decor tiles out with GMS 1.4, they were taking a performance hit due to how GMS 1.4 handled tiles.  However, GMS 2 solves this by having what is known as assets, which are graphics with no other interactions.

With the open world, we needed a way to turn these assets on and off.  Computers are pretty fast now compared to what they used to be.  But, loading an entire open world of these assets would surely cause any game to crawl to a screeching halt. The way we solved loading all the assets at once is to break up the entire open world into zones.  We defined a zone as a 960 x 960 pixel grid.  These grids are loaded into the game based on the camera’s position.  We will always load the zone the camera is in, plus a few surrounding zones.  To do this, a zone name can be defined as assets_i_j, where i is the camera’s left position over 960, rounded down, and j is the camera’s top position over 960, rounded down.  For example, if our camera’s position is in location (2000, 1000), i would be 2 and j would be 1.  Thus, we can toggle an asset group called assets_2_1 and turn that layer on.

The final big feature that GMS 2 added was a new concept called layers.  I have mixed feelings about this new function.  On one hand, it solved my problem of these assets as when we say “asset group”, we mean a layer.  It also solves the problem with tiles as that we can have multiple tiles on multiple layers.  I think my biggest issue is how layers work with objects and the rendering order.

To give an illusion of a 3D perspective in a 2D game, objects need to have some kind of depth to them. In GMS 1.4, every object has a depth variable.  Objects drawn at a smaller depth will be drawn closer to the camera versus objects with a higher depth.  An easy way to give this illusion in Game Maker was to set an object’s depth to -y.  Using an inverted y axis (like most game engines do), the farther down an object is in a room, the larger its y variable will be.  If we want that illusion of fake 3D in a 2D game, we can take an object’s y position, which is larger the farther the object is from the origin, and negate the y value, thus, being closer to the camera.

Though we can use a depth variable in GMS 2, the engine prefers to use layers instead.  GMS 2 will not let us mix depths and layers.  In fact, if we assign an object a depth, GMS 2 will automatically create a layer and manage it for us, giving one no access to this said layer.  Depth according to the GMS 2’s manual is slower than using layers.  However, I did not notice a slow down using depths, unless being called every frame by every object.  So, we solved this by only changing the depth variable when an object needed its depth to be changed.

Why is this depth and layer thing a big deal you may ask?

In order to do the 3D illusion with layers, we have to take every object in the layer, and make a list ourselves, sorting by the y value descending.  Then, once sorted, we can draw each object.  I had a couple problems with this approach:

1. Making a list and sorting every frame was CPU intensive.  Sure, I could figure out ways to make a list pre-sorted, but…
2. I had to turn off the default drawing functionality of Game Maker to do this.  To turn off Game Maker’s draw event for an object, we can set a visible flag to false.  To me, setting a core built in variable like this seemed weird and counter productive to the readability of the code later on.
3. By doing this approach, we completely bypass the framework in which Game Maker works for rendering objects, almost side stepping an optimization.

For me, the depth = -y approached seemed like a much better way of handling drawing.  I just wish there was a native way to group objects using the depth = -y approach with layers at the same time.

Those are the main core features that GMS 2 introduced in their latest version of Game Maker that I found useful.  If you stayed with me through this post, then you’re a trooper!  Thanks for reading.

 

As a developer, I thought this placeholder title injected by WordPress was very fitting.  I am deciding to keep it 🙂

So yes, I am a developer.  I have been coding since the 8th grade.  I started out with a little tool called Game Maker.  I’ve always been fascinated with videogames and Game Maker was a great way to learn the fundamentals of programming.

During college, I worked for a small company that made games for freearcade.com.  My most notable game was Wicky Woo in Lavaland.  It was actually an expansion of one of the first games I made in Game Maker.  In another post, I should do an analysis of this game.  But I digress.

After college, I began work for a company called Pixo.  At the time they were creating mobile games with Unity.  Unity was quite a fun program to play around with.  However, I was mostly doing web development for Pixo.  Web development was alright, but I could do that type of work much closer to where I grew up, which is where I wanted to be.  I moved away from my friends and family to take that job, because I wanted to pursue doing my dream, which was making games.

Shortly after Pixo, I found a company called Root, which is where I am currently employed doing web development. After a few years of working for Root, I realized that though web development wasn’t the dream thing, that Root’s awesome culture and flexibility was a dream in-and-of-itself.

After working for Root for a few years, I went through a difficult time in my life.  Luckily, The Legend of Zelda: Breath of the Wild had recently come out, so I played the game to near completion (everything but the 900 Korok seeds) to pass the time.  It was quite an amazing game to play through.  I thought to myself, “wouldn’t it be cool to make a game like that?”

One day on the internet, I discovered that Nintendo had built a 2D prototype of Breath of the Wild to concept out new ideas for the Zelda game quickly.  I thought to myself “this would be cool to re-imagine.”  And reading through the comments on similar postings, I was not the only one.

I started tinkering around again in Game Maker with my “Zelda” prototype.  I am a big believer in Miyamoto’s philosophy of building the game around the fundamental mechanic.  Thus, I began working on the combat mechanics for this prototype.  After several iterations with people trying it out, I landed on something that other people seemed to enjoy.  And the best part is that it isn’t even a “game” yet.

So, here we are, October 15, 2018.  What’s the plan?

As I mentioned, I work for an awesome company called Root.  We’ve worked out an arrangement where I will be taking of leave of absence from January 1st through March 31st of 2019. During this time, I am going to be working on this project as a way to heal from my divorce.  Even though it has been over a year since those events happened, I am still wanting to use this project as a way to relieve stress and heal.

I’ve decided to start a blog about the experience for two reasons:

1. As a way for me to track in words (rather than code) the progress of the game.
2. As a way for me to share with my friends and others the progress of the game.

I should have started this process sooner — but as they say, “better late than never”. 😀  I am excited to share my continued progress with you!  Thanks for reading.