Category: Uncategorized

I have now implemented a prototype action bar (as explained in my previous post). Here is a screenshot:

As you can see there is a little row of action icons that can be clicked on. (Please ignore the red square on the left, that is a graphical glitch that will go away in the final version.)

After trying this out for a while, I’m reasonably happy with it. Using the mouse along with the WASD keys feels very natural (no doubt because of its familiarity from other games). On the negative side, the pure action bar system feels a bit slow to use, especially for common actions like attacking or opening doors where you don’t really want to hunt along the action bar every time.

The best system is probably some sort of hybrid, using keys (or mouse buttons) for common actions, and reserving the action bar for more rarely used actions. For example:

• WASD = move
• E = pick up, open door, etc
• Right mouse button = attack

Alternatively, we could use the left mouse button (when the mouse pointer is outside the action bar area) as a “pick up” function, instead of the E key.

I tried this out briefly and it seemed to work quite well. Unfortunately I didn’t get time to go any further this weekend (I’ve had to spend some time installing anti spam measures on the forum unfortunately) but I will keep playing with it and report back on how it goes.

As I’ve mentioned before, I’m working on a new control system for Knights.

Right now, I have set up a system where you have the four movement keys, plus three separate “action” keys: one for melee combat, one for ranged combat (daggers, thrown axes, or crossbows), and one for interacting with the dungeon (which means opening or closing doors, picking up items, and the like). There is also a separate key to open the menu, which is still needed for the lesser-used actions (like setting chest traps or picking locks).

This works reasonably well, but I found it a bit confusing, especially when combined with the “approach” feature of Knights (i.e., where you have to approach a chest or door, by holding down the movement key, before you can open it).

So, I tried removing the approach feature completely. For example, to pick up an item from a chest, you now just face towards the chest, and press the interact button; you don’t have to “approach” the chest first. Similarly for opening doors. This does seem to have improved things, and is also probably simpler to explain to new players. It does lead to one or two quirks (like picking up an object in front of a door: if you’re facing the door, you can’t pick up the object, because pressing “interact” will open the door instead); but on balance, I think the advantages outweigh the disadvantages.

However, even with that change, I am still finding the new controls a bit confusing. Sometimes I press “interact” when I meant to press “attack”, or vice versa. No doubt this is just because I’m not used to it, but it’s still a bit annoying.

My brother has suggested a World of Warcraft style “action bar”. In other words, we would use WASD for movement, and then have little icons that you click on to perform actions (like attacking, opening doors, and so on). We would also allow players to map keyboard shortcuts to the actions if they wish.

I’m going to try to this out and see how it feels. If it works then it could be quite a nice system, because it means new players can use a friendly mouse-based interface, while experienced players can still use keyboard controls if they wish. It also means we can get rid of that irritating 4-way menu once and for all 🙂

Controls are an important thing to get right, so I’m going to keep experimenting until I get something that feels right. I don’t know how much more time that is going to take; but I’ll try to keep people informed via this blog.

I’ve been busy adding Lua scripting to Knights. This has involved quite a few changes to the code (and plenty of debugging!) but I think it’s been worth it. Most of the in-game scripts (such as switch effects, gnome book puzzles etc) are now using Lua instead of my old text file based configuration system. Although the new Lua scripts don’t really let you do anything new yet (they basically replicate what the old system could do), the general framework is now in place; all that remains now is to add a few new functions and things that can be called from the Lua side. This should allow plenty of possibilities for mods.

The next thing I need to do is to write some documentation of how the Lua scripting works. I might use the Trac “wiki” section for this (as it’s not being used for anything else currently and it will be easy for me to update it as development continues).

After that I want to start work on the new control system which I promised a while ago. I have planned out how I am going to do this, it is just a case of doing the work now 🙂

Hopefully, I should be able to get a release out with this stuff in it by the end of the year.

The forum is now back online.

The problem was that I was getting some strange spam-like emails being sent to me from the forum. I never found out why this was happening – maybe it was someone trying to hack into the forum, maybe it was just a bug in SMF. But I have upgraded to the latest SMF version (2.0 RC4) and this seems to have solved the problem, for now at least.

I also took the opportunity to delete the spam user accounts (that have been building up again!) and also tweak the forum settings a bit. I have disabled the ability for guests to view user profiles. This means that if spammers sign up fake accounts and then put links in the profiles, then no-one (apart from regular forum users) will be able to see those links. It probably won’t stop the spammers, but at least they won’t be getting any benefit from spamming my forum any more.

