next »

[ThemsAllTook]

The game UI that I've shown here so far has very much been in a prototype state. It's come far enough along by now that it's time to take the step of rebuilding it into something closer to what the finished state will need to be. I've done some careful mapping of the flow of events during a typical play session, and I'm laying out my new UI to minimize friction for what a player is going to want to do. This is going to be a major and highly visible change to the overall presentation of the game, so I'm taking my time to be sure I get it right. Here's a super rough draft of the first screen you'll see in-game:



The idea I have in mind right now is that the landscape background will shift and adapt for different screens as you navigate to them. I'm working in a lot of animations and polish to improve the overall feel of everything. I haven't replaced my old rounded button graphics yet, but those are definitely on the chopping block. I'm happy with the trajectory it's on now, but I still have a lot of work ahead of me.

[Ishi]

Just had a read through the devlog, good work so far! I fear this isn't really my kind of game - I only tend to enjoy very light puzzling and strategy - but I do love the purity / ambition of displaying all information to the player and turning it into a true puzzle game.

The general idea of the spatial layout of the battles and the way the rows determine who you can attack really appeals to me.

There's no way to get stuck. There's no way to grind.
..
If an encounter is insurmountable, you may need to choose a different one and earn more equipment or champions before taking it on.

This gave me a chuckle at first as they seem to contradict one another! But don't worry, I totally get that there's a difference between your game's progress, where the rewards are part of a sort of meta-puzzle, and traditional grinding where you can level up as much as you want through tedious battles.

I was curious whether the rewards for each encounter are also visible before attempting the encounter, as part of providing the player with complete information? I'm a little concerned that, unless it's fairly obvious to the player which encounter should be attempted first (e.g. do Encounter A to get the Fire Sword before fighting the ice monsters in Encounter B) then it could undermine the puzzley nature of the individual encounters, as you may be attempting to figure out a solution to an impossible encounter. On the other hand, this kind of complex-but-essentially-fair puzzle could be just what you're going for.

I just want to say that this game is insanely cool! After watching a couple of videos, I realized the gameplay is much more interesting than I thought!

