Blog

Focusing on getting an early demo out

Hi friends, fans & family!

I realised recently that I was putting way to much time in on details that don’t really matter yet and I was feeling like the project wasn’t moving forward fast enough. I am doing progress no doubt but recently it was the “wrong” kind of progress. My strategy for finishing the game has been to first put all the pieces together and then start polishing like crazy and adding content but lately I’ve been doing far too much polishing and I decided to back off and focus on getting something playable out there. So first of all, let’s loudly declare that I’m aiming to get a VERY EARLY demo out before the year is over. I will most likely upload it to itch.io but perhaps this plan changes. The deadline will not however. I’ll have something out before the year ends dammit!

My newfound focus led me to start work on an actual structure for the game so here’s the stuff I’ve been doing in the last weeks:

LEVEL UP SCREEN

My current intention is to let all characters in a mission gain experience points after each level so the first thing I had to do was to get something in place to show that and set up a simple architecture for it. When characters get more than 100 XP they level up and their XP amount is reset. Characters will most likely gain the same amount of XP per level each but different levels and objectives will grant you differing amounts depending on difficulty etc. The code for this part was fairly straight forward so most of the work was layout & graphics related. Here’s the result of the first iteration:

LEVEL/MISSION SEQUENCE

The way the code was setup I could only present one level and that’s it and I had been waiting for the “perfect” moment to structure things so you can present levels one after the other (only for the demo, there will probably be some strategic choices in-between missions etc later). I was clearly putting it off for a reason. Game started to fall apart on my first attempt and I had to create a lot of code for resetting stuff between levels, saving and creating things. My advice would be to think about this from the onset but I built this based on a tutorial and well… It was just messy. It did end up well at least and I can now create levels at will at any given point.

DIALOGUE STRUCTURE

My first pass with the dialogue was just to mess around and see if I could get something in place but now I wanted to improve this and make something similar to Fire Emblem: characters talking in the beginning and end of the missions and in certain order. I added a dialogue array in the JSON for the level and now it’s all tied to the level. When the level is loaded the dialogue is presented in the correct order. On top of that I added some code so you can speed up the talking and also click to get to the next talking character. Here’s an example:

PROJECT CLEANUP

The whole project has been a mess since the beginning because of what I mentioned earlier about it starting off from following a tutorial so I had files from the tutorials all over and folders that didn’t really belong where they should etc. Worse than that there were a lot of architectural things that I did not really approve of anymore now that I’ve gotten to understand Unity a bit better. A BIG part of the work recently has been to throw away code and restructure stuff to make it fit my plan better and it is MUCH easier for me to do stuff like creating new enemy units for example. It is always important to find a balance when it comes to how much refactoring (code improvement without new features) one wants to do since it takes a lot of time but if done for the correct parts of your code you will be well rewarded in the long run. The trick is to recognise which parts of the code you will be messing around with frequently. Those parts need to be robust and easy to change!

SKILL TREES

I started putting together skill trees for the characters and getting some kind of foundation in place. This part will most likely change a lot between here and release but I needed something for the players to screw around with for this first demo. There won’t be many choices or anything now at first but at least it gives a taste of the much better things to come… 😉

FINISHED PROMO IMAGE

Saving the best for last. The illustration for the game is finally finished! It will be used on the website and on the different store pages etc so it was a very important part of the marketing.

I am super pleased with the result! What do you think?

I have a friend working on the logo and once that is done I will finally be revealing the name of the game! In the meantime I will be updating the website a bit to accommodate both released games and to look a bit better.

Until next time! // Luis

Particle effects and refactoring

Hi friends, fans and family

These last two weeks have been a bit different since my wife has been away most of the time so I’ve had that my daughter for myself. I’ve still managed to maintain a pretty high tempo but my working hours have differed greatly I have not worked as much in the morning and I have worked a bit more during the night. So what have I been up to this time?

Newsletter

I finally have a newsletter up and running where you can keep updated on everything that I’m doing with the game: http://tinyletter.com/sinistersiamese and it’s the best place to get a summary of these blogposts and find out stuff that I don’t necessarily talk about anywhere else 😉 