Due to some technical issues I have had to disable the Knights forum temporarily. My apologies for this.

I will post some more details at the weekend once I have had a chance to look into the issue in more detail.

First some good news: after a break of about 2 or 3 months, I have started working on Knights again, as of today 🙂

The first thing I wanted to do was have a look through the backlog of bug reports. Unfortunately there are a couple of bugs I can’t reproduce at my end, such as #74. This is a bit of a problem since you can’t really debug something if you can’t reproduce it. So what I’ve decided to do is start logging all Knights games played on the server: this means saving all the network packets received, with timestamps, as well as the random number seed used for the game. Then, if I set up a test server on my machine (with the same random number seed) and replay all the packets to it, the game should (in theory) play out exactly as it did on the real server — and bingo, we have a reproducible test case.

So the first thing I will do is set up some logging; hopefully this should be done by next weekend.

After that, I want to have a look at controls – lots of people on moddb complained about the “strange” control system, so we need to do something about that. Also, I want to continue the work to add Lua scripting to the game (which is quite a big task). So there is lots to keep me busy for the moment 🙂

OK, time for another update.

Since the last post I have finished the “team duel to the death” feature and hope to get this released fairly soon. If people like this then I will consider adding a team option to all quests, but let’s see how it goes for now.

I’ve also been working on some minor improvements and bug fixes (you can see a list here: http://www.knightsgame.org.uk:8000/timeline).

Another big change I am looking into is adding Lua scripting to the game. Someone suggested this on the forums a while back — the idea is that people would be able to add their own new features to the game by writing simple Lua scripts, instead of having to hack the C++ code. I think this is a good idea as I personally don’t have that much free time to work on Knights, so anything that can allow users to help me out by adding new stuff themselves has to be a good thing.

Some things that could be enabled by Lua scripting are:

1. Changing the way the dungeon generator works, to allow new types of dungeon layout, procedurally generated dungeon rooms, etc.
2. New monsters. This could mean new monster types (with different strength, speed etc) or new AI behaviours (by allowing monster AI to be controlled by scripts).
3. New tile types.
4. New item types, including new types of wands or new potion/scroll effects for example.
5. New quests (e.g. by allowing the victory conditions to be modified from scripts).

I should say that these are all just ideas at the moment and it is going to be quite a lot of effort to actually implement all of that. However it should be possible to proceed incrementally, so I can start by making one small part of the game scriptable (item types for example), and then add new scripting features gradually as time goes on. This should allow me to continue adding other features in parallel with the scripting and also maybe get feedback on the scripting system from an early stage.

So… it’s been a while since I did anything Knights related, but today I’ve started working on it again.

I’m working on adding a team duel to the death mode, which is something that was suggested on the forum a while back. This is basically going to be the same as a normal duel to the death, except that the knights will divide into two teams. There will only be one wand of securing in the dungeon, and the objective is to secure all entry points for your team, then kill all enemy knights to win. If this works well, I will go on to add other team modes, like “capture the book” for example.

Other than that I don’t really want to add much else for the next release because it’s been a long time since the last one. I may make some further small updates (like adding more in game messages for example) but I’ll try to keep it minimal so I can get the next release out soon.

I have to go now, but stay tuned for more updates in the next few days…

This post explains how to set up switch effects in the map editor. (See the previous post for more details on the map editor.)

First of all, open up a segment containing some switches (e.g. A01.4) and take a look at the switches list (at the right-hand side of the editor window). Each switch is listed in the format “(x,y) [Effect]”, where (x,y) are the map coordinates of the switch and Effect is the effect itself (explained below). The coordinates start at the top left square (which is (0,0)) with x increasing to the right, and y increasing downwards.

Note that switch effects can be placed either on actual switches (in which case the effect is triggered when the switch is flipped up or down) or on floor tiles (in which case the effect is triggered when someone steps on the tile). Both are referred to as “switch effects” (or just “switches”) in the map editor.

The Effect can be one (or more) of the following:

Shoot(x, y, “direction”, item)

e.g. Shoot(0, -5, “north”, i_bolt_trap)

Used to set up bolt traps.

• x, y are relative coordinates of the point where the bolt should shoot out from. This usually points to a skull or wall tile. For example, Shoot(0, -5, …) means the bolt should start from a skull/wall square which is 5 squares to the south of the switch square. Shoot(-2, 3, …) means the starting square is 2 squares to the left of, and 3 squares above, the switch square. And so on.
• The “direction” can be “north”, “south”, “east” or “west” and indicates the direction the bolt will travel in.
• The “item” is always i_bolt_trap currently.

Activate(x,y)  /  Open(x,y)  /  Close(x,y)

e.g. Open(-2, 4)

Used to open/close doors etc. “Open” opens a door/pit/etc (or does nothing if it is already open), “Close” is the opposite, and “Activate” toggles a tile between open and closed.

• (x,y) give the relative coordinates of the tile to be activated, opened or closed. For example Close(1,2) closes a door one square to the right and two squares below the switch tile.
• The following tiles can be opened/closed/activated:
  • doors (both wooden and iron)
  • portcullises
  • chests
  • pits (NB there are three open pit tiles, and three closed pit tiles — note that the “wooden floor” tile is actually one of the closed pit tiles).
  • pillars/crystal balls (“opening” a pillar turns it into a crystal ball, and “closing” turns it back into a pillar)
  • pentagrams (“closing” a pentagram turns it into a dead pentagram that doesn’t do anything when stepped on, and “opening” it makes it active again).

TeleportTo(x,y)

e.g. TeleportTo(-1, 2)

This teleports the knight. Once again the (x,y) coordinates are relative, so the above example teleports the knight one square to the left and two down.

In addition, sound effects can be included, as follows:

• snd_click — A general clicking sound, used when a knight steps on a “pressure pad”.
• snd_crossbow — The sound of a bolt firing. Usually used together with “Shoot”.
• snd_door — The sound of a door opening/closing.
• snd_pentagram — The sound of a pentagram being used.
• snd_teleport — The sound of a knight being teleported. Usually used with TeleportTo.

Multiple effects can be combined, by enclosing the whole list in square brackets, and separating them by commas. For example, [Shoot(-3, 0, “east”, i_bolt_trap), snd_crossbow] would fire a bolt towards the knight and also play a crossbow sound, while [Open(-2,0), Open(3,2), Close(2,1)] would open and close several doors at the same time.

In a future version I might integrate the sound effects into the switch actions (so that “Shoot” always plays a sound as well as shooting a bolt) but for now you have to add any sound effects required as part of the switch definition.

To actually edit the switches you need to click the “Switches” button at the bottom (just below the main map area). Any existing switches will be highlighted on the map in red. To place a new switch, or edit an existing one, double click it and then type the switch effect you want. Note that you only type the part in square brackets, not the (x,y) coordinates. (So for example if a switch is listed in the switch list as (2,3) [Open(1,2)], you would enter this by double clicking on the square (2,3), and typing [Open(1,2)] into the dialog box.)

Switches can also be deleted by right-clicking them.

Don’t forget to test out your switches using the Test feature (Segment menu).

If you want to see examples of switches being used, have a look at the gnome book rooms (Z01.3 to Z09.3).

Finally, if you have questions, feel free to post them below, or ask on the Knights forum.

Happy editing 🙂

So I have been working on a map editor for Knights. Here is a screenshot (click to enlarge):

Some explanation is probably needed. First of all you have to understand how the dungeon generator in Knights works. Basically, there are a bunch of pre-designed 12×12 map sections, which I call “segments”. There are 259 of these segments defined currently. The game randomly selects a number of these and combines them to make a dungeon. The number of segments used depends on the dungeon type: for example, a Tiny dungeon is a single segment, a Basic dungeon is 4 segments (in a 2×2 arrangement), and a Huge dungeon is 9 segments (3×3). Each segment is then further split into a number of “rooms” which are the rooms you actually see in-game.

In the map editor screenshot you can see small images of the segments down the left-hand side. (There is a scrollbar so you can page through all the segments in the file.) Double clicking a segment brings it up in the main editor window (in the centre). Below that is a palette containing all the dungeon tiles that can be used to make the map.

The editor has three modes: Paint, where you can select tiles from the palette and “paint” them into the map; Switches, where you can edit the switches and their effects; and Rooms, where you set the boundaries of the individual dungeon rooms.

The switches are defined using a mini scripting language, which you can see on the right-hand side of the screenshot (each line represents one switch). In this example there are two types of switch, “Open” and “Shoot”. Currently you have to type in the switch definitions manually, but in future I may add some sort of GUI system so you can enter them in a more user friendly way.

The plan is to do an initial release of the map editor in about a week or so. This will be in a fairly early state so should probably be thought of as a “test” release, but at least it will allow people to start using the map editor and feed back to me any problems. If anyone makes any cool rooms with it then I will be happy to incorporate them into the game. Also, if anyone wants to draw some additional graphical tiles to use with the map editor, then that would be good too 🙂