(Hopefully that doesn't come off as insulting)

Thanks! I totally get what you're saying - it's actually really useful feedback to know that I haven't quite nailed the presentation of my first impression yet. Definitely going to keep working on that.

Thinking about my own first impressions of the game from looking at the screenshots, the game screen doesn't have an obvious focal point to me (just based on the old placeholder UI at least). The diagram of the spatial layout of the battle could be a kind of visual hook to draw my eye to the screen, but currently it comes across as fairly unimportant because it's small and kinda shunted off to the side. Just wanted to mention those thoughts in case it helps you to think about how to approach your continued UI work.

[ThemsAllTook]

Just had a read through the devlog, good work so far! I fear this isn't really my kind of game - I only tend to enjoy very light puzzling and strategy - but I do love the purity / ambition of displaying all information to the player and turning it into a true puzzle game.

The general idea of the spatial layout of the battles and the way the rows determine who you can attack really appeals to me.

Hey, thanks! I'm hoping the campaign mode will be able to fit this niche, even if the puzzle and challenge modes don't - the idea is to make it somewhat open and lenient, since you can bring any tool you can find to any encounter, but we'll see how it works once I manage to get a full campaign built.

I was curious whether the rewards for each encounter are also visible before attempting the encounter, as part of providing the player with complete information? I'm a little concerned that, unless it's fairly obvious to the player which encounter should be attempted first (e.g. do Encounter A to get the Fire Sword before fighting the ice monsters in Encounter B) then it could undermine the puzzley nature of the individual encounters, as you may be attempting to figure out a solution to an impossible encounter. On the other hand, this kind of complex-but-essentially-fair puzzle could be just what you're going for.

Yup, rewards are visible. I'm messing around with the idea of having different options for how much information is shown ahead of time, where it could be anywhere from being able to inspect the final encounter and everything leading up to it the first time you open a scenario, or to have it show you only what you have unlocked and leave the rewards hidden until you clear an encounter. Maybe each scenario could have its own recommended information mode depending on how it's designed, but allow you to change it if you want? Being able to preserve at least some surprise would be a good thing, but I want to keep my commitment to complete information. Still thinking about this.

Thinking about my own first impressions of the game from looking at the screenshots, the game screen doesn't have an obvious focal point to me (just based on the old placeholder UI at least). The diagram of the spatial layout of the battle could be a kind of visual hook to draw my eye to the screen, but currently it comes across as fairly unimportant because it's small and kinda shunted off to the side. Just wanted to mention those thoughts in case it helps you to think about how to approach your continued UI work.

Aha, that's a good way to think about it. Thanks! I'm hoping the new UI will solve a lot of these problems on its own, but I'll definitely keep the idea of a focal point in mind. That seems like a useful insight.

Anyway, here's a devlog video I didn't get around to posting in this thread, showing some UI progress and talking about technicalities of OpenGL graphics:

[ThemsAllTook]

It's been a slow iterative process with lots of back and forth, but my reimagined UI is coming together piece by piece. A big component of the game that I never really had a clear vision for is the map screen. I knew I wanted some sort of spatial layout, showing a hierarchy of encounters where you may need to finish certain puzzles to unlock others, but I hadn't figured out what exactly I wanted that to look like. I've been struggling to actually make all of the little decisions that I need to make for this part of the game to become reality.

Meanwhile, there are still a lot of other things I can work on while I'm finding my way. A discussion in a puzzle game discord server led me to realize that I wanted to track the player's progess in a much more granular and visible way. I've added some icons to show whether a particular encounter or puzzle has been viewed by the player, and whether they've made an attempt at solving it yet. Although there isn't currently an implementation of saving partial solutions, all of the machinery is pretty much in place, so it should be a pretty quick wiring job.



Here's a video where I go over the few things I have to show for the last several weeks of work:

[a-k-]

Is the logo a bitmap or vectorial? It's anti-aliased without MSAA, so I wonder if you handle the outlines like you do the mountains.

[ThemsAllTook]

Bitmap. The anti-aliasing it has now is a result of how Inkscape exports the images for each letter. I'm not 100% satisfied with it, so I may switch to some other drawing method, or do some tweaks to it post-export...seems workable for now, though.

There was a previous game project I worked on where I wanted to use vector graphics for everything, but I never managed to figure out a good way to do it without being a complete nightmare. That's actually part of the reason I chose a fixed resolution for this project, just so I wouldn't have to think about that problem anymore. There are still some vector graphics involved in my pipeline though, so I guess I still have to worry about it on some level!

[ThemsAllTook]

This map screen is fighting me every step of the way, but I'm starting to get somewhere. Here's a peek at how it looks today:



The check marks and blue status lights correspond to the solved and unseen states shown in the list from the previous post. Each square can belong to its own color group, and the plan is to have them unlock based on progress. Clear encounter 1 to gain access to 2 and 3, etc. There can also be multiple map zones with separate backgrounds.

Meanwhile, a story of how what should have been a simple UI animation took me way too long because I kept getting unsatisfactory results:

[ThemsAllTook]

Map screen progress! It's getting there, but I still have a hundred little things to do before it's finished. I've had an unlock system in mind for a while, and I decided that now is the time to actually wire it up.



Each encounter, puzzle, and challenge can have an arbitrary number of prerequisites that must be met before it can be attempted. These can be other encounters, challenges, or inventory items. Interacting with a locked encounter allows you to see what needs to be done to unlock it. I'm not sure what this will look like in a real scenario yet, but now that it's all in and working, I can start building that out and figure out what makes the most sense.

[ThemsAllTook]

I wanted the action of unlocking new puzzles to feel significant, so I spent some extra time getting the animation and sound effect just right for when a player returns to the map screen after clearing something. First, I tried drawing the obvious animation frames for my padlock icon, and playing them back at a constant speed:



This looked pretty limp and sad and I hated it. I tweaked the frame timings to give it some more convincing motion:



Much better! Now it needed a sound effect. Instead of using bfxr to combine some raw waveforms as I'd done for the rest of the sounds in the game, I decided to try recording the sound of opening a real padlock and pitching it down to sound weightier. After some work in an audio editor, I was pretty satisfied with it. Audio tends to make the largest difference for things like this, so once there was a big impactful sound synced up with the animation, everything felt great.

I'm still messing around with menus and buttons and stuff. The map screen I've been focusing my efforts on feels pretty good now, so I'm turning my attention to the encounter setup and battle screens to get them polished up to the same standard. Once this process is done, the game should feel a lot more comfortable in every way.

[ThemsAllTook]

I've implemented a basic save/load system for partial solutions to individual puzzles, so players will be able to experiment without having to erase an almost-working solution. The current working solution is automatically saved to disk every time a change is made, so if anything unexpected happens in the middle of solving, no progress will be lost. Puzzles that have solutions in progress get a special marker on the map screen so you'll always know where you left off.



I've begun reworking the UI downstream from my map screen. I'm paying special attention to the default menu cursor position, with the idea being that at every step of the game, pressing the action button without making any directional inputs will make a reasonable default guess at what you want to do, up to the point where puzzle decisions need to be made. As long as the most commonly used action is the default, things tend to flow nicely. This also makes me think about places where I can reduce the number of button presses if asking the player for a decision is unnecessary at a particular step of the process. I don't want to make the game play itself, but I want to reduce friction as much as possible in places where it doesn't contribute to the core game challenge.

[ThemsAllTook]

Continuing my efforts to reduce unnecessary button presses, I've implemented a priority system for the default menu cursor position when arriving at the map screen. The game makes a reasonable guess at which encounter the player will want to enter by choosing the first best fit from these criteria:

newly unlocked > last seen returning from encounter setup screen > has saved progress > has been seen > is unlocked > is solved

Since creating a save involves assigning it a name, and I didn't have an editable text widget handy to use in my current toolkit, I took a little detour to implement one. This is one of my favorite programming tasks, and there are going to be several other places in this game where text entry will be necessary, so I went all-out and wrote a pretty full-featured text editor. I've done this from scratch a few times before, so I already had a pretty clear idea in mind of how to structure it. There are a few different hierarchical components involved:

• At the bottom level, TextureAtlas is a lookup table of rectangular regions in a bitmap image, allowing an individual glyph (or other graphic) to be drawn to the screen.
  
  
• GLBitmapFont handles UTF-8 strings, and uses them to look up glyphs in TextureAtlas to draw text to the screen. It knows how wide each character is and handles kerning, so it can be used to look up the horizontal position of a character, and vice versa to return a character index at a horizonal position.
  
  
• TextFlow handles multiline text and performs word wrapping, giving a second dimension to GLBitmapFont's position/character lookup.
  
  
• UIEditText performs cursor management and insertion/deletion, using TextFlow for layout. It handles mouse and keyboard events to modify the string or cursor/selection as needed. It also talks to the operating system's clipboard, so copy and paste work as normal.
  
  

Doing this work now benefits not only Foresight Fight, but other current and future projects I'm building using Stem, my game development framework. Every Stem project is a balancing act between writing game-specific code and expanding the underlying framework with new reusable components. I sometimes have to remind myself to stick to game-specific code rather than just expanding my framework forever, but this was a clear case where a reusable solution was more appropriate.

On another topic, I recently bought a new laptop running Ubuntu Linux, which I'm thinking of making my primary computer for daily use. I've been on a MacBook Pro for the entire duration of this project, and macOS has been my default development platform since it's what's usually in front of me. Windows and Linux are both a higher priority though, so it would be better for the game overall if more of my time was spent in those environments. I managed to get all of my code building and running on Ubuntu over the last couple of weeks, though I don't have an implementation of my audio system using Linux-compatible APIs at the moment. Getting sound working on all supported platforms is going to be one of my next priorities. My Windows audio code needs some attention too, since both waveOut and DirectSound have shown unacceptable amounts of latency. I'm going to try using XAudio2 instead and see if that does any better.

[Ishi]

It's been a long time since I wrote custom text box code but I remember it being very satisfying to put together! Yours looks to work very nicely. I appreciate attention to detail like having the cursor remember the horizontal position correctly across lines of different lengths. Also the cursor seems to stop blinking and become solid while typing text which is great

[ThemsAllTook]

Something that's been bothering me for a while was the small size of my battlefield grid. Since it's meant to be the main focal point of the battle screen, I wanted it to stand out a lot more. I doubled the size, changed the perspective a bit and redrew my tiles and champion graphics:



There are still some placeholder graphics in there (the ones in black and white), whose problems became even more visible at double size. I'll need to find some time to replace these soon, but drawing them sure does take a while...

Also shown in that screenshot is a new combat event log. It scrolls, shows everything for the entire battle instead of just the current turn, and allows you to seek to any point in time to see the state of the battle when that event occurred. Still a few tweaks to make, but it's definitely a step in the right direction.

The elements at the top of the screen are the next thing to be replaced, so I'll be working on those next. I'm also in the middle of implementing a battle victory screen that pops up when an encounter is first solved, showing a summary of what happened, any rewards earned, etc. I'm hoping to be able to show all of that soon!

[ThemsAllTook]

My current UI overhaul is drawing to a close. The rows of champion information I used to show on the encounter setup screen have been replaced by this thing, which pops up when you point at any champion on the battlefield:



It shows all of the at-a-glance information that I expect to be relevant: Vital resources, combat actions, and equipment. There's a separate UI for inspecting everything in more detail if you need to know more than what it shows.

I also added a pop-up with a summary of battle results that shows when you win an encounter:



This one is in a much rougher state, and will definitely get a lot more polish down the road. Having a central place to put stuff like rewards earned, points, saved solution name, etc. is pretty nice, though. It also provides a more direct way to advance to the next encounter when the current one is solved.

Looking to the future, I've mapped out the remaining work to get this game to a releasable state, and right now it looks like there's about a year's worth of work remaining. I've asked myself this question a few times now, and each time I've come up with the same answer. I'm hoping that having a more specific roadmap will help me start reeling in that goal, so that I won't get the "one more year" answer if I ask the question again next year. As soon as I replace just one more old bit of UI, it's going to be time to do some real level design, so that I can nail down the parts of my game mechanics that haven't been set in stone yet.

[ThemsAllTook]

I've known from the beginning of this project that I wanted to include a full-featured level editor. Somehow the time seemed right to start building it out. One of the first steps toward this is to be able to manage the scenarios loaded into the game - create, delete, import, export, etc. I've built a new system for doing these things:



Not everything is wired up yet, and all of the changes currently take place only in memory, so you can't actually save anything to disk yet without exporting. Still, most of the basics are there.

I've also added some drop shadows, and redone the last piece of UI that I felt was holding me back. During battle, the current actor and target for each turn step are now shown with a nicer visual representation:



I'm planning to start roughing out the scenario editor over the coming weeks so that I can modify puzzles directly in the game without having to edit raw JSON data and rebuild each time I want to test something. With any luck, this will allow me to more rapidly build new puzzles and nail down the last remaining game mechanics that are up in the air. It only has to be user friendly enough for my own use right now, but eventually I'd like it to be nice enough for everyone to use. I'd love it if there ended up being lots of user-generated content for this game once it's out. I'm building in all of the necessary support for it just in case I'm able to generate enough interest. We'll see!

[ThemsAllTook]

Audio was an area of this game I hadn't put much thought into. I have some basic sfxr sound effects in it right now, and one that involves a recorded sample with some postprocessing. My procedure for doing this postprocessing was manual, platform-specific, and not reliably repeatable, which bothered me enough that I decided to do something about it.

I'm now in the middle of writing my own command-line audio processing utility which I'll be able to integrate into my build process when it's finished, allowing me to only have to put a few tiny synthesizer parameter files and unprocessed raw recordings into version control, with some information specifying how to transform them into the finished audio that goes into the game. Taking full control of this process turns audio production into a lossless procedure - if I need to tweak anything, I won't be stuck reprocessing already-compressed vorbis data or trying to recreate an effect I had made manually. Everything is repeatable and assembled from fundamental building blocks.

Right now, my utility can do all the basic stuff like mix, trim, amplify, up/downsample, generate tones and noise, etc., but certain operations like equalization are a bit more complicated. I'm doing a deep dive into the world of digital signal processing to make sure I fully understand what I need to put this all together. I'm not finding a whole lot of good resources that focus specifically on writing audio processing code, so if I can get a good enough handle on all this, I might feel compelled to write about it for future people trying to follow the same path I'm on. Until then, I have a lot of academic language and equations to parse through before I can really make sense of what I'm doing.

I'm treating this audio processing sidequest as a separate thing from work on the game itself, so while that happens in whatever extra time I can find for it, I'm also working on wiring up my scenario editor code. It's going to take a while before it's really usable. Progress continues to be made every single day, even if not everything is particularly showy.

[ThemsAllTook]

I've spent the last few weeks focused almost entirely on getting my scenario editor up and running. I wrote an analyzer that generates a list of action items for a work-in-progress scenario, pointing out any unfinished aspects that it can detect, serving as sort of an automatically generated interactive to-do list:



Getting the editor itself to work is mostly a matter of wiring up UI to be able to modify every relevant field of the structures that make up a scenario's data. Some of these things are as simple as choosing items from a list in a pop-up menu, but a lot of them require bespoke UI components to be created for them. I had a lot of fun implementing a color picker from scratch. Nothing is saved to disk yet, but for the portions of the editor that I have implemented, I can edit a scenario in memory and see the changes in-game right away.

[droqen]

Hey just letting you know I can't see your linked images at all. Maybe the domain it's hosted on doesn't like external linking? I can open the image fine if I copy the link and paste it into my address bar.

[ThemsAllTook]

Yup, there's definitely something going on with them. My initial investigation tells me that there was a recent change to Chrome that made it no longer load resources over HTTP embedded in a page loaded over HTTPS...but for some reason, on my computer right now, it's showing them to me. Thanks for confirming that it's still an issue! I've been working on getting SSL set up on my server, so hopefully I can switch them all over as soon as that's done and it'll be fixed.

Edit: Should be fixed now, I think? Looks like getting SSL up and running was all it needed. I guess Chrome just automatically redirects http links or something if https is found working. Makes sense.

[ThemsAllTook]

A whole lot of my time has been going into this game lately. There's a lot of technical drudgery to work through that isn't very showy - I rewrote a large portion of my build system to make compiling my code more convenient on every platform I build for, and added an ALSA interface to my audio output library, allowing sound output to finally work on Linux. Just for fun, I'm tinkering with getting this game to run on a Raspberry Pi. It's not all the way there yet, but it should do pretty well once I get the kinks worked out.

In terms of visible game stuff, I made a change to my inventory system that I've been meaning to do for a while. Instead of putting a unique entry in the inventory list for each non-unique item owned, they're now coalesced into a single item with an equipped/owned count displayed:



When changing a champion's equipment, I now show the full list of owned items that can be equipped in that slot, instead of just the currently available ones. Attempting to equip an item that's out of stock brings up a dialog that allows you to unequip it from its current owner without having to back out of the menu you're currently in:



Since I had a list of items that didn't fit onscreen, I finally got around to implementing vertical scrolling in my list view pop-up. The scrollbar probably needs some visual polish, but in terms of functionality, it's all where it needs to be. This was surprisingly easy; only about an hour of work total to get it done:



The productivity rules I've set for myself are helping a lot in plowing through this slow section of the game's development. My chain of work is still unbroken: Every single day, no matter what, I spend at least half an hour of completely focused work on this game. However, I am also finding time for a few small side projects. Having another project in a more exciting phase of its development is actually proving to be helpful in keeping my motivation up to get this one through its current stretch. I think I've found a healthy balance.