JSON map import

I finally managed to get JSON working to be able to import maps. It took me a little while to get it working since there were some minor weirdness when using the JSON utility in unity. You need to think a bit about where you place your arrays and how you structure them for unity to actually get it, so it works better if you have a simple structure and if you avoid doing to much nested stuff. Now I have a base to iterate from where I can position the enemies or state that they get a random position and I can also lay out my entire map in JSON. Still have to do some things to control dialogue and other stuff but things will be easy now that I have this in place. My next step with this will be to build some sort of level editor that can actually create the JSON. I might actually write this in swift so I can make an app on my phone or iPad and create maps on the go.

Typewriter effect

So I mentioned that I was going to have dialogue from the game right? In order to get that looking right there are a few things that need to be put in place: a few funny character expressions, nice dialogue and also a typewriter effect that makes each letter or word appear one by one so it looks like the character is talking :D. I made a basic implementation that does this and I’ve also added parameters so I can configure talking speed and put in pauses at the end of a sentences etc.

Particle effects

Man this part was so much fun. I could probably fool around with the particle system for the entirety of the project just to get things looking nice and have cool effects all over the place. It’s really easy to use. You basically just place the particle system somewhere the same way you place a game object and then your fiddle around with parameters. Naturally, the challenge does not lie in messing around with stuff, it’s actually making it look really good and tweaking things takes quite some time and it’s definitely easier if you have some sort of understanding about what it is you’re doing. I managed to put in an effect for when the characters are walking and kicking up dust and I also added an effect for hits. I will definitely put in more 😊.

Prefab refactorization

My project started as an old unity tutorial and now that I’ve learned some stuff I’ve started to realize that the default way of doing some things in unity is not necessarily the best way when it comes to architecture so I’ve been trying to move more and more from the clicky draggy parts in the editor to code that I can easily control and manipulate. One of the things I’m doing is that I’m greatly reducing the amount of prefabs I have because I started with loads of them. Now I am instead using one prefab for units for example and configuring them in code instead which suits me much better. With that said it was not a problem free approach since a lot of things were built upon that foundation and I broke a lot of stuff before I got it to work.

Other

As usual I’ve also killed a lot of bugs and I’ve also been going back-and-forth with my hired illustrator to make sure that the splash screen that we are creating lives up to my vision. Really looking forward to showing you guys that and to revealing the title of the game :D.

Going forward I will be trying to push hard now to actually get a demo working because so far most of the work I’ve been doing has been to lay the foundation on which I can build upon. The base is getting closer and closer to completion so now it’s time for me to actually create content. 

See you again in two weeks! // Luis

AI is not a complete idiot anymore

Hi friends, fans and family!

The results of the last two weeks have been very productive to say the least in spite of a slump in the middle of the period where I was just not feeling it. Making games is not always fun, there are some tasks that are way more boring than others and tutorials are something I never look forward to. You pretty much always have to write very strange code and architecture to hammer it into place and it’s just not close to being my favourite thing to do :P. Anyway, here’s how this period went!

AI improvements

The AI in this game is a bit different from other turn based games. I want to show the player what the AI will do before it actually does it and this AI makes decisions as soon as the player has moved one of his units or performed other actions. Other games make the decisions when the player’s completely done. There are also games in which the units go 1 by 1 instead of getting to move your entire group. In any case, there are some special considerations to make when you’re going to show what the AI does this way. The major thing is that you have to account for where the units WILL stand as well as where they are standing in this particular moment. If a unit decides that it has to move to a forest tile, you have to make sure that the other AI units know about it so they don’t move to the same space. This has been my biggest challenge but one that I’ve ultimately solved. Yeay!

AI is pretty complicated to debug because there’s always a trillion things happening and it’s usually very hard to pinpoint what exactly is going on so I did a couple of things to make my life easier:

  • I made sure to show where enemies are going
  • I made sure to show all the tiles that enemies can walk to
  • I made improvements in the code that generates levels to make sure that I could place enemies exactly where I wanted them instead of randomising their positions

