Migrating the Blog

Hello all, this will be the first blog post on this site. But technically, I’ve been blogging my progress since maybe early 2016.

This blog will contain all of the past accumulated blogs up until the point.

Here’s a comprehensive list of past blog posts and blog related activities:

I’ve been working on Immortal Doctrine’s basic story and game mechanics. I’m thinking of a hybrid game with Legend of Zelda exploration, Star Ocean combat, and Skyrim Lore…

The documentation is very… very complete.

March 29th 2016
I’ve been running some tests for Immortal Doctrine’s basic components and have come up with a simple way to go about approaching the core mechanics of the game. (Especially the battle system)

I’ve decided 100% that I will be using Unity to make this game. And specifically the Ork Framework.

April 1st 2016
I started with a really simple map including some NPC shopkeepers, treasure chests and some experimental alchemy, cooking, and weapon modification systems.
April 12th 2016
Interesting update on the Square Enix Collective.  So it would appear that the collective exists only as a way to rate submitted game and determine the likelihood that they will be funded. It provides a nice system which allows members to review your game based on concept (and whatever else you can provide).

I was doing some research on crowd funding today. And I’m almost certain that the creation of Mini-Frayla (some kind of demo) is the absolute best way to showcase the game and get proper feedback.

Showing people how sexy the game is on a small scale is important, as with that we can show them how even sexier it would be on a larger scale.

April 12th 2016
Guys it is official! Today marks the day that we now have Unity Pro!  I’m having a meeting with Jesse this Wednesday to talk about how to incorporate the expense.  We talked about the possibility of splitting the cost (total cost is $75). But we’ll be talking about how to go about that on Wednesday and during our next information
April 13th 2016
Small announcement about the story for Mini Frayla. Given inspiration by works like metal gear and final fantasy and how they’ve used their demos/smaller games to set the stage for their larger games-I will be writing the story for Mini Fraya in a way that will tie what happens in the demo directly to the events in the main game.Essentially the demo will end where the main game will begin.

(However players who did not get a chance to see it will not miss anything too crucial to the full game.)

April 20th 2016
Heads up guys! Jesse and I had a meeting in order to estimate potential costs for the game. In regards to the costs for the development of the game itself, we might be looking at  $10,000.  This is based on estimates from what I’ve spent for art already, and predicted costs.
April 20th 2016
I came up with an idea for getting music for ID

We hold a soundtrack contest for I.D. winner gets $1000 or maybe half of what we’d be charged by a professional.

Advertise it to college students

Best sound track wins the prize ( we can reduce it to accommodate 2nd and 3rd

Place winners)

First place earns an offer to join the team.


April 23rd 2016
t looks like, that I might be able to use patreon to find a way to get some good quality art for cheap
April 27th 2016
Some additional updates in regards to the game:1. The game’s initial environment graphics have been replaced with a much nice style that makes the test map look much more like a real area in the game.2. There is now a functional battle system where the player can engage an enemy by touching them, and then return to the main battle scene after the battle is over. 3. The size of all game objects has been increased. In order to better accommodate the map building tool I’ve been using to make new maps (which is way better than the old one I was using)4. Marin’s overworld and battle sprite have been replaced.5. The battle zone looks more like an arena now

Though you will notice, that the monsters and player’s moving around awkwardly.

Currently movement on the X and Y axis hasn’t been configured properly yet.

April 29th 2016
Made the game’s first build to give people some remote idea of what it was (at the time)

Though there’s a battle scene, we don’t have damage or attacks configured yet!  So right now you can only run away from battle

To do so, right now just exit from the bottom right side of the arena

Brandon Responds:

“Don’t press options

Yeah… Make sure you have weapons when you touch the weapon mod chest lolz

A is menu

the buying sound is different for the armor vendor

I shall look more later….”

So basically everything was fcked haha!

3 Month Hiatus/Prep for Quitting Job and Learning Backend Web Development
Quit Job!

Learned backend web development!

Ruby Language!

November 7th
Currently: Battle system begins and ends.You can fight monsters by using base attacks.

You can either :

Fight and win the battle (battle victory)

Run away from the fight and arrive back to the main field (escape battle)

Be defeated and trigger a Game Over

Next up is to test the concept of Magic abilities. Once, that’s done, I’ll be able to easily implement battle skills immediately (Since they will be easier to implement)

After magic and battle skills are done. I’ll make a few different kinds for a single battle character. (Marin)

Then I’m going to polish the attacking and skill mechanics for Marin

Then next up is Move AI

