arc-dev-blog

[arc-dev-blog]

Update 5: Command Menu

I recently added a pretty important component of the game, and made my first foray into UI: the command menu! This is the menu that pops up once you order a character to a position, and lets you tell the character what to do. Currently, only “Wait” is implemented, but next up is attacks.

One problem it has right now is that it covers stuff up. I need to write something to make it choose its display position based on its surroundings.

I had to go looking around for fonts to use as well. I’m not fully decided on this font because I’m not even sure yet if the game is going to exist on this resolution scale. Currently it’s 32x32, but I really won’t have any idea whether that’s the right decision until I make some actual character sprites.

My next project is combat and attacks. This is going to be a pretty lengthy and important bit, especially as I haven’t entirely decided how weapons will work. So, if any of you idea guys out there have pitches for unique weapons or systems, feel free to send me them.

[arc-dev-blog]

Update 4: Red tiles

I’ve been getting a lot done this week! I’ve been making a conscious effort to get out of bed before noon so that I can work on the game while I still have willpower. This effort has definitely born fruit. Check this out:

There’s a lot of new stuff happening that’s visible in this picture, but first I’m gonna write about something that isn’t. While I was getting my code reviewed because of the bug last week, one of the people from the Godot discord commented that my code had a lot of parallelisms; two different types of class that were both doing half of the same task. He suggested I make an effort to divide them more cleanly by what exactly each class’ intended function was.

Initially, I thought I’d just keep going anyway because I’m an amateur and it doesn’t matter if my code is bad if it accomplishes what I need it to. Turns out he was actually right as I ran into problems almost instantly and had to spend two days moving code around. I also rewrote most of the arrow code. My code is much better for it now though. All the code that has to do with the character is in character.gd, and likewise for the cursor. There’s a lot less needless interaction between them now, which should make going forward much easier.

Now on to the cool visible stuff. The red tiles displaying the edge of the character’s attack range is new. For each tile the character can move to, it looks at the box of tiles of side length 2*weapon range and checks each square’s distance from the character’s position. The ones that fall within the weapon’s allowable range are marked as attackable tiles, and the attackable tiles that aren’t already marked in red are marked in blue instead.

The other biggest change is the Team system I created. As you can see in the image, the selected character can move through the character south of him, but the one to the east is impassable and marked in red. Character nodes are now stored in folders called Teams, and consider the positions of enemies when calculating movement costs. This was one of the most satisfying things to see work, if only because of how nice it looks graphically.

Having accomplished a lot in the code editor, I also treated myself to a bit of story writing. Planning out each individual chapter is a bit more difficult than I thought, and I’m actually pretty glad I won’t have to be seriously implementing any narrative elements anytime soon. I have a beginning, middle, and end in my head, but connecting each of those points in a way that not only is narratively convincing but is also paced well with gameplay is pretty challenging. I’m looking forward to it, though.

[arc-dev-blog]

The evil is defeated

This bug that was causing the occasional tile to just not render had been looming over my head for months, and I had no idea how to solve it. I sat in the voice channel of the Godot discord for over an hour as people far smarter and kinder than me poured over it and eventually solved it.

Apparently, a variable was randomly getting set to point to one of the tiles, and then getting cleared. There was nowhere in my code that was making the variable do that. If this problem was at sea level, my pay grade would be the Mariana Trench.

Anyway, they solved it by being extra careful with the variables near free() commands. We’re still only 80% sure that this will actually solve it, but we couldn’t reproduce the bug at all after that change.

With school over, I’m excited to get back to work without this bug looming over my head. More posts should follow soon.

[arc-dev-blog]

Update 3: Diagonal arrow movement

Smaller update today. I was having a minor issue with the arrow that was bugging me for a couple days, but I found a cute way to resolve it.

When the arrow is in a position like this and the player wants to move it along the red line, they would encounter problems. There’s a mechanic that stops the cursor when it moves to the edge of a character’s movement range, by checking in each direction individually if the next tile was out of range. This interacted poorly with diagonal movement, and made it so if the player wanted to move the cursor along a diagonal they’d have to move it one by one.