So after letting the issues in my AI persist for quite some time I decided to finally grab the bull by the horns and eliminate all of them! It was hard, gruelling work but the satisfaction of seeing my last known AI bug (and all others that showed up when I was making fixes :D) was incredibly satisfying 🙂

UNDO button

An undo button for this game is a must so I had to implement it. It’s easy to misclick if you’re not paying attention but more importantly, I want to give players a chance to explore different scenarios. What happens if I move my mage here? Will the archer survive? A very important part of the gameplay is to make sure that the AI is consistent and does not do random stuff just for the sake of it. The AI has to make the same move given a certain board state and the reason for this has to do with player understanding and AI “fairness”. I don’t want the player to go: move, undo, move to the same place, undo again and then get a different outcome. That would just be weird!

4K Graphics XD

I mentioned earlier that I got into a slump in the middle of the week and that was when I started doing the tutorial. I got quite far (not done yet though…) but I was just feeling bored and needed to take my mind off it to get some momentum so I started looking over my graphics in search for things to improve. I’ve already mentioned before that I’m not 100% satisfied with how the game looks and the tiles in particular could need a makeover so I started experimenting a bit. I ended up changing: forests, mountains, roads, the color of the grass and even the color of the goblins. It feels much better now. What do you think?

Overwatch baby!

I’ve always loved the overwatch ability in XCOM. You basically postpone your chance to fire and stand on lookout and when the enemy moves into firing range the game goes into this really cool slowmotion sequence and your unit takes the shot. This lets you fire on the enemy turn which is a good way of adding some wrinkles to the players considerations. Is my position good enough for the attack or should I take the shot next turn when the enemy is out in the open?

I really wanted to make my own implementation of this and had made an earlier attempt that failed spectacularly and left my code in a mess. This time would be a bit different since it now works but the code is still a mess XD. Besides being cool it’s also a very good skill from the perspective of truly differentiating the units as they now have much different abilities that don’t play out the same at all. So how does it work in game? Basically the archer picks an area to guard, and the first unit that tries to pass this area will be fired on and STOP it’s movement. I’ve mentioned before that I don’t just want to make damaging abilities so I had to add something more to it to set it apart. Here’s the end result:

There are still some things I could do to make it clearer to the players and improve it a bit but overall I’m very pleased with the results :D. Also, notice the hit effect I’ve added when units are attacked. That wasn’t there before 😛

In the end, these two weeks have been great and I’ve started my search for an illustrator to make the game’s header image. This image will be used on the web, steam pages etc and is a crucial piece of my marketing plans. As soon as that is in place I will release the name of the game and a short playable demo of the game. That’s all for this time!

Thanks for following my project 🙂

// Luis

UI updates, attack animations and more!

Hello friends, fans and family!

It’s been a couple of weeks since my last update so I thought I would share with you what I’ve been doing since. Vacation is officially over which means I’m back to my usual routine of working on the game on early mornings. I’ve made a small adjustment though since I no longer have to commute. I now wake up a 06:00 instead of 05:00 which is better for keeping my sanity :P.

What other changes have I made? Read on…

UI updates

I’ve removed most of the text I had on the UI and made separate panels for the unit, skill and tile sections as well as changing the side that the tile details were displayed on. This way, everything that gets updated frequently is moved to the left side so you don’t have to keep attention on both parts of the screen. I’ve also started messing around with very minimal borders to give the panels a bit more “pop”. The UI is definitely not ready but it’s been much improved. Here’s a screenshot:

Graphical updates & attack frames for the characters

The graphics will be replaced and improved quite frequently since I’m still not 100% satisfied with the looks of the game. The tiles need a lot of sprucing up and I will most likely update the colors a bit since something is a bit off… Haven’t yet figured out what it is though XD. There have been some big improvements made on the characters at least! I’ve started changing the shading to be on the left side instead of right and be more consistent with where the light is coming from. Made the mistake of changing the shading of the enemies too which was not necessary since they are flipped in the opposite direction XD. The biggest change however is that I’ve added some expressions and attack frames to the characters that makes everything a lot better! Previously all the animations were just bump to attack but now you can clearly see the units preparing for an attack and then 1 frame for performing the action. Why just 1 frame? Well, let’s just say that animation is BY FAR what takes the most time out of everything that I’m doing so I’m doing the bare minimum necessary for it not to look like crap :D. If I have time I might add more frames but the are more pressing issues, like making a game for example ;). Anyway, here’s a zoomed in screenshot of what the attacks look like in action:

