Tooltips have been tidied up since that gif was created:

And finally, here’s a look at a Cody targeting some enemies in a test battle

I really need to fix the gaps created by my dodgy window rendering code.

Battle mode is coming along nicely. Characters can be spawned in specific areas, so it’s possible to have the team split into multiple sections. Enemies can be targeted, and land effects and movement are working.

The next step is getting attack animations working, and then there might actually be something approaching a playable battle. Finally!

The above screenshot is from the very first town in the next Shining Online demo. Like other Shining Force games, you start alone and have to recruit a team before you can venture into the wide open world.

All of the above is handled by a little bit of lispy-script:

Shining Online uses a custom lisp engine for scripting, and has an entity + component system for managing in-game objects. Entities can be anything from characters walking around to hidden triggers or spawn zones.

So far this setup is working really well. Entities can have scripts attached to them, and it’s possible to add components to entities via script. I’m not 100% happy with how inspecting works; it’s far too complicated for what it is, but it works so I’m trying to leave it alone.

In development

I’m currently working through milestone 3 – items. At this point it’s mostly UI work that is left. It’s not one of my strong points, but it’s slowly getting there. My aim is to have it all complete by the end of the month so that I can start on shops and the priest.

The main screen for managing items looks like this

I’m not totally happy with the tooltip yet, but it’s pretty close to what I’m aiming for. Giving items to other characters works, but the table needs updating with stat changes. Equipping items and armor is getting a slight revamp, but should be working by the time March rolls around.

I’m looking forward to working on something a little more fun.

But don’t worry, there’s plenty of technical words (and screens) right at the end!

Roaming NPC’s

This is something the original Shining Online never had, but I really wanted them in the game.

The first attempt was not a total success.

After adding some pauses and timing tweaks, the finished result looks like this:

I’m pretty happy with how it turned out.

Custom text boxes

Text boxes can have custom frames, backgrounds and fonts. They can also be positioned anywhere on the screen.

Not very exciting, but at least we know what’s in the tent.

Battle ranges

Towns aren’t the only thing that have had some attention.

Battle ranges are a key part of Shining-style battles, and now they’re in Shining Online. They take land types and movement types into account, so flying entities will ignore trees, whereas centaurs will be slowed down by them.

Finding items and gold

What kind of RPG would this be if you can’t raid people’s homes for their hard-earned cash?

Items work in a similar way, and are automatically passed to the next free character. If there’s no space, it will be left in the container until some room is available.

There’s a fair amount of behind-the-scenes work going on in that screenshot, most of it handled via script:

1. The text for “Cody looking in the barrel” looks like this in the configuration file “%CHARACTER% looked in the %CONTAINER%”. The tokens are replaced by fetching data from the team (the team leader’s name) and the entity being searched (the barrel).
2. Gold is added to the player’s gold reserves
3. Flags are set in the session to make sure searching the same place doesn’t give rewards twice.
4. There’s some other bits going on, like pausing player input, displaying a text box and playing a jingle (which you can’t hear in the gif, but it’s there).

Items are slightly more complicated; the game has to check there is at least one character with an open inventory slot, and then has to either pass it to them or display a “There is no room” message.

Here’s how the barrel in the screenshot is configured:

All entities in Shining Online are made up of components. Entities are created using a simple template system, which sets out which components are required and what their field values are. The base_money_container template looks like this:

It listens for an inspectevent, and then disables input, runs the gold:findscript using properties from the entity and then re-enables the entity when done.

The %self% variable is always set to the entity’s identifier. So for the money container in the example, it will be the string “vagabond_gold_container_1”. Flag names can be overridden by setting a flag_name property on the entity, but that’s optional.

And finally, here’s what the gold:find function looks like:

For comparison, this is what the item:find function looks like:

It’s a little more complicated, but it’s all built and configured in a similar way to the gold container.

That’s all (for now)

I’d like to get item management finished in the next few months so I can move on to the battle system. Pathfinding and movement ranges are all working, so with some AI and proper turn management there will be an actual game soon!

The last month or so have been spent on building the user interface and making it actually usable. Equipping weapons isn’t exactly a thrilling part of the Shining experience, but it’s an important one.

Right now Shining Online’s item screen looks something like this:

It seems like every project update usually contains a bunch of notes about boring engine internals. So here’s a screenshot of Demo 5’s first battle instead.

The last couple of months have been a bit quiet on the development front, but this year I really want to release the elusive Demo 5. There’s still a lot of pieces that need to fall into place, but every hour spent on the project brings it a little bit closer to release. At least that’s the theory.