I fixed this by instead of checking each direction individually, at the beginning of the movement loop it makes a vector of the cursor’s current direction of movement, and does the check only once instead. This allows the smooth diagonal motion I wanted, and eliminates the horrible spaghetti solution I was halfway through writing when I had this idea.

Next update: Items and command menu

[arc-dev-blog]

Update 2: Movement arrow, Deselect button

So I’ve had a lot of time to work on my project this past week. It was hard to get into a rhythm at first, but I’m making more steady progress these past few days as I find a routine. Anyway, I’m super proud of this so let’s get right into it.

The big achievement of this update is this arrow! It was absent from the first few FE games, and they do feel a little bit lacking for missing it. I do think it adds a lot to the user experience.

Additionally, the code outlining the tiles the arrow would flow along would have to have been implemented anyway in order to actually give the character a path to move along. I actually didn’t really know a lot about pathfinding algorithms, but when I did read up on them I found that with the way I implemented the highlighted blue tiles, I was already halfway there. Going back from the end point of the arrow to the character was a simple matter of just going backwards along the grid of movement costs, towards the source.

It would have been easy to just use this approach to update the arrow with every step, but the thesis of the arrow as a UI element is to trace a path the user draws for a character to move. For instance, if the user wanted to do a path like this:

The approach just outlined would never allow suboptimal paths like this. Thus, the primary way to draw arrows is to follow the cursor, and then if the path it draws exceeds the character’s maximum movement, use the algorithm to redraw the arrow to that new point.

The final item is another minor aesthetic detail that I nevertheless wanted to get right. My first draft of the algorithm would only produce right-angle paths like this:

This isn’t exactly visually appealing, so I thought for a long time on how exactly to tell the program how many times to bend and where and figuring out how to implement that in a recursive method was a nightmare. Eventually my mom suggested to just do it randomly. I was initially averse to the suggestion, but on a hunch I inspected an actual FE game and found that was also how they did it. I implemented the random solution and ended up with lines like this, exactly how I wanted.

That’s all for this post. There was almost a month between this and the previous one, but with school being entirely online now I’ll have a lot of time to myself, so the next update should be much sooner.

Next update’s goal: character movement and menus

[arc-dev-blog]

Update 1: Beginnings of movement/character selection

Hi all! This is the development blog I’m keeping as I develop my strategy game tentatively called Iphigenia. This project was born equally from my love of the Fire Emblem games and my desire to write a story.

I’m using the Godot engine, because it’s completely free. I’m still a beginner to it but I’m gaining more fluency with each new thing I implement. Speaking of which:

When a character is selected in the game, it has to show you valid places the character can move. These have to be within the character’s movement range, but it isn’t as simple as drawing a diamond on the map with a radius of 5 or whatever; things like walls and trees can get in the way.

I don’t know how other similar games implemented this, so coming up with my own solution was a ton of fun actually. First it makes a grid of integers, and marks the square the character is standing on with a 5 (this character’s maximum movement range). Then it checks the movement cost to move into each adjacent tile against the remaining movement, and if the move is legal, it marks that new tile with the amount of movement the character would have left after moving to that space.

This process continues recursively, spreading around walls and through forests. Impassable spaces like walls or water simply have a movement cost of 99. If the character was able to obtain 99 movement somehow, he could move through it, though the game will likely have easier ways of gaining access to walled-off areas.

One thing I’ve been thinking about while implementing this system is portals. I’ve floated the idea in my head of a spell that links two locations, allowing characters on one space to move to the other normally. This could be done by having the recursive method check with a list of such bridges. Implementing these bridges would require extra code in the part that moves the character’s sprite along the path once the move is selected, though. It would be bad to just have a sprite slide completely over the entire map at walking speed.

Look forward to more posts when there’s more stuff to post about.