Updated Unity to an LTS version

Unity is widely known for being a bit… finicky when you update between versions. I’ve read a lot of horror stories about people having to rework stuff because something broke etc so I’ve been holding on to the exact same version for quite some time know. I’ve been waiting for Unity to release what they call an LTS version (Long term support) that are versions that you can safely work with without things constantly breaking or being updated. The LTS versions that were available where old though and since I know my project will go on for at least another year I wanted to have a 2019 or 2020 version before I tooked the plunge and updated. This week I gathered my courage and updated and it went… perfect actually! I had to make a small fix in preferences so that Visual Studio (where I write code) and Unity would cooperate but it wasn’t hard to fix so now I’m cruising on an LTS version and life is good :P.

Other fixes

Here’s a small list of other fixes and improvements:

  • Removed cursor that was only intended for play with a gamepad
  • Started working on a tutorial
  • Registered a domain name for the game’s website. Stay tuned…
  • Restructured my millions of to-do lists to something that makes more sense

Thanks for following the project! See you again in about 2-3 weeks 🙂

// Luis

Still working on the game…

Hi friends, fans and family!

Haven’t posted in a while and I thought I would correct that 😊. The game is still being worked on and I’ve made quite a bit of progress since my last post in February(!)

Instead of trying to remember everything that’s been added since I’ll try to pick out some of the “best” stuff and also talk what the next goal is.

Mission Objectives

I’ve added some code that allows me to setup different missions like for example: reach this point on the map, kill x number of enemies or a specific enemy, survive x turns etc and many more types will be added. I strongly believe that I need a lot of different mission objectives to keep the game “fresh”. There will also be secondary objectives that are not mandatory but will reward you with bonuses of different kinds upon completion.

Technical details

The way I’ve implemented this is I have “Mission” protocol/interface that has various different methods that act like triggers

Here are some examples: UnitReachedTile(unit, tile) and UnitWasKilled(unit) and NextTurn(turn).

The mission also holds a specific map with enemies etc

The Mission class is passed to a BoardManager class that knows when these events happen. The BoardManager then invokes the methods on the mission. So when BoardManager tells the mission that a unit has been killed, the mission code can check if this was the last enemy or if the enemy is a boss or if it was a player unit etc and set the state of the mission accordingly.

Fire & Ice

I’m going for skills that create a lot of emergent gameplay so I try to avoid attacks that only do damage and one of my “rules” when designing is that no skill is allowed to do only 1 thing. Ice for example freezes units so they can’t do anything for 1 turn which sounds pretty standard but…

A frozen unit will prevent fire from spreading and the ice will melt when attacked by fire. So you can freeze one of your own units to protect from a fire attack! The other thing you can do is freeze water to create bridges. If somebody stands on the frozen ice and they get hit with fire… Well the ice will melt and the unit will drown. Fire also spread randomly between tiles which gives the game some dynamism. I’m very pleased with how ice and fire is interacting though more graphical work is required to show it off more clearly.

Here’s some fire:

Technical details:

Lots of if cases 😂. Tiles can hold ice and fire (child gameobjects of the tile) and there is code to detect if something is frozen when hit by fire etc.

Roads

I think having different types of tiles is important in a tactical turnbased game since it makes positioning more “complicated”. The most common way of doing this is to give different tiles different bonuses/penalties: forests have +1 defense while hills increase the range of attacks or something like that (this is in the game already). Another way is by setting a movement cost for different units and tiles. In Fire Emblem for example, units on horseback have a harder time crossing forest tiles. I wanted movement to be impacted somehow but I’ve never been a fan of the “movement cost” approach since I feel it’s too fiddly so I needed to try something a bit different. Enter roads. A unit beginning their turn on a road can move their distance OR move freely on roads until blocked by an enemy. This allows you to move great distances. To mitigate this a bit I added a defensive penalty on roads which makes units on roads very vulnerable to damage. Here’s an example:

