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:
character_dictionary['103']['attributes']['strength']

or:
character_dictionary['103']['inventory']['greatsword']

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?

Comments

Popular posts from this blog

Upstairs / Downstairs.

I've decided to make my prefabs multilevel. Later this should allow me to add pit traps and other great stuff. It also makes it easier to line up stairs so that you can exit them on the same co-ordinates where you entered them. The prefab editor is pretty much finished, it just needs some code for loading up prefabs from a saved dictionary, so that they can be checked or edited. The entries will need to be forwards compatible, so I'll be loading each tile and then translating the indexes to a new array, that way if I add extra indexes or extra info (like traps or puzzles) I'll be able to update existing prefabs to work with the new standard. Click for a video.

Automating Level imports from Blender to Godot

  Recently I've been making some levels in Blender an importing them into Godot. There are only about 7 or 8 shaders for each level, not counting dynamic objects which will be added later. But to improve rendering performance, it can be a good idea to split the meshes up into sections. At that point you might be faced with a list like this: Or it might be even more chaotic, if you didn't use simple names for the objects in your level. So it can take a long time to sort out all the meshes, make them unique and add textures and so on. Blender imports with simple Blender textures, or with placeholder materials. This is sometimes OK, but if your Godot shaders are very different to those used by Blender, it means applying new materials to every mesh object in the level when you import the scene. I found that during the design process, I was importing and readying a level several times before I was happy with the final layout. So at first I was wasting a lot of time. In Blender, I us

Advice needed on tilesets...

I need some advice on which is the best way to handle building the dungeon. Right now I'm using prefabs for my dungeon, they have a north south east and west section for each "room": The basic tileset. This has several advantages, and also several disadvantages. Firstly I can have curved rooms, I can have tunnels and other interesting shapes. The tilesets can look quite nice with a little work. On the other hand I can't easily get the navigation data before building the map and once the map has been built I can't make changes to the layout, like having active pit traps or believable secret doors. Although the rooms are interesting, they are quite repetitive, and it takes a lot of effort to make even a few different variations. Also rooms are constrained to one size. A newer version of the tileset with a lot of variant parts for making more interesting rooms. To create a tile set is a real headache too. Planning how to lay out the UVs, trying to cra