More updates, and Lua scripting

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.

Team duel to the death

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…

Map editor: Switches

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 🙂

Map Editor

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

map_editor

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 🙂

Knights game this Sunday

Since the Knights server is often empty (although admittedly less so than it used to be), I have decided to start holding a regular multiplayer Knights game, once a month. I thought this would be a good way to give Knights players an opportunity to get together and play in a bigger game than would normally be possible.

The first of these monthly games will be this Sunday, 21st February at 16:00 GMT. This will be held on the official Knights server (knightsgame.org.uk). All welcome, just log in at that time and join in the games. Hopefully there should be quite a few people online. I myself will be there and so will a few people from the forums (see this thread for details).

Finished tutorial, and single player mode

I spent most of the weekend working on Knights. I’ve now got the tutorial working and I’ve also added a single player mode, as a couple of people have requested it. The tutorial took quite a while to get working properly, but I personally considered it important to have the tutorial and single player mode in place, for completeness more than anything else.

I also added optional time limits for quests – if no-one finishes the quest within the time limit, then all players lose. This actually works quite well with the single player mode. I played through a few of the standard quests with a time limit and it is quite fun and strangely addictive… which is encouraging!

I’ve also been working on a ton of bug fixes and other minor improvements; hopefully now that those are out of the way, there should be more time to work on more interesting stuff in the future.

The next step is to get this lot released – probably this coming weekend. After that I’m undecided about what to do next, but maybe adding some of the new quest types (e.g. team games) that have been suggested would be fun.

Tutorial Mode

It’s been a while since my last post, but I’ve now started working on Knights again.

One thing that Knights badly needs is more players. So at some point I am going to want to approach various indie gaming type websites and try to get some ‘press’ for the game. However, before I do that, I want to make sure that there is some sort of tutorial mode in place. The reason being that, since Knights is fairly difficult to learn (imho), I think we need to do as much as possible to ensure that new players can easily learn how to play. The last thing I want is for there to be a huge influx of new players, but then most of them disappear again because they can’t work out how to play the damn thing…

So the plan at the moment is to do one more release with tutorial mode added (and perhaps a couple of other things) and then start on the ‘marketing’ stuff.

Here is a screenshot of the tutorial mode so far (click to enlarge):

The tutorial is basically just going to be a standard Quest for Gems, except there is going to be a little window at the top right (as you can see in the screenshot) containing various hints. The idea is that as the player goes around the dungeon, certain events will trigger a message to appear. For example, the first time you see a door, a message explaining how to open doors appears, and the first time you pick up a trap, you’ll get a message explaining how to set traps.

I tried a couple of other approaches – like having windows pop up during the gameplay – but I found that just got annoying and interrupted the flow of the game. I also thought about making the tutorial more ‘active’ and giving the player little tasks to do – like ‘now go to this room’, ‘now set a trap on this chest’, and so on – but to be honest I don’t really like that sort of tutorial. (I remember downloading some space sim once, where the tutorial was trying to teach you about a million different key commands, and it wouldn’t let you move on to the next one until you had completed some little task with the previous one. I got so bored with that, I gave up half way through the tutorial and didn’t play the game again!) With the scheme I proposed above, at least people can just skip certain things if they want – for example if someone’s not very interested in traps, then they can ignore the instructions on how to use traps and just get on with the rest of the tutorial.

Anyway I think I’ve ranted on long enough for now… Expect another post when this tutorial stuff is finished. Also, at some point I am going to get Trac installed, and put all the outstanding tasks into it. I expect there will be time to put a few bug fixes or minor new features into the next version, as well as just this tutorial stuff.

Issue tracking systems – part 2

A while back I blogged about setting up an issue tracking system for Knights. There were two systems I seriously considered: JIRA and Trac. I found that my server didn’t have enough RAM to run JIRA so I was going to use Trac instead.

Since then there has been a slight change of plan. The folks at Atlassian (the makers of JIRA) have informed me that they offer free JIRA hosting for open source projects. This is very cool as it solves my hosting issues and also is much easier to set up than Trac (as they basically set it up for you!). Also I am more familiar with JIRA than Trac (as I use JIRA at work). For these reasons I have decided to give JIRA a try.

So there is currently a Knights JIRA installation running at http://knightsgame.jira.com. This is open to the public so feel free to have a play with it and let me know what you think. So far I have added one or two issues but otherwise haven’t really used it yet — I’m relying on you guys to fill it up with the things you want done in future releases 🙂

JIRA is quite easy to use, but here are some quick instructions in case you need them:

  • To view issues, click on Browse Projects and then click Knights. You will be presented with lists of components and versions. Since I haven’t set up any components or versions yet, just click on No Component and you will be taken to a list of all open issues. You can then click any issue to get details of it.
  • To search you can either type something into the Quick Search box (top right) or you can do a more detailed search by clicking on Find Issues. In the latter case you will have a panel on the left of your screen which allows you to filter issues by type, priority, text search etc, or any combination of these.
  • To comment on an issue, first browse or search for the issue you want (see above) and then click the Comment link on the left hand side. You need to create an account before you can post comments (see below).
  • To report a bug or request a new feature, click on Create New Issue and follow the instructions. You need to create an account to do this (see below).

Note that currently I am running an evaluation copy of JIRA which is limited to five user accounts (one of them being me). These will be available on a first come first served basis. In the meantime I will have to submit an application to Atlassian to be given full access for my open source project. Once this is done (and assuming they accept the application) we will get full access and the limit on the number of users will be removed. This process apparently takes about 2 weeks. (If they don’t accept the application, then plan B is to switch to Trac. Should this happen I will copy all issues from JIRA into Trac so don’t worry about losing any data.)

Anyway, please try it out and let me know what you think.

This week’s progress

Just a quick update. Work on the next version of Knights has been going well. Today I finished off the in-game player list and tidied up a few other things. I also made some changes to the in-game screen layout recently; you can see a screenshot in this forum post.

There is only one more thing left to do before the next release and that’s to fix the LAN game mode so that it works with multiplayer (currently it’s still limited to two players). I’ll try and get that done next weekend, and then we’ll have a release!

After that I’ll see about getting the Trac set up. (I haven’t forgotten the Trac, I just wanted to get the work for the next release done first.) In the meantime, if you want to submit bug reports etc. then the forum is always available, or just leave a comment here.

Issue tracking systems

I think it would be good if Knights had a public issue tracking system, this would be useful for keeping track of bug reports (of which there have been a few following the recent multiplayer beta) as well as feature requests.

I’ve spent a bit of time looking at the different bug tracking systems out there (and there are a lot of them), but eventually I think I’ve decided on using Trac. This is an open source system that seems quite popular and has most (if not all) features that would be needed for a project like Knights.

Of the alternatives, I liked Flyspray and Redmine, which are both very simple and easy to use, but they seem a bit limited in terms of features (imho) compared to Trac. I also considered JIRA which is what I use at work (and it’s free for open source projects to use); JIRA is a very nice system, but unfortunately it’s an enormous Java application which my server doesn’t really have enough RAM to be able to run properly, and anyway it is probably overkill for a small project like Knights.

In other news, I have now got most of the bugs from the multiplayer test fixed, and have been working on getting observer mode working in multiplayer games as well (so you can change who you are observing by using left/right arrow keys). I also want to get a player list and end of game statistics set up before releasing a “stable” multiplayer version.

After that I think the next priority would be making the game simpler for newbies. I think there are a lot of people who try the game out once or twice, can’t work out how to play, and then never come back (I sometimes see people like this on the server). Sadly people do not read manuals these days. Some sort of tutorial mode is probably the answer here.