+ Battle AI (but it’s not too bad with the frameworks I have)

November 8th
There was is an indie team I found, that’s using the same framework and engine I’m using to build I.D.

It’s interesting because they went a completely different approach to build his game.

But they ran into a huge problem where they tried to invest in all of the game’s art, before the game itself was complete

So now they’ve spent more than around $14,000 on his game just for art

And now need more.

And the actual mechanical game is nowhere near completion

Since they didn’t properly estimate the budget it seems

But they seem like a decent team. I think they just made mistakes that I would have made had we not started Gluten Free Games so early and made those mistakes earlier in life

(They didn’t realize that the should have made an MVP before going all out on their RPG

November 8th 2016
 I have a: totally-friend-oriented-secret-don’tworryit’sjustafeeling-kind-of-small-crush-pleasedonttellmywife-we’regoingtobeokay/totalfanboyof:    Becca Bair

She’s the one who’s making Arcadian Atlas (or Atlus) the indie FFtactics inspired game

…. Don’t tell my wife

November 8th 2016
Oh and to save on graphics and accurately estimate art costs for battle characters. I used spriters-resource to take all of the character models from the psp version of the first Star Ocean game. It gave me an excellent bearing on how to orient artwork in the game! Eventually I will build the whole demo with free resources and then simply replace the graphics

Oh and all the base character art is allllmost done. We did some revisions for Bastille. I think he’s gonna look pretty dope! The true King of Despair and Bringer of Declivity

November 8th 2016
Update on Skills:So currently ORK does not have the ability to support my originally proposed mechanics for the battle skill/ magic ability system. Originally the plan was this:Casting skills in the game uses a none target related positioning system. Meaning, when you are in battle, you can access the player’s skill menu. Upon doing so, you can select an ability. Upon selecting an ability an AOE marker would be created indicating the range of the ability. At this point, the player could elect to cast the desired ability anywhere within ability range without regard to there being any enemy targets around.The purpose of this system was to force the player to predict where enemies would be standing when on the map instead of directly targeting them.

Doing so would require some calculation and forethought

However, I realized that there were some rather large complications to a system like this…

The benefit would mostly fall on the player, since a player can see where skills will be cast before they are casted. But allowing Enemies to react to spells in the same way, would be very difficult to implement.

The fact that it would be difficult to implement would be one thing. Bu I also think that it wouldn’t be very fun in general

So after some brainstorming, I thought of a better system that would be easier to implement and in general more fun

It goes like this:

1. All abilities have a standard casting distance (range)

2. Abilities will have three distinct styles: Homing, Target Instantiated- Delayed, Target Instantiated – Mounted

Homing – When an ability is casted by the player, it will spawn and then move into the general direction of the target. The AOE of the ability will be utilized and harm any enemies that are within the AOE of the ability when it hits its target

Homing works best for skills like Har (Fire) where the fire ball will rush to the enemy and then on enemy contact will explode. Since the ability will move toward the enemy’s general direction, it will give them an opportunity to “dodge”


Target Instantiated – Delayed – When an ability is casted, the ability will spawn at the location of the targeted enemy.  However, there will be a small window of time before the ability deals damage at the target location. This will give the target the chance to dodge the ability


The above skill will work for a skills like Qwei, (water) where they are more group target focused. The skill will affect any targets within the general location of the selected target.


Target Instantiated – Mounted – When an ability is casted, it will spawn on the targeted enemy itself. Essentially it will be unavoidable.

This works best for spells like healing spells and negative status spells like (poison) where we don’t want mechanical position to affect it.

However, we can add a Hit% on the negative status spells to add some degree of probability


I think having skill archetypes like these will make the game a bit more interesting and ultimately make it easier for me to create more skills at a faster rate.

Har, Hara, Haraga will all have the same exact traits mechanically, but the difference will be the amount of damage they deal and the overall size of the AOE


I will begin by creating a rough version of each ability type. If all goes well, I’ll most likely release a test game in order to have some peeps check it out!

November 9th 2016
Uhhh. Anyway I’ve successfully created ability methods 1 and 2 last night! 3 will be super easy to do (it’s literally… 2 with another thing) And then those will be done

The next thing I’ll need to do is create a system where the skills animations will flip based on which direction the player is facing. (Right now, homing spells face the same direction no mater which direction the player is facing)


Next step will be the creating the 2nd and third levels of the three basic abilities I made. And ensuring that the abilities can be leveled up through either uses, or aquisition of experience (i’m leaning towards experience)


After that will be Automata equipping. I’ll need to include the system that allows the player to access a given ability while equipping the corresponding Automata.

The level of the skill will increase as long as the respective automata is held. (So exp is gained as long as the automata is equipped)

As the skill levels, the automata changes form. (I have a model for each form

November 11th 2016
The automata equipping system was a success! Now the player can equip an Automata and then while having it equipped while fighting, they gain experience!

Before I move on making additional abilities, I need to solve the problem where I need to flip the animations based on player orientation, but after that, I’ll be moving on to combat skills!


So flipping the animations based on player orientation will require some additional work, so I’m going to push it off till later.

I went ahead and moved on to creating my first battle skill… and to great results!

My test character is now capable of:

1. Casting Magic Abilities

2. Casting a Combat Ability

3. Equipping the Har Automata (which currently levels to 2 allowing the use of Hara)

4. Using basic attacks

The last required items for individual player control include:

– Guarding

… and that’s it!

I’ll create one or two more battle abilities for the test character. Then work on the guarding animation and skill (Which shouldn’t take too long)

Once that’s done. The basic battle character will be complete and then I can move on to… *Gulp* the enemies!


A quick note on Combat abilities.

So magic is easier to implement in the game since you can categorize it into 3 major types. It makes it easier to “copy/paste” functionality. Combat abilities are a bit more complex, because no two combat abilites are alike (especially in the “full” version of the game)

Because of this, a different approach/functionality has to be approached with each skill I attempt to allow a character to use.

Knowing this now, I have a much better idea about how my Sprite art will need to be animated in order to work best with my working knowledge of spriting in Unity and Ork

On the other side, since each combat ability requires a different logic and functionality to implement. I’m kinda interested to see how I’ll manage to integrate character’s A.I.s



Implementing Basic A.I. with enemies will occur in two parts/phases

The first is Decision making and second is movement.

In Decision making, I’ll need to create the logic that allows the monsters to make decisions about *when to attack*, *who to attack*, and *with what to attack with*.

Decision making will mostly occur independently of movement.

There will be a defined set of movement A.I’s that all monster’s will be able to choose from. Something like:

– Pursue

– Escape

– Roam

Decisions will first start with a simple breakdown regarding three types:

– Attack

– Obstain

– Heal/Defend(if applicable)

Each move A.I. will be prompted by a decision A.I.

So when desiring to attack, the Pursue movement logic will trigger. But after taking a certain amount of damage, the Escape logic will trigger along with the Heal/Defend logic

Most monsters will have only a few combinations of a limited set of Decision A.I./ Movement A.I. pairs

More dangerous enemies like bosses and special monsters will be given unique A.I. which will be given special conditions and allow them to fight (smarter)

Balancing will be necessary as always


So yeah, Decision A.I. first.  Movement A.I. next.

Ork will support all A.I. Decision logic. Movement A.I. will be handled using a program called Behavior Designer. Used by the same peeps that are making that one other indie RPG game (Which name escapes me at the moment) :

November 13th 2016

I successfully added a new combat ability for the main test character last night. It’s projectile based!

With that done, I will now be moving on to Decision A.I. for monsters

The process will include developing three test monsters. Red Slime, Blue Slime and Green Slime

Red Slime will only use physical attacks when an enemy is in range

Blue Slime will use magic attacks (har)

Green Slime will heal the others slimes (and itself) when their health reaches below 50%

The implementation of these decisions will be relatively simple, however the main challenge that I forsee is Monster Orientation

Orientation as in the direction the monster will be facing.

I need a way to have the monster “face” the target they are currently targeting. Since the game is 2D, this means that they will need to face left or right relative to the current location of their target. Normally flipping a sprite in unity is simple given it’s functionality. But finding a way to have Unity  communicate with Ork might be more difficult. Ork manages the game data, including battles, player/enemy stats, inventory, and even A.I.. But Unity handles object placement, animation, and some degree of targeting. But since Ork uses it’s own A.I. property. I’ll need to find a way to access the monster’s A.I. targeting component, and access the gameobject location of the player in game space, and then slip the entire enemy game object left or right based on the player target’s relative position from the monster

Here we go!

After some research, it seems that the best system for me to use to develop the game’s A.I. properties will be a Unity asset called Node Canvas. Node Canvas is used by the team that makes Cryamore for their A.I.

So I’ll be attempting to use it, by create custom A.I. nodes by interacting with Ork Framework’s API directly

November 18th 2016
I studied A.I. behavior trees and understand how to build A.I. now

At this point. I need to devise a way to make the three frameworks communicate

This will literally be the most difficult portion of the game. But if I can get this part done. Everything else in I.D. will officially be plausible to implement without too much difficulty

The real challenge at that point will be *Polish*

Since polish is how many Indie games get the boot these days :disappointed:

But anyway… (eckemmm)


After studying behavior trees and FSM’s I have organized the A.I. system for the healing slime in I.D.

Muhahahaha! Muhahaha


The only thing I need to do now is study Ork Frameworks API so that I can develop the write script references in order to allow the ability for Node canvas to “understand” what abilities and stats are

As well as understand when to make some decisions over others

November 29th
One quick update:In order to make the ai system work, I’ve had to look at many different ways to integrate the systems.

Basically there are two ways to implement the Move and A.I. battle system. And they both rely on “who is going to take responsibility”

This meaning. We have Ork. Ork manages everything from stats, statuses abilities and so on. Ork is also responsible for handling the damage processing for skills and abilities. Ork relies on Unity in order to create control systems, actually running the game, and leveraging Unities API to make many of Ork frameworks features possible.No when it comes down to A.I. we have three choices

1. We can leave all A.I. implementation to Ork

2. We can create a custom system in raw C# code and add set it to Ork’s Specifications (so that it will be compatible)

3. We can use a third party A.I. software to handle all A.I. needs

The Pros and Cons:


Option 1:

Leaving all A.I. implementation to Ork would be nice and would make things incredibly simple. However the problem is that Ork’s default move A.I. is very simplistic at best. This wouldn’t be a problem as far as an MVP goes, but the major problem is that the default move A.I. system is made for 3D games in mind. (So everything operates on the XZ axis rather than XY axis. Because of this limitation. Using Ork as a default is a no-go :


Option 2: Creating a custom system in raw C# would provide the most flexibility, but with all that flexibility and freedom comes… ultimate flexibility and freedom. You can only create something as great as you *actually* can. And though it’s possible to create an arbitrary system (that’ll get the job done) the problem is future expansion. Luckily Ork Supports custom Move A.I.’s which are integrated into the system so that they can be used on top of it’s Battle A.I.’s. The problem is ensuring that you write your moveAI scripts correctly so that Ork will understand them. This in itself is tricky and still requires research. But it’s the best option of the three so far!


Option 3:

In programming recreating the wheel is usually not a good idea, especially when there are many frameworks out there that already solved the problem that you’ve been trying to solve for what seems like your entire life. This is where 3rd party plugins and extensions come in handy!There are dozens of professional level A.I. tools out there that can allow one to make really robust game logic! The only real down side to them is having to spend time learning yet another framework (which isn’t so bad once you get the hang of it)However, there are some limitations to going this route.Limitation 1 is that most A.I. programs leverage 3D bias over 2D. So there are some adjustments that need to be made (and following tutorials gets a bit tricker when all of the examples are in 3D)The other limitation to this is: Leveraging any Custom system that doesn’t use Ork’s framework directly will need to leverage Ork framework’s API instead. Since these 3rd party programs are so robust, it’s even more difficult to create an A.I. system that fits the bill according to Ork’s wishes. This means that creating a custom move A.I. in ork becomes more challenging. It’s not impossible. But it will slow down workflow significantly and make rapid prototyping an impossibility (within a reasonable time frame)

December 4th
Update: I’m currently in talks with Gaming is Love (GiL a.k.a the guy that made Ork framework)

He’s running the cost for the A.I. custom system and I should hear from him in the next day or so.

I successfully created  second game character. So now, you can switch control between a player and computer controlled ally (minus the computer control)

I’ll be able to better test that aspect once the A.I. system is ready

In the meantime, I’ve been working on additional systems for the game including the Day and Night cycle system and camping system. It pleases me to say that I have successfully implemented

those two systems! And they are working… NICE

So now the game can do time related quests

The game also has a feature where time runs in only certain areas. So that time progesses when exploring the fields and dungeons, yet freezes when inside a town!

At this point, the remaining items I have left are the Quest system (which will be even easier to implement) and the creation of a Dungeon (which I have specific game formula in mind for how I want dungeons to work)

Each of those things will not take much time.

But once, they have been completed, all that’s left will be the remaining details of the  battle system.After all is said and done, I’ll begin to add polish to the game’s current  features (as much as possible with free resources.Then lastly, I will test some final “Extra features” to get a better idea of what kinds of promises I can make content-wise if we do a campaign. Then the Tech Test will be complete! Then we can move on to the development of the Demo!

December 8th 2016
Great news

The Raw Quest System and First town have been constructed!

The first town I created was none-other than the Iconic town of Faraway which houses the legendary HOF guild (Heroes of Frayla) The town is equipped with an INN, Blacksmith/Weapon mod station, Personal Home, Mayor’s office, General Goods store and Alchemy storeYou can now go to the Mayor’s office and pick up the key to the Personal Home. Home’s in I.D. will work similar to how the work in Skyrim. Though the main benefit is that they provide the player a place to sleep other than camping outside and provide other stat benefits!The Inn lets you sleep to any day of the week and wake up in the Morning, Afternoon, or at night

At the HOF guild, you can speak to hero Targus as he will welcome you into the guild and set you on your way to your first quest which will be to kill the Big Slime (don’t rpgs need to have slimes? 🙂

The town responds to the day and night system by changing the color of the sky, but it also freezes time while you’re in the town. You can sleep in beds to progress time though

In addition, there are two quests available in the game now. The first is a HOF Hunt quest called Kill the Big Slime.

And a General Quest called “Please Save My Sister” where a girl named Lily asks you to save her sister after she had been gone for some time in the fields while going out to collect spices for a cake recipe.You later find that  this is a common thing that happens to her, and that it’s due to her rather interesting condition.


With the basic Town and Quest system out of the way, now I move on to creating my First Immortal Doctrine Dungeon.

I will be using the Dungeon Formula I have been working out for some time now that is inspired by Zelda themed strategies. Thanks to unity, I’ll be able to add a nice twist to it though!

January 2nd 2016
Been awhile, but that’s because I got a freak ton of things done!

The game’s first ever Dungeon is Done!

I like its current formula, though it’s empty right now because I don’t have monsters, the boss, treasure, or other items set up yet.

However, the basic formula is complete. You can finish the dungeon from beginning to end. It’s formula reminds me of a combination of Skyrim and Zelda

But it’s definitely unique


Also, I’ve been working with GIL who’s been working really hard on the DAIS A.I. system

Right now, it’s looking really good!

At this point, I can create and assign different A.I.’s for my allies and monsters to use during battle!

I can also assign different rulesets to the main A.I. which allows the player to customize how their allies will fight to excruciating detail if they wish!

Or they can just let the A.I. use the default settings!

Currently phase two of the  system is 99% complete!

Lastly comes phase three which is integrating the Move A.I. with the Decision A.I.

Once that’s done, I’ll be able to dive into the battle system even more in depth


My plan is to release a playable tech demo as soon as the base battle system has been complete.

I’d also like to add some additional monsters and npcs to make the Dungeons and Quests have more substance

Once these things are done, I’ll be ready to show everyone the game’s current progress! At which point, “not including polish” the tech demo will be at roughly more than 60% completion


Oh I also managed to create the game’s following system. So now the party members follow the player and you can speak with them!


Next stage at this point is for me to work on the MVP Resource collection system (for collecting materials for crafting)

I also have some secrets and dungeons that I made that I will integrate into the game


I almost forgot to mention that I drastically expanded the test world from beyond a single map!

I wonder if you guys will be able to still recognize the game? >:D

Today (January 4th)
I completed the basic resource re-spawn system. So now after collecting an item, it will respawn after a specified amount of Game Time (so real time, but calculated based on how long the game has been running)

Right now you can collect some plants!

Next, I’ll add a couple other materials.

Then, I’ll need to work on an issue where they item spawns won’t respond to the “In-Game Time”.

However, once that’s done, I’ll liberally spread the resources throughout the game’s world in attempt to accurately simulate how the player will go about collecting them.


I updated the Treasure Chests so now they open and stay open (like they should). I also added a little feature where if you check an empty treasure chest, the game will choose from a randomly generated HUGELY DEPRESSING message about how you’ve already opened the chest (big grin)

Next direct step is to replace all of the game’s current treasure chests with the new chest system.

Future steps will be to add a chest opening animation that lasts a few frames, but it’s not needed at this moment, so for now Treasure chests are 100% done.


GIL has finished the major portion of the A.I. battle Stratagem system. So now I can create cool A.I.’s for the character’s (And enemies) to use.

You can now also purchase the A.I. items from stores and find them in chests.

As I mentioned before, the final stage of the system is to handle A.I. movement.


After those things. I’m going to put the secrets into the game world and add some treasure to them as well.

At that point, I’ll be working on polishing current features while waiting on the completion of the Move A.i. for the game’s battle system

Author twill14
Categories Uncategorized
Views 1228


No Comments

Leave a Reply