Technical details:

My first challenge was to place the appropriate road sprite on the corresponding position. I began by having a specific type for each road tile like “NorthEastRoad” and “NorthSouth” road etc but this quickly became unwieldy since mapdesign was hard and if cases for detecting types of tiles were huge and unreadable and I knew I was going to have to refactor it at some point. I then changed the architecture to work like this: all road tiles have the type “road” but when they are placed I examine all their neighboring tiles, if a road tile has a road above and below it then I know I have to place a “NorthSouthRoad” graphic there. This code was then reused to handle water as well. It’s now super simple to “paint” roads and water since the corresponding graphic is drawn without me having to think about it when designing 🎉.

The other problem was related to pathfinding and allowed tiles in a turn. When a units turn begins I check if it’s on a road tile. If it is I draw paths out from where the unit is standing and only add road tiles to the path until I can’t add anymore. So my “allowed tile movement” contains the normal range + the road tiles from the pathfinding. When a unit wants to move to another road tile I check if its within the unit’s normal range and if it is not I know that the unit wants to do a special road move and I restrict the red path arrows to only follow the road. My normal pathfinding cares about showing the shortest path so I need to restrict it so the unit doesn’t move outside of the road crossing hills, forests etc. The feature needs to be tested some more but it spices up the movement and feels different in a good way.

Graphics

I’ve added some more shading to the units and also changed up the tiles to add some more variety on the maps and make them look a bit better. The graphics are still on the simplistic side and I’m favoring production speed and clarity over “beautiful” graphics, mostly because it’s the only realistic way to actually make and finish the game on my own.

Going forward

There are still a million things to do but my main focus right now is to send something out to my closest friends to let them have first stab on it and iron out some things before I make a “meatier” demo. This demo will most likely be used as an incentive for signing up on an email list that I will be creating shortly.

The other BIG thing is that I need a name for the game before I can start creating store pages on steam and itch. Once I have that I’ll be setting up a website to increase visibility and all of the other stuff you need to do so people know your game exists…

I’ll try to post a bit more often hereafter (aiming for once every two weeks) but you know how it is 😂

Finally, here some actual gameplay to finish up! Thanks for reading 🙏 / Luis

Dev log w6 (3-9 February) 2020

Ran into a lot of problems this week that ate up a lot of time and I had to restructure and understand a lot of small things (that’s the price you pay when you “need” to work fast) so I didn’t get a whole lot done unfortunately but I did learn a lot about how Unity works.

New functionality: 

  • Implemented a new skill for the wizard that raises impassable ice mountains on the tiles adjacent to him. If there are units on those tiles they are frozen. This effectively protects him from incoming damage and can also be used to block of enemy paths to other units. Will probably modify it to be a ranged attack.
  • Implemented a “unit details window” where you can see the portrait, name and hit points of a unit. This will also show any status effects or injuries that the unit might have etc.
  • And also %€#/!. Better luck next week I guess 😛 

wallOfIce

/Luis

Dev log: w5 (27 Jan- 2 February) 2020

Made great progress this week apart from on Sunday where I experimented with stuff that I ended up throwing away…

New functionality: 

  • Added functionality for terrain bonuses and penalties. Hills increase ranged attack distance and damage for example while forests give a defence bonus.
  • Archer can no longer fire on a unit adjacent to it. It is now basically an artillery attack
  • Added a turn label to indicate whether it’s the player or the AI’s turn
  • Hovering over a player unit now shows exactly how much damage it will take when the enemies attack 
  • Added a new symbol that shows that an enemy will move (I don’t indicate where) but that I won’t attack anyone
  • Added mountains. Mountains block paths just like water but also block some types of ranged attacks. Not “artillery” attacks (arrows etc). 
  • Implemented a move indicator. It shows whether the unit has moved but not performed an action, if the turn is completely over or if it hasn’t done anything yet. 
  • Added an END TURN shortcut key

