Skip to main content

Comments Welcome and Data Entry

This is actually two short blog posts but I'll roll them together for the sake of brevity.

Firstly, BtS, the author of "The ground gives way" brought to my attention a problem with non-google users not being able to comment on the blog. The problem is now fixed and you should be able to post if you want to.

I do need some feedback on the game, so please do comment if you've got something to say. if you think something looks great, or terrible, please tell me about it. If you can see me heading for a disaster because I've made a mistake in my code or, a concept I'm chasing is fundamentally flawed, please tell me so I can fix it.

Secondly, I've been working on a rudimentary data entry program for my project.

A spreadsheet version of a dictionary.

Until now I've always used spreadsheets for creating data sets for my games. In the past I've spent hors, days, even weeks hand typing data for everything from global environment settings to battlemech stats. My Battletech simulator project was a very bad example of this with many dozens of hours wasted scrolling through open office spreadsheets trying to find the typos which had shown up in playtesting, or just plodding along adding new mechs line by line, entry by entry.

As it happens I found a way later to just rip the data directly from sourcebook and rewrite it to fit my special ruleset automatically. But that won't work with the current project because the only place the data exists currently is in my head.

With that in mind I've set about writing a custom program that should make Data Entry more survivable.

 The Dungeon Data Editor MKI.

I actually used to do Data Entry as a job, right after University. It was boring as hell, but that's mostly because the content was about supermarket loyalty cards, milk deliveries, university applications and other such mind numbing stuff.

I don't actually mind doing the data entry part of my games. It's hard work, entering thousands of characters at high speed while trying to keep an accuracy rating above 99%, but it's rewarding when you see your game come to life with all the raw information you've entered.

A monster isn't a monster until you've given it stats.

Anyway, the editor is working in a limited fashion already. I still have to add functionality for auto-complete and also for previewing the dictionary (in the white area at the bottom), as well as searching existing dictionaries to make corrections.

It's easy to alter the program, adding new fields, taking old ones away, showing inventory icons where necessary, I can change it from a monster editor to a weapons and items editor in just 5 minutes. I may even embed it in my main game so that I can preview the monsters with the chosen skin and animations.

However, the biggest benefit is in dictionary structure.
The spreadsheets were using a 2d data array. That is, each dictionary entry was an array of mixed properties which could be found by getting the dictionary, the id key and the index of the info you wanted.

So in the above spreadsheet:
character_dict['103'][3] would give me 0.25
But what does that mean? I have to make a list of all the indexes for each dictionary and remember them, and use them in my code like that. The alternative, embedding mini dictionaries in the main dictionary turned out to be a nightmare to try and enter data in to. It was just too long. I'd have to scroll back and forth all day long.

The new program though can save everything automatically in a dictionary of dictionaries or even a dictionary of dictionaries of dictionaries.

For example:


And it allows me to make checks like:
if "poison" in character['effects']:

Hopefully, once I get the autocomplete up and running with all the available armature actions and such it should make entering stats for monsters of items a breeze. Hopefully it should speed up development quite a lot.

I'm interested to know, do you use spreadsheets for entering data in your projects? Do you write your own data entry utilities or do your use others, such as microsoft access?


Popular posts from this blog

Make your game models POP with fake rim lighting.

I was watching one of my son's cartoons today and I noticed they models were using serious amounts of simulated rim lighting. Even though it wasn't a dark scene where you'd usually see such an effect, the result was actually quite effective.

The white edge highlighting and ambient occluded creases give a kind of high contrast that is similar to, but different from traditional comic book ink work.

I'll be honest, I don't know if there's a specific term for this effect in 3d design, since my major at university was in traditional art. I learned it as part of photography.

You can find plenty of tutorials on "what is rim lighting" for photography. It basically means putting your main sources of light behind your subject so that they are lit around the edges. It can produce very arresting photographs, either with an obvious effect when used on a dark subject...

..,or as part of a fully lit scene to add some subtle highlights. See how alive the subject look…

How to... build a strong art concept.

So you want to make some art assets for your game. The first on the list is a Steampunk Revolver for your main character to shoot up Cthulhu with. Quickly opening your internet browser you start with a Google image search. Ah, there is is!

It might be a good idea to find a few influences so you don't accidentally end up copying a famous design.

Just mash them up and you're ready to go! Off to your favorite modeling program.
But wait! isn't there more to building a strong design concept than that?

Of course there is.
One of the diseases of modern design is that of recursion. Everything is a copy of a copy of a copy. This is especially a problem with "historical" concepts. Over the course of that recursive process the concept becomes infected with modern design elements, and ends up looking very similar to everything else that anyone else has ever made.
If you want to come up with a really fresh idea, you have to get beyond secondary references and go look at real …


Ok, so it's not exactly skynet, but I have got my first AI state working, kind of.

The first state is "HOLD" in which case the agent stays in place where they are and shoots at any unit that comes in range. When I started writing this module, I found that the existing method of triggering actions wasn't good enough to allow the AI to choose the best weapon or target. It worked by simply sending a command to the unit to trigger the currently selected action.

If the action is valid, it triggered, if not it didn't.
That's fine for play controlled units, as that's all they need to do. But AI needs to know in advance if the action is valid. The player can get that info from UI feedback, but that wasn't available to the AI player.

There were three problems:

1. The UI feedback duplicated code in the action trigger function. These  two sets of code could get out of phase so that UI feedback was wrong.

2. The action trigger didn't give enough feedback for …