Shining Online

December 23rd, 2008 13:28 Development Diary

A little Christmas present

It’s not a demo I’m afraid, but a tiny glimpse at what’s going on with Shining Online. Despite being pretty much silent for the past year or so, we’re still working on it. It’s very slow going, but if all goes to plan there’ll be a lot more action next year. I’m sure I’ve said that every year, so no promises ;)

Anyway, below is a little screenshot of the current Shining Online website. We’re using a wiki to keep our notes and ideas together, which also acts as a complete reference of the game world. The light version of the main site will go live in the second quarter of next year, and after that updates should be a little more frequent. Hope you like the design!

The Amazing Shining Online Wibsite
[Click for Bigger]

July 23rd, 2008 09:29 Development Diary

Shining Online – How we did AI

Hind Beetle - The Atari ST Version Woah, a Shining Online update! Unfortunately there’s nothing really new in this entry, but if you want to see how the old demo worked you might be interested.

I’ve tried to extract as much useful information from the original source code as possible, but it really was a mess. Blame my youth and inexperience for that :P

How the AI worked, or “Everybody hates Ken”

If you’ve played Demo 4, you probably notice everybody gangs up on Ken. It might think it’s because of his awesome blue hair, but that’s not the case.

Every time an AI in Shining Online decides to move, it has to decide whether to attack, move or defend (and heal/support if I’d got that far ;)).

Who do we attack?

The AI would first cycle through every player on the battlefield. Each player is assigned a score to work out how dangerous they are to the current enemy and how likely they are to die.

Scores were assigned based on the following:

  1. Players with less than 25% health get 15 points.
  2. Players that can be killed by this enemy (health < attack) get 25 points.
  3. If enemy attack multiplied by their bravery was greater than the player defence, there’s a 10 point bonus.
  4. Closer players are given higher scores.
  5. 10 points are added for each enemy the player has killed.
  6. Cody has a 10 point bonus for being the team leader.

All the scores are then sorted, and the enemy has its target. However, not all targets are in range, so a little extra decision making needs to be made. If the player was out of range, but the enemy had high bravery they’d rush towards them, otherwise they’d stay still.

And that’s all there is to it!

Further Improvements

The addition of healing would have made things far more interesting, but I was far too lazy to add it.

Here’s a couple of improvement ideas for the next version:

  1. Take healers and mages into account, especially ones with multiple hit spells.
  2. Look at what other enemies are doing.
  3. Have an “order” queue that can have instructions added to it by the boss enemy. For example, if the boss felt threatened by someone, they could send minions to destroy them. This could also be used to instruct units to heal others.
  4. Don’t move into dangerous squares. Each square could have a "danger" rating assigned to it, calculated by adjacent enemies and land effects. Enemies would avoid squares with high danger values.
  5. Magic and support. Perform attack spells on the heavy hitters, or boost the defence of healers and "tanks".
  6. Personalities and vendettas. The "bravery" attribute was an attempt to do something like this, but it sucked.

The biggest problem with all this is keeping things fun. An AI enemy is playing to win, but it has to do it in a fun way. Having enemies do a pincer move or set you up for defeat can be fun to play, if it’s done in an imperfect way. This is where personalities and randomness come in, as you don’t want enemies to always react the same way.

January 8th, 2007 16:32 Development Diary

A look at the SO Editor

Once development of the PC version of Shining Online started, it became apparent that a suite of editors would make creating the content much quicker and easier than adding information directly to the source code. Here’s a little look at two of the old Shining Online development tools.

Shining Online – Level Editor

The first version of the level editor was built directly into the game engine, and could be activated by pressing certain keys. The buttons on the side would slide onto the screen in a similar fashion to the Dreamcast web-browser, and the whole thing was controlled using the arrow keys.

As the levels got larger and more complicated, using this editor became much harder. After the first demo was released it was re-designed and rebuilt from the ground up.


The “Shining Online Development Application”, or SODA, was the next iteration of these development tools. It was a separate, full screen application that took advantage of a higher resolution and the mouse, so was much easier to use. It made it much easier to edit maps and characters, and integrated an “event editor” that allowed the user to create simple scripted events, such as characters speaking or changing the weather.

The quest featured in Shining Online Demo 3B was developed using SODA, which was difficult considering the unfinished state SODA was in. It was mainly a race between adding functionality to the main game and then adding a method to edit it in SODA.

The Future…

When Shining Online was put on indefinite hold, my focus switched to other projects which would need a set of editing tools to be created. Instead of creating a million new editors for each new project, it seemed logical to create a single, unified application which other editors could be built on top of.

Instead of writing a complete GUI system as in the first two applications, the standard Windows GUI is used instead. Naturally a few extra bits have been added, and the finished version should allow for GUI’s to be loaded dynamically from an XML definition file, which opens up the possibility for the application interface to be developed using itself.

The editor is currently in development (as always), but is still called SODA. Because recursive acronyms are so popular these days, SODA should stand for something groovy like “SODA: Omnipotent Development Application”. I think I’ll keep that.

February 20th, 2003 12:23 Development Diary

Worklog – February 20th, 2003

More more more! From now on I’ll try and update this thing as soon as features are added. Most of these features should be apparent in the next demo.

  • Added the play and stop ambient sound events.
  • Added the play and stop music events.
  • Added the new look weather events.
  • Added the speak event.
  • Added enemy editing to SODA.
  • Added obstruction template (thanks to Koshums for his help).
  • Added the flashing tiles too :)
  • Removed almost 30k of redundant/repugnant code. Ouch.


November 28th, 2002 12:22 Development Diary

Worklog – November 28th, 2002

Another month, another Dev Diary. I’m writing this at 2am after 6 hours of coding, so excuse the lack of coherence.

  • Got four absolute monsters of assignments for January hand-ins. Ouch.
  • Interviewed for TSS. Hopefully a link will be up soon.
  • More source slicing. What’s left is a lot tighter than before. Hopefully the weekend shall yield more results.
  • Started writing an A* algorithm for the enemy AI (as well as an article to go with it.) It’s not as easy as I thought, but it should be done soon.
  • More design doc, more website.
  • Worked on SODA some more. Completely overhauled the interface.
  • Started plans for the Atari SO.
  • More website stuff.
  • Did the Hussien Skank.

My bed looks very comfy. Night!