From our thread on the Unity Forums

Finished the major functionality of the quest editing system, it can add and remove quests and quest chains, rename them, assign starter and turn-in NPCs, add/remove/configure objectives and NPC set dialogue text. References to linked quests are automatically updated when quests are renamed or deleted.

The entire quest structure is saved as a binary asset which is loaded at run time by the QuestManager.

Still to be added are functions for filtering and searching quests by name, zone, starter/turn-in NPC, objective type etc. etc. This will become increasingly necessary as the number of quests in the game increases.

From our thread on the Unity Forums

KoG is progressing nicely, we added a lot of content over the past month or so. It’s now got various types of NPCs, including vendors, quest NPCs and professions trainers.

We’ve implemented the quest system, which is story driven and supports multiple types of quest objective, including but not limited to talk to/take item to another NPC, kill a number of mobs, kill mobs to collect drops, search for and find collectable items, explore an area, etc. etc. Each quest can have multiple objectives made up of a combination of any of the available objective types.

Quests can be part of a longer chain, and some are repeatable daily.

We’ve implemented a lot more professions, there’s currently 17 different professions with more to come. All of the useful items in the game (potions, food, armour weapons) can be made, and as the profession skill increases, things like armour and weapons will have a chance to be better quality, with better stats.

Some more screenshots…

Exploring the local caverns

I wonder what’s on the other side of this portal…

Playing with my new combat skill

NPCs with quests

Quest dialogue example

Professions UI

Gathering some ingredients

WIP Room interior

From our thread on the Unity Forums

Been working on the UI and just finished implementing draggable windows. Here’s a quick video demonstrating that, plus some of the other features we’ve been working on such as the bank and vendor windows.

From our thread on the Unity Forums

Implemented dropping items from your inventory onto the ground. Other players or yourself can pick them up again, and they disappear after 2 minutes. Not yet implemented is a popup window that shows the content when you mouse over the package on the ground.

From our thread on the Unity Forums

The majority of the framework for the professions and manufacturing system is now in place.

To work, you go the area in which the item you want to gather can be found for basic items, or for advanced items (armour, weapons, potions etc.) you go to the associated building for that profession and then you select the item from the list of products you can currently make/gather and your character starts working.

You can’t perform any other actions on a character whilst it is working, however, you can switch to another character or exit the game and when you come back your work session will have continued while you were away (courtesy of our proprietary, ahem! Temporal Phase Adjustment Technology) and you’ll be presented with a report of what you made during that time. However, it can be quite relaxing actually just sitting there and watching it tick away 🙂

Typically, low-level items can be gathered quite quickly, but higher level items will take considerably longer to produce and may require rare drops as one or more of the ingredients. Whilst lower level items will be available to buy from NPCs higher level items will only be available from mob drops or professions.

The benefit of making things like armour and weapons yourself is that as your skill in the profession increases you will have a chance to make better quality versions of the items than those that you can gain from mob drops, with better stats and higher durability.

From our thread on the Unity Forums

It’s been just over a month since my last update and there’s been a fair bit of progress during that time.

The combat system feature list is pretty much complete now.

• It supports melee and cast spells to single and multiple targets, which can cause damage or healing. Healing can be targeted at the caster and other targets.
• In combat and out of combat skills are supported.
• Skills can be set to allow particular target types e.g. Friendly targets, enemy targets or self only.
• The attack system is generic and the same code is reused for player, pet and mob attacks.
• As well as attacks, buffs can be cast, which can increase any the available stats for a configurable number of rounds.
• Buffs can also apply heal over time and mana recovery over time during combat.
• Skills can be set to be available in combat only, out of combat only, and both.
• Cooldown system, mainly for out of combat casting. Cooldown persists between sessions in real time.

Out of combat heal

Skills can be dragged onto the skill bar and arranged in the ways that best suits you.

We’ve also done a fair bit of work on the underlying system for handling in-game items and we’ve got a flexible system in place to control all the various item attributes that things can have (name, icon, weight, description, usage effects etc. etc.)

We’ve handled this using mainly composition and interfaces, as we felt it gives us greater flexibility and cleaner code when compared to using inheritance.

The inventory system is 90% finished too and although it was designed primarily to handle the player’s collection of items, the same core code will be used to handle anything that needs to work with game items e.g. the player loadout.
Weapons and armour can have stat bonuses in multiple stats and consumable items can be used to heal/recover mana or apply stat buffs that have a limited duration.

Inventory and player loadout (WIP)

We’ve also implemented exp. gain and levelling for both characters and pets and unlocking of skills based on level. Some skills will be unlocked in different ways.

Levelup!

On level up, some stat gains will be allocated by the system and some will be awarded to the player to distribute in whichever way they like.

