Ahead of our new dialogue system, I’m beginning the grand UI reskin. This will touch all existing and some completely new UI elements in our game.
Our current UI is not the same resolution as the game’s native resolution (480x270). We’re fixing that during this reskin.
UnitInventory
Dialog Box
Turn Display
Attack Forecast
Battle UI
Action Select
New ones:
Unit Stat View & Unit Level Up
Gear GUI (more on this later)
General Menu UI (options menu, sound, etc.)
Likely more.
Not to mention, those portraits are the picture of excellence.
I’ve got their expressions and squint/closed eye states.
Truly some excellent work being done.
AI update, retreat AI is going well. I’ve had to take a detour and begin our healing system, since we didnt implement Potions or healing spells yet.
I’ve got the system complete with a cool little graphic to go with:
I still need to decide if healing should swap scenes or just occur on the grid map. Most likely, swap scenes.
Tilesets are nearing completion. I haven’t seen them, but I’m confident they’ll be dope. Should have the first set by the end of the month.
There’s been a good amount of work done simply setting up a working framework for our team of programmers. Setting up Git & Github, Trello project management, Discord integration with these services. We’re just about completely on the same page and will be in a position to work quickly without stepping on each others toes.
Today, I received the first batch of tiles for the fort’s interior. Obviously inspired by the first map, but done way better.
Will share the complete map later or next week.
EDIT:
Just so we’re back at square 1. Adding some props to liven things up soon. Well, having them made.
These tilesets cover walls, floors, roofing. Stuff like banners, tables, chairs, beds, etc. will have to be done.
Edit 2:
experimental knight’s mess hall, using tiles that I cannot use. I’ll be making a bunch of these test maps to figure out what tiles we’ll need. In the end map, the tiles will likely be all different. I’m thinking I’ll add more room in the chef’s corner and an unreachable door that implies there’s a kitchen with cooks in the back.
Figured it’d be a fun idea to show the prototype maps then share the finished ones.
There’s so much stuff in progress, I’m tempted to wait. But, let’s go on:
AI is still ongoing. Bruh, doing version control with game development is a shitshow. I tried setting up git for Unity project, and it was a nightmare of merge conflicts and files randomly changed, broken scenes. Spent loads of time debugging that stuff and ended up using Plastic SCM.
To be accurate, the issues were Unity specific. Unity has these files called .meta files that basically act as a map for Unity. Whenever someone pushed on git, these meta files would just go ballistic and mangled. So if I wanted to get those changes, Unity would believe that things changed when they didn’t… this is Git Large File Storage’s fault. That’s pretty much why Plastic SCM got bought by Unity, because git isn’t really too sustainable for it. unless you’re making a mobile game…
My programmers feel me. I was working basically solo or just two of us, so Unity Collaborate was enough. But, I haaaad to open the team up to programmers and doing all this project management and version control stuff has eaten time that could have been spent killing these AI features.
It has not been worth it so far… plus one of them flat out quit lmao. Don’t underestimate the time and expertise needed to program a large scope RPG. I even gave them pretty easy tasks while I solo’d the AI dragon. smh…
/end nerd rant.
So yeah. Plastic SCM is solid though, so we’ll see if they start being productive. One or two of them seem solid, so I hope they can contribute. If not, more revenue (and work) for meeeee! (sorry guys). Lol, in all seriousness, a solid programmer would be great but I can definitely get it done solo. Either way, I want complain.
On that note, I did make some AI progress on Retreat logic and implementing healing. It’s still in rough stages, but all the bones are there:
Basically, they will retreat when hurt then come back for more. Or, run to the nearest Healer (when I implement a Healer, that is :P). I’m going to add logic that compares the combined strength of the allies within sight vs the combined strength of enemies in sight, and assess whether they should flee. This will likely be the starting stages of a Morale system for AI units… possibly for Player Units too.
To throw out a formula for Morale: (Allied Strength - Enemy Strength) + (Within Leadership Influence radius, then 2 + [leadership rank bonus])
This sort of thing exists in FE, where units get stat boosts if they’re within range of Ike and so on. But, I plan to extend it out a bit further… if you’ve ever played Total War Shogun, you are aware of what it is I’m going for.
Anyway — going to polish that stuff off in the coming days. The heal effect is ok, but the opacity is supposed to be animated for a fade in/fade out sort of effect. However, Unity’s particle system is being stubborn and animating that property is turning out to be a goddamn chore. Will clean it up. Plus, the mini health bar isn’t rendering, but it’s probably something simple there.
But, that’s visual stuff which I care a ton about, but I’m glad my AI is getting smarter.
That healing effect will likely only be for when a Healer uses a healing spell on someone. There are more animations, like a “drink potion” animation for the sprites incoming.
Speaking of which:
Art is the real rock star of this mini update. There’s a ton of art incoming, it’s great.
I am setting up our new portraits in preparation of completing our dialogue system. We bought some really nice assets to speed the development of that up and to easily integrate with Articy Draft:
This one a big one. Articy: Draft imports and branching dialogue choices. Integrates with other plugins I’ll end up most likely using like Love:Hate (https://assetstore.unity.com/packages/tools/ai/love-hate-33063). Love/Hate is a really awesome tool, for reasons I will elaborate on when we get there. But basically, say Soren is next to Ike while he one-shots the Black Knight. This would allow for Soren to remember this action and bring it up outside of combat. One example, but it’ll make dialogue with NPCs and player characters much more interesting. Not to mention, it might play nicely with this new AI setup I have going on.
You’d think animating text for stuff like shaking, angry text would be easy… it’s not.
It is my pleasure to bestow on you: blinking.
And Penelope talking:
Good lord, keyframing this is a nightmare and it shows. I’ll clean it up later :’( I’m not an animator, ok lol
I’d show Jacques talking, but I’m totally procrastinating on keyframing it to write this
EDIT:
After losing a few hours trying to animate Penelope… I found out there’s an issue with her mouth expressions when trying to do talking animations more advanced than “open/close loops”.
So we’ll fix that then the talking animation will get smoother.
Jacques is all good tho. At least I dont suck at keyframing as much as I thought I did…
Edit 2:
I programmed random blinking intervals. alright, update again in a few days or so.
Jacques’ new map sprite:
Penelope’s new map sprite:
More Portraits and Map Sprites are incoming. And yes, after those, battle sprites by the same artist who made these map sprites and portraits. I know you all hate my 3D models, I hate them too (but they sort of look cool tho).
Working on getting custom props done for our new fort interior tileset:
This is just a minor taste. Within the next week or so, I will have a whole flood of props to really deck out the interiors.
Props take way less time then flat our tilesets, luckily.
Art is catching up to programming in terms of progress, so I’ve gotta put the foot on the gas and get AI, dialogue and non-map exploration done. The programmer who quit was doing that… but I guess I am lol
FINAL EDIT I PROMISE:
So I worked the night shift tonight. Great decision:
I started laying the groundwork for non-combat exploration. Tbh, everything that is NOT AI is easy. For me, at least lol.
I got collision detection wired up for my levels now. The only issue here is walking BEHIND things… like the castle or those trees.
For that, I will have to pull some programmer wizardry and tactfully enable/disable colliders when the player enters a certain area:
Sort of like that, but with code. I’d pretty much draw a box on the map and say: when the player enters or leaves this box, do this.
enter: disable tilemap collider, move sorting layer above player, enable different colliders (appear to walk behind the castle)
exit: go back to normal
Doing this will be sort of annoying, but less annoying than manually drawing collision on every level. I might find a smarter solution for this, but this seems to be the only way.
Anyway, with that done, the rest of non-combat exploration is pretty easy. The player movement and all is the easy part. Got some running and jump animations in progress (don’t expect to be able to jump all the time, just at ledges, specific places, think pokemon ledges).
anyway, i’ve shitposted and spammed enough so i’ll cool off for a few days lol. I use this as my unfiltered devlog, the one on TigSource is all professional-like…
anyway, that’s is all for now. probably be back when there’s more to show.
EDIT: Ah, I was advised to open a Steam Wishlist. So, I am currently validating my existence and my company’s existence to Valve, after which I should be able to list on Steam.
Should be done by Friday, the latest.
EDIT 2: You might notice different battle music in the gameplay video. That’s because I was testing out potential new battle theme tracks. I got a lot of random requests to compose for us, so I let them all into Discord. It’s been an interesting time.
it’s sort of cool but, i’m likely to go with something more orchestral and dark, less chiptune and retro. The original battle theme is still #1, but we’ll see if any new track can unseat it.
I’m back to work with my original programmer and he’s killing it! Non-map exploration is basically done. I’m not showing it until we get our run and jump animations though.
Currently working on our dialogue system as well.
Now, other important gameplay will be done while I lose my mind animating 3D models and programming AI (plus managing everybody, but that’s the fun part).
Dude just got started yesterday, he’s a beast. A reliable beast. I am content.
I heard you like WIPs, so I got you a WIP to go with the other WIP:
Not perfect, fixing this today. then plugging in our new enemy archer:
(but with a bow…)
More art:
her sprite:
Have their talking and blinking states. Plus, fixed version of Penelope’s talking frames. Even more animation work, yay /s
UI is going pretty well:
Pretty good stuff. We should be able to port to using this pretty soon. Likely have it plugged in by the middle of next week.
I got some fancy stuff to do our tutorial battle with, by the god pixel artist, cyangmou:
(doing these later, when we have gamepad support)
I have a medieval horse and carriage sprite underway + lots of props incoming, as you know. Those should be great, maybe by next week for props and by tomorrow or Saturday for the horse/carriage.
IN THE BEST NEWS I HEARD ALL WEEK (because I am siiick and tired of rigging and animated 3D models, let me tell you): Battle sprites have begun!!!
Now that all our current players have their sprites and portraits, their battle sprites are up next. It will be costly, but it will be glorious.
Very, very early non-combat movement. The ability to walk behind things is currently kicking my ass. For a visual on what’s happening behind the scenes:
Not to mention, homie’s walk cycle looks awkward as hell. Probably getting him reanimated/resprited. He served his purpose as my prototype dummy.
Anyhow, I’m mainly trying to conquer collision detection related to walking behind things which is a goddamn nightmare in my current system. You can see times when he is running into nothing… I can fix this my changing the tool I use to import my maps from Tiled, but there’s too much important stuff that needs to happen before that (AI, Dialogue, getting run/jump, npc interactions to feel natural). However, we will definitely get collision detection rewired to perfection before our next big alpha.
Haven’t posted this here, but it’s an ingame shot of the battle scene – sprites scaled to match perspective. The original source files has its issues, but the engine is pretty good at compensating lol. Pretty excited for these guys to get animated, though doing everyone’s will take time.
Someone mentioned that the shot looked cramped and it seems like the camera should pan up. I have to agree, so I’ll probably get the artist to work on increasing the height and killing a few lingering perspective issues going on in the background.
The Zenovia sprite I shared earlier was exported at a weird resolution – I got the actual sprite today.
Anyway, still fighting with collision detection but I got some really good advice on how handle this in Tiled’s Discord channel:
I basically have to draw my map a certain way and also draw the points of collision. The end result will look much more complex in parts where there’s overlapping layers… Mapping just got a bit more complicated but it saved me from having to do that annoying thing with the boxes I do in video above.
Working on our dialogue system – our text engine is pretty much ready to go. We got text animations to play for a set duration instead of looping to infinity:
That said, we’re running into a point in development where we have to make a decision…
I mentioned my intentions for the game to have mod support, which comes with lots of extra effort on the programming side. Even right now for dialogues, we’re faced with using an easier pre-built solution that will make things easier for us programmers or use a more flexible solution using JSON or XML files (which can be edited by outside ppl manually or via a modding tool we’d build).
The latter will take longer, but it will make modding a cakewalk. We’d basically be custom building stuff that the pre-built Unity solution does.
Which begs the question:
How important is mod support to you? (though this place is biased lol)
Very Important
I’d like it, but I’ll take it it without it
Not important
0voters
In other news, we’re restyling a few of our map sprites as we have been:
Bringing all our sprites to Exit Fate’s resolution. We need to get both of the artists doing these to share consistent styles but we’ll get there. There’s always shared palettes being made.
I won’t say modding support is absolutely the most important thing you should focus on, but with an engine this promising, it would be a real shame for it not to include modding/custom game support. A damned shame.
Btw, are you taking cues from the Paper Mario dialogue system, with all sorts of text effects?
These were all built in effects from a tool we’re using.
There’s the ability to create custom ones, as well.
this text is going to <shake>Shake</shake>
That sort of thing. You can also do <shake t=5>shaking text</shake> where t is the amount of seconds to shake.
There’s settings that allow you to change certain things like how hard it shakes, for each animation.
I’m most likely going to use these mostly for dramatic effect and occasionally for humor.
About modding, I’m a big supporter of it. I think relying on articy draft is great for things like writing dialogue where you can turn Mass Effect like choices and branching trees into gameplay pretty easily.
I’m not certain that I should require modders to have a license for it though.
It’s a game writing tool and it’s pretty great but it’s not exactly cheap…
The ideal situation is to aim to build a suite of tools like you’d get in FEBuilder or SRPG Studio. Which is really ambitious, making a great game and mod engine at the same time.
The plan is to rely on Tiled as the level editor, but I really want to limit the number of other tools someone needs to learn to be able to make a mod.
It’ll definitely be a Kickstarter stretch goal where if I can hire extra tools programmers to work alongside us on the gameplay, we’d be able to develop features plus the external tools needed to use them outside of Unity.
Even if we don’t reach that stretch goal, I would definitely still aim for a post-launch effort to focus on building those tools and still write most of the features in a way that won’t make it too difficult to do.
I hope we are able to get tools programmers though not too many game programmers with that skillset, tell the Tactile developers to help me lol.
We are pretty close to closing the book on the navigation and collision detection aspects of this one. I conquered walk-behind, finally. The advice from the Tiled Discord paid off, and we’re not using completely hand-drawn (by yours truly) polygon colliders for our collision detection on our map.
It is a bit tedious, but Tiled is really flexible with the tools, like Snap to Grid, etc. that make it a breeze once you get the hang it. The bonus is I don’t have to do the enable/disable stuff nearly as often, and when I do, it’s precise enough that I can choose specific colliders to enable/disable.
Ok let’s do an in-game and in-engine visual:
You’ll also notice – I added a badass new animated door the castle. Had that laying around for a while, because this feature wasn’t ready yet.
You can see the simplistic box colliders from before are gone, and the shapes I drew in Tiled are there instead. This requires that I get creative with the “layers” I’m using, having tiles that get walked behind on designated “Pass Behind” layers that will be rendered above the player. I can give a visual there too:
Pretty simple stuff, once you get used to it. But tedious. Is it better than the complete fuckery I was doing before? Totally.
Does it require a ton of running into things to make sure everything looks ok? Totally.
Last update on Non-Map Exploration: Footsteps
This was pretty interesting to setup – it required me to make some extensions to our Grid System. For those interested (tech talk incoming):
Basically every tile has data associated with it (scroll up, you’ll see the raw JSON for TileConfigurations). Inside that data, you’ll see SurfaceType, that currently only defines what footstep sound to play. The issue I was having is that the Grid would only give me the TileConfiguration for the Tile on the highest render order.
Example: I am walking behind the walls, it’d give me the data for the wall… But we’re not walking on the wall! We’re walking on the dirt tile UNDER the wall.
So, I had to refactor the Grid to give me every TileConfiguration at a certain rendering layer (basically, Unity uses integer [number] based IDs for each “layer” [exactly like Photoshop here], I wanted to get the data for every tile at a certain position based on the layer it’s on).
/end tech talk
So, I did that. This will come in handy when it’s time to add “walk-behind” to battle mode (which you currently can’t do, YET). Most likely, we’ll add a silhouette shader so you can see players and (sighted) enemies who are hidden behind tiles.
Silhouette shader example:
(Probably not using this, I want to, but there’s a limitation that prevents it from being useful to me… so we’'llll have it figure that part out)
That’s all for non-map exploration. Next up in that department is
Jumping at certain points in the map
Transitioning between maps/rooms
UI Redesign (30% Complete)
We just got started this week on this – had some hiccups resolution wise (what else is new). So, instead of tiny 480x270 (game resolution), we’re using 1920x1080 (HD) for our UI resolution.
Why? Because the UI is so sexy, it’s a shame not to use it, that’s why.
This eliminates the possibility of a mobile port (but, who even plays single player RPGs on their phones??), but that’s ok. PC and most likely console is enough for me.
You guys have seem what it looks like – so I’ll only share it once it’s all wired up :]. Though, there’s some cool animations going on in some parts.
Maybe in a week and a half or so – everything will be wired up and I’ll do a quality check before unveiling it.
AI - Group Behavior
This is the big one. It’s just getting started and I literally had to get another programmer to take this stuff on (so there’s about 3 of us atm), because it was such a timesink and our backlog was growing. Dude is the developer of Kingdom Of No One, which is hex-based but still in the SRPG category.
I was able to build a good framework for the AI on an individual level, now is the time to start working on Group behavior and tactics. This is where things get a bit more complicated and we’re in the theory stages juuust starting implementation. Here’s the idea for how AI will work:
There’s an idea of AIGroup’s and a overall AITeamManger (for each non-player controlled phases, Enemy, OtherEnemy`, so on).
Using the above image, there’s the idea of roles for each group that will change as the situation demands:
1. Vanguard/Frontlines
Job: Seek out and Engage the Enemy – Halt their advance towards critical defense points
Example: Say that the door to the fort is a “Seize” point, using FE as an example. The vanguard’s job is to limit your movement and block your path by using formations to block your movement range. Then, engage in combat.
They are the head that drives the advance, everyone else is merely providing support and following where they lead. I didn’t want to do stuff like manually setting “choke points” or manually setting certain units to “defend or attack”, it felt cheap. I wanted every unit to be able to make the decision on an individual or group level.
The issue was: How will the AI know where to go? There’s literally 10,000 tiles in this one map (if not a bit more).
The answer we found sufficient was for the role of seeking and patrolling for the enemies to be left to the front-line. There will be times when they’re stationary until they see incoming enemies and times when they are actively searching (but don’t exactly know where you are until you’re within vision range).
They’re the head of the snake, the other groups are the body that follows, in a nutshell.
2. Flank Defenders
Based on the position of the enemy, other AIGroups will move to defend their “flanks”. In this case in the screenshot above, the flanks are Direction.Left and Direction.Right, because the enemy is approaching from the South.
Basically, this role is to follow the vanguard and camp outside of their move range to guard from anyone trying to go around them or attack from the sides. If the vanguard is decimated, they will become the new vanguard and rush in to fight.
There’s two Flank Defenders per Vanguard Group.
3. Backup
Their role is simple – backup the Flank Defenders and the Vanguard. An excess pool of units that can fulfill either role above as the situation demands.
That’s about it. The AITeamManager will be responsible for deploying and setting these responsibilities. AIUnits will be able to dynamically leave/join these Groups as well and act on their own. Perhaps, there will be “PersonalityTypes” for Units, that will effect the way they make decisions, but for now it’s all hivemind behavior first, then we’ll program the erratic behavior.
A big inspiration for this AI system was Total War’s “Combat AI”:
Dialogue System - On Temporary Hold
As you all saw last week – our text engine is pretty much complete. The future of these features is more:
integrating with a dialogue tool like articy:draft or Twine
Writing dialogue sequences in these tools and automatically creating the data in the engine – drag and droppable into the game
Allowing Mass Effect-like choices and a method to keep track of these decisions
Later On: Probably an integration with Love/Hate, for KOTOR like relationship grades.
It is on hold, because articy:draft’s exporter isn’t playing nicely with our project… We tried debugging it, but it is one of those silent errors… and the code is hidden in a .dll file…
Meaning: we’re screwed lol. I had to contact Articy Support and we’re on a email thread going back and forth. Might be a week or so before we reach a resolution there.
Which brings me to Twine. I really like the feature set of Articy, but Twine is really simple and there’s beauty in that. We could use it for our dialogue system and branching choices – plus it’s free. which means, modders could use it as well.
Still a decision I need to make soon though. Let me ask:
Which dialogue tool should we use for the engine, assuming we have mod support:
Articy: Draft 3
Twine
I don’t care – just make the goddamn game
0voters
That about wraps up technical progress, updates. Aside from tons of minor bugfixes and optimizations that no one will care about, lol.
Art Updates
They continue to do great work, love seeing how this stuff is turning out.
In the non-map exploration video, you saw the new Artur sprite. Here’s a splash of all his animations (when he was at the wrong resolution, but he got fixed):
Our revamped Knight:
We got new “drink potion” animations:
Artist said we was inspired by The Mandalorian, lol. It’s an awesome animation, tbh. 4 frames of awesome. There will be taking off helmet and assorted face version of this guy for the next level, it’ll be great.
Can’t forget about our badass castle door:
Our carriage sprite and new horses are coming along:
I envisioned a multi-horse carriage, but it’ll be a challenge getting that perspective to work with the harness and all. He says he has an idea & I believe him, so we’ll see how that goes. Interior for this one is coming in a week or so.
You might remember the storyline I spoke about with the Skyrim carriage and all – it’s happening.
Then there’s the star of the show:
Our artist on battle sprites is doing an excellent job – even though he partially hates my guts from all the revisions (from which I will be chilling on requesting lol).
These are great – there’s some post-processing magic happening here though:
I personally really like it with those filters on – so I’m keeping it and tweaking on a scene by scene basis.
Work as begun on extending the top of the background, so the camera can pan up some more. New backgrounds from the same artist coming pretty soon as well.
Our map sprites are being remastered to a new style/resolution, as well. Generally speaking, I’ve been trying to get all the artists on board with a universal palette, but that’s not happening lol. At least, not until post KS. For now, we’re trying to agree on universal saturation/illumination levels and strict resolution restrictions on map sprites.
Other updates:
Concept Art coming soon – should be a piece based on our white horse logo
Steam Store Page is a WIP – I got no graphics yet and I might get a bit further with gameplay. Maybe by the time UI redesign is complete.
More Tiles, but you know how long it took to get the ones we have
Props… didnt turn out that well. I mean – they were super cheap (cuz I am), so it’s not a big loss. Also useful as a general reference and as a baseline to surpass. Still searching for the right person to handle those since lots of the artists I worked with before are busy with commissions, whatnot. I have a few leads, though. So, expect some empty levels until I get some grade A props done.
This one is probably the highlight of the set so far:
Hard to hate on good ale.
That’s about it, shoutout to that one dude who followed be on twitter, you da realest. One day I’ll be outta double digits lol (I post here more than I do there – going to kick up marketing out of necessary pretty soon).
EDIT: sorry i was rewatching that AI video — there’s some typos but you know what I mean.
I heard you like mini-updates, so I’m keeping them short:
Technical Progress
Jumping
Pretty much fresh off the presses. We added JumpTriggers to our system. Internally, they look like this:
Since it’s not a platformer and we don’t use gravity, I decided we should use a “parabola” to handle jumping. Typically, if you use gravity, your jumps and stuff will automatically look something like this.
But, since it’s a top down RPG and not a platformer, there’s no “gravity”. So we move based on a pre-drawn path that looks like gravity using Math.
The short one, not the long one that does everything for you at the cost of not know wtf is happening in there, lol.
Anyway, this is still pretty much pre-polish. I might mess around with the artificial gravity I’ve got going so far, but mainly need to:
Add SFX
Maybe add a dust pixel particle effect that spawn upon landing
Might mess with animation speed a little bit, particularly landing animation speed
Anyway, we can jump now. Not all the time, but it’s possible lol
UI Redesign (90% done)
Well, most of the code is still the same here, so transition has been pretty painless. I still have to make a quality check on font sizes and colors, etc., but that’s the easy part.
Also added Trading, though the UI might change a bit:
lil animation action going on
But, this is all pre-quality check, reserve judgment on the minor things like placement, colors, portrait sizing, etc…
AI Group Behavior
Just got off a call with the engineer doing this, and hot damn, I wish I took gifs/video.
I will next time though.
Basically:
We implemented formations & the ability create custom formations
Vanguard role is complete, they will block the Player’s movement range towards points of interest, then start attacking
AIGroup's will move to create Formations dynamically
We still need to:
Get AIGroups to move while keeping formation
Add Flank Defenders & Backup roles
Test Decision Making in situations with 3-5 way battles
Add more AIBehavior's aside from Defense tactics
But, man that stuff was so awesome to see… There’s even a “Formation Builder” where to you can manually click squares and hit “save” then it loads that same formation in the AIGroup. This will be pretty awesome to do, if/when we build modding tools.
I’ll get a gif for you guys soon.
Art Updates
Carriage (pretty much done – carriage interior tiles are next)
The game’s starting scene is inside this carriage, so I’m excited.
Battle Sprites [no where near done, but still awesome. this will take a while]
Probably many of you saw this already:
The original model was smear-less and choppy. My artist wanted to use smears and I was against it at first, but at this frame rate, it made sense, so I let it happen.
Glad I let it happen. And he’s glad he doesn’t need to animate 30+ frames – we’re all winners lol
Got an extended battle scene – battle will pan in from the top, down to the action smoothly (not like here, because I did it manually, but writing the script is easy).
Anyway, these new battle graphics are really something. New background for our interior map is in the works, and more battle sprite animations as well.
It’s the weekend and I’ve been playing Cold Steel 4, since I barely play games these days (aside from “research”)… and I can’t really swindle myself into calling Trails “research” lol.
But, the grind never stops, have some mini-updates:
Setting up our new dialogue UI, it’s looking good. I still need to fix Penelope’s and a few other people’s talking animations, but I got the missing frame that’s key to making these look more fluid. We have a few variants of this speech bubble:
Should be fun to use. Idea is that there’s a max of two people on screen at a time – left and right.
While I’m at it, I sent my project over to the team at Articy Support – since they wanted it to debug their plugin. Might hear back in a few days with good news.
However, another open source dialogue tool has my attention as the best pick for both the team and modders: Ink.
Less features and GUI than Articy, sure. However, it’s simple and to the point – only for writing dialogue and branching narratives (so no object/location databases like you get in articy for creating items and location lore, etc.).
It’s a simple language and has a really great and well-supported Unity integration – looks like a winner to me. I downloaded it yesterday and I’m playing around with it to learn how to use it; it’s been enjoyable thus far.
Dialogue stuff is cramping our backlog (though we have lots of other stuff to do), so I’ll most likely choose Ink as our dialogue tool and we’ll build GUI for building items, etc. with our external modding tools down the line.
Mini update on jumping: DUST!
(had the wrong dust video – tried out a few versions)
Sweet, right?
Still some minor polish to do here, like SFX.
There’s been an unholy amount of testing to our character controller, so much of the progress here is invisible. But, since it’s officially rock solid – we can add walk-behind to our battle and use this fancy new shader:
Which will only appear in battle mode. It will show you the player/allied units that are hidden behind a tile. It will show red enemies ONLY when you have seen them, so you’ll have to be wise when advancing towards places that could be hiding spots.
This will be a fun mechanic, it works the same vice-versa. Meaning, you can hide your units behind tiles and if no enemy has seen you move there, you’re invisible.
And a look at our “Group AI”
It may look simple, but these guys are dynamically building out formations in the middle of the enemy’s movement range towards a goal. In this case, the goal is the castle gates.
We can get AIGroups to build any formation we create in this handy tool one of our engineers made last week:
So, that’s test behavior for the Vanguard – emphasis is on the building and placement of these custom formations and being able to move while keeping them.
Attack is the easy part.
After this, we’re adding our Flank Defenders and Backup roles, Leadership Units and Morale Systems, then fleshing out individual AIBehavior some more.
The next week or two should be awesome in this department.
This is a rare programming only update – art has been showing us up for a while now lol.
There’s always cool stuff in the works there though, we should be seeing it soon.
& Currently working on Map/Room transitions by adding and testing our Fort Interior level as well as some WIP props:
Exploring black outlines here. Some places they work, others they don’t. Still awesome props. This is not at all indicative of our level design, merely assessing how our props mesh with pre-existing tiles.
which I care a ton about, but I’m glad my AI is getting smarter.
but, i’m likely to go with something more orchestral and dark, less chiptune and retro. The original battle theme is still 
not too many game programmers with that skillset, tell the Tactile developers to help me lol.