Bugs:

  • Fixed some annoying pathfinding AI bugs where units would stand on top of each other in certain situations
  • Removed a crash on the swingmeter and fixed erroneous damage calculation when the Rogue unit attacked while cloaked
  • Made sure that inputs don’t register when animations are running 

Here’s the weekly gif 🙂

playerUnitPreviewDamage

Dev log: w4 (20-26 January) 2020

Less productive than usual and only got 4 out of 7 days done (wife was sick) but I got some work done on a really cool new mechanic 🙂 

  • Added some panels to the UI to get a feel for the size of the map and the screen and increased the map a bit as a result
  • Fixed some issues with the damage number labels that appear when attacking. They were not following the characters correctly among other things
  • Added a ”swingmeter”. When the player attacks a meter appears which forces you to use  your reactions to maximize damage. Stop the swing in the big yellow zone and the attack does “normal” damage. Stop it in the red zone for “critical” damage. However, aiming for the red zone is risky since missing causes you to do LESS damage than normal. It gives the game a nice “Mario RPG” feel 🙂
  • Made sure that the rogue does more damage when attacking when cloaked

Here’s a gif of the first iteration of the swing meterswingmeter

Dev log: w3 (13-19 January) 2020 and a first look at the game

HI friends, fans and family!

In order to keep you all in the loop and tell you what’s going on with the new game I’ve decided to put up short weekly reports on what I’ve been doing. They won’t be super technical nor extremely detailed (makes it easier for me to actually write them :D) but will hopefully give an idea of where the game is and where it’s heading.

Progress:

  • Changed layout of the game. The playing area will be in the centre and have two UI panels on each side of it. The panels will hold the buttons for special skills, objectives for the current map, unit and tile information etc.  Support for all 16:9 resolutions. Full HD (1920×1080), Nintendo Switch portable resolution…
  • Added unit subclasses. Started specialising the units a bit by giving them special abilities. The Rogue has a cloak ability that lets him/her disappear which make enemies focus elsewhere. If the Rogue attacks while cloaked the attack will do much more damage but the cloak will be lost and put into cool down. The Knight/Paladin has a guard ability that lowers the incoming damage that turn which can be used to bait enemies into attacking the Knight while others attack them from range for example. 
  • Set a foundation for different abilities by adding cool downs and durations and just making them easier to work with.
  • Added handling of multiple abilities. Each unit can now have multiple abilities as well as their “basic attack”. 
  • Simple bug fixes and cosmetic tweaks. Changing the facing of damage labels for etc…

Here’s a gif from the game:

archer_water_splash

See you next week!

// Luis

The embryo of a game

Hi fans, friends and family!

In my last post I mentioned that work has started on a new game and then I left you with a cliffhanger. This was more due to the fact that the game is in the very early stages of development and there’s not much to say yet, than an attempt to trick your mind into getting hooked and eager to come back for more :D.

How the project was chosen

I had three important criteria that I wanted to meet before I took on any new game project:

  • It should be a project that I’m confident that I can pull off technically. Something that caters to my strengths.
  • It should be a game that I would like to play. A game for me.
  • It should be something fun to design which for me means intricate little rules and systems.

Considering all these things and the fact that I’m working with a new tool (Unity) that lets me release the game on various platforms, I have chosen to once again make a turnbased game :). My reasoning being that the risks of using a new tool will be somewhat mitigated by my previous experience with implementing games in this genre.

Gameplay

The main difference this time gameplay wise is that you will control more than one character. Another feature will be some form of management of these characters outside of combat, though time will tell how expansive that part will be as it depends on how much effort we can reasonably put in before growing tired of the whole ordeal :P. Those are the only two things so far that are set in stone. I have some general ideas that I want to try out that I’ll be prototyping for a while and I’ll post here every now and then to keep you updated…

For those of you that want more frequent updates the best way of “staying in the loop” for the moment is to follow on twitter: http://twitter.com/sinistersiamese or to check our facebook page that’s has a copy of the twitter feed. An email list will show up once the game has gotten some real traction.

Next time I’ll tell you a bit about the goals with this project and the general strategy to get the project over the finish line.

//Luis