We’ve also done a lot of work on the drop system, which allows us to set loot tables for entire areas and also for the mobs themselves. On completion of a successful fight, the area and mob loot tables are combined and the drop probabilities are calculated. Specific drops can be limited in quantity and/or made a guaranteed drop. Armour and weapon area drops will be generally low quality, whereas boss mob drops will be higher quality with proportionately higher stats.

Combat result dialog (WIP)

Hopefully, we should have a working implementation of the workskills/production system for the next update.

As always any comments/suggestions are very welcome.

From our thread on the Unity Forums

Implemented single and multi-target caster attacks, here’s a quick video demonstration.

From our thread on the Unity Forums

As mentioned in an earlier post, we’ve been working on the turn-based combat system. Here’s a video of it in action in its current state.

Currently, only basic melee attacks have been implemented, and the attack priority is only sorted by attacker type (i.e. mob, player, pet). Eventually, the attack order will also be governed by dexterity and spell/skill type.

We had a few headaches synchronising the attack animations between clients; programming multiplayer is such a PITA compared with single player, but it’s a nice feeling when it comes together 🙂

There are still bugs to be ironed out, mainly relating to situations where players unexpectedly disconnect during combat, but they are few and far between now as we’ve dealt with the majority and in general it’s pretty stable.

We’ve also decided on a title for the game, The Kingdom of Galanor.

As always, any comments, suggestions, criticisms are always welcome.

From our thread on the Unity Forums

We’ve been working on a lot of ‘under the hood’ stuff, making sure the core systems are as stable and maintainable as possible. The worst thing is finding out sometime down the line that some bad early design decisions have come back to haunt you.

One of the first obvious hurdles we had to overcome was how to deal with teleports. Initially, we had a simple design, whereby the teleport gameobject contained a component that had a reference to a destination gameobject and when activated it just moved the player to the destination location.

All well and good, except that as we use a different scene for each map we ran into the issue that as cross scene references aren’t allowed we couldn’t store the reference to the destination in the teleport if the destination wasn’t in the same map.

So a slight design change meant we stored the name of the destination gameobject in the teleport along with the scene path as strings and then when activated, the teleport loads the new scene (if necessary) and once the scene is loaded it searches for the destination gameobject by name and then moves the player to its location.

Job done, or was it? With the number of teleports that will eventually be in the game, this would soon become a nightmare to maintain. Anything that relies on manual entry of strings to make references for anything other than a few objects isn’t going to cut it.

In addition to that, we found that although this worked acceptably in a single player environment once we tried it networked we saw ‘warping’ of the player character because it was at its old location from the previous map for a few frames whilst the teleport located the destination and sent the new location over the network. So we fixed this by adding the location and rotation of the destination as properties of the teleport and sending them along with the scene change message, so all clients could update to the new position instantly.

This, however, meant that it was even more difficult to maintain the link between teleports and destinations and was quite frankly turning into a nightmare. So it was pretty obvious that a rethink was required.

After a bit of discussion, it was decided to move all teleport logic and data to a singleton manager which would store the information for all the teleports and destinations. Which just left the issue of how to easily get that information into the manager in the first place.

Custom Editor Window to the rescue!

We designed a custom editor that enables us to create/edit and delete teleports directly in scenes and it automatically saves the info for each teleport/destination into an asset which is loaded into the teleport manager at runtime. This has changed the task of maintenance from a manual task to visual design. We can quickly locate and update teleports and destination maps/positions and the new information is automatically saved. We can also automatically check for orphaned teleport and destination objects.

Now when a teleport gameobject is activated at runtime, it just queries the manager for its destination information and voila!

Quick snap of the editor in action, and that’s it for this update. See you again soon.

From our thread on the Unity Forums

Have been tidying up the network code that handles parties and combat, particularly to make sure that unexpected disconnects are handled gracefully and don’t result in errors and null reference exceptions for the remaining clients.

The party system is substantially complete and is working exactly as planned. The combat system is partially implemented, with passive and aggressive mob behaviour.

When we originally started developing this we had player stats network synchronised, so any time any player had a stat update (HP, MP, DEX etc.) it was broadcast to every connected client, which created unnecessary network traffic. But it became clear that most of the time access to remote client stats wasn’t required, and it would be more efficient to have stats on the local client only and just send the stats to any interested clients on the occasion they are required.

We currently have a placeholder scene in place for combat, and in that we can see that the party leader correctly receives data from all players in the party, which it will use to calculate the result of the combat, and then transmit that to the other party members as and when needed.

Hopefully, the next update should have a working implementation of the turn-based combat system.

Players are currently only sending about 1 update a second to synchronise position and rotation (packed into one vector3), which although doesn’t result in absolutely perfect synchronisation is easily good enough for this type of game.

Also, we have also been experimenting with a shader based random screen transition system.