The biggest feature I’ve been working on lately has been the status menu framework. It’s one of those things that seemed simple on paper but ended up taking far too long.

Screen stacking was definitely the biggest sticking point. Players need to be able to navigate to new menu screens, but also need to return to the previous screen in the state they left it. Sprinkle in some interactive panels and transition animations and things start to get complex. It’s undergone two rewrites since I started, but I’m satisfied with how it works now.

At the moment the team list and character details screen are implemented, but I’m planning to have the rest finished soon™ so I can move onto something more enjoyable.

It’s been a while since the last project update, mostly due to a hardware failure at the start of the year. No data was lost, but it took a while to get everything back to normal. Unfortunately that means there hasn’t been a lot of progress, but things are still moving forward.

• Website rebuilt — The new shiningonline.org looks pretty much the same as the old one, but there are a lot of changes under the hood, mostly aimed at making it easier to publish game content to the web.
• Scripting engine improvements — The script engine now supports some very basic editor integration, so scripts can be rebuild and reloaded whilst the game is still running. I expect this to be a huge help in the future
• Lots of screen designs — UI development is my least favourite task, but it needs to be done. Various menu screens are starting to come together, and soon it will be possible to actually manage inventories and teams without using debug commands.

As always, more detailed notes can be found on the Development Notes section of the Shining Online site. Until next week!

It’s been a busy few months, but progress has been good. The largest task I’ve been working on is the scripting system, and there’s finally enough of it implemented to be able to “play” a short part of the game. There is still a huge amount to do, but I’m pleased with how things are currently working.

Previously I was using a system of triggers, conditions and actions to run scriptable events. This worked well enough for simple things, such as an NPC that says one line of text, but it started to struggle once more complicated actions and cutscenes were required.

In the end I felt the best course of action was to build a scripting language into the game, rather than trying to turn the existing system into something more powerful. It took a few weeks of development, but it’s finally usable. Here’s a comparison between the old and new systems:

Before:

[template_triggers] {
    [*] {
        event*     = EVENT_INSPECT_ENTITY;
        condition* = global_flag_equals('vagabond.has_spoken_to_tensai', 0);
        action*    = display_textbox('[Text goes here]');
    }
}

The above configuration would add a “template_triggers” component to the entity, and assign a single trigger that would listen for the EVENT_INSPECT_ENTITY. When the entity receives the event, it would then check to make sure the “vagabond.has_spoken_to_tensai” flag, and would then display some text if flag wasn’t set.

It’s good for simple things like doorways and one-line NPC’s, but it quickly gets unreadable once more complicated decision trees are needed. You can very quickly end up with a dozen or more repeated conditions. Not good.

After:

(listen :event-inspect-entity
  (when (not (global-flag? "vagabond.has_spoken_to_tensai"))
    (message-box "[Text goes here]")))

I went with a Lisp style syntax, mostly because there is a wealth of information about writing Lisp parsers. The plan is to have a few dozen commands baked into the engine, and then the rest defined in the script engine itself. So far it has worked pretty well, but I expect I might not be so optimistic in a few months.

Probably the hardest problem was pausing the various script processes without blocking the rest of the application. The original script interpreter would run all functions sequentially, which made it easier to implement but impossible to pause a script for external input. In the end I added a stack-based VM and a very (very) simple “process” system, which allows multiple scripts to run in parallel. Processes can pause themselves (and other processes), which makes for some interesting possibilities.

It was a lot of work, and probably not the best way of handling things, but it’s now possible to create some more interesting behaviour purely through scripting.

I also spent far too long rebuilding the entity system to separate the graphical representation (the actual sprite image) from the logical position (co-ordinates on the map). The main reason was so the server doesn’t need image libraries in order to run. Plus it doesn’t really need to know the actual image details, just the position of the character. I probably wasted a week getting it all switched, but I think it’s better to do it now than later.

Another thing I’ve been working on is getting the various menus up and running:

This is my first effort at the status screen. It’s a little different from the usual Shining Force style, but I think it works. There’s still some changes I’d like to make (such as the health bars), but overall I’m pretty happy with the layout.

Nothing too exciting in this update, as most of the work lately has been on getting the scripting system working in a nicer fashion.

• Treasure chest now stores its state in the game session, which can then be checked during trigger evaluation. In other words, it knows if it has been opened
• NPC’s can respond to events and display messages (as seen in the screenshot)
• Cleaned up the rendering system so screens don’t have to access the render service directly. Each screen has its own render group which it can add items to, and these are automatically added and removed from the global queue

Like I said, nothing too exciting, but progress is progress.