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

Back to Vinland.

I'm going back to my real time tactics project, Vinland 1936.
While working on the other project I overcame the problems which were stopping me from saving/loading the game and also cleaned up the base code a lot.

After a few weeks I'm getting near the the state I was in before.


Infantry are back to their previous state, and vehicles are running OK.
This time I'm going to push ahead with mocking up the combat system though before I work any more on the vehicle builder or graphical aspects of the game.

Map screen designs

I've been working some more on the map window. Right now you can only see the base, it doesn't show items, enemies or even doors on the map yet. These would be decals.


In the top window you can see the modified result of last night's tile based map. It looks good but there are some visual artifacts related to the problems I encountered yesterday, and as well it takes much more code and time to calculate.

The second window uses a cheap trick to fake an beveled look from a smoothed version of the 32x32 map. It uses black to mask unexplored areas.

Finally the third version is meant to look like a had drawn map. I'm using a cross hatching texture to distort it and unexplored areas are shown as blank map paper.

There's going to be a mechanic in game where you need to use some paper every level in order to activate the map for that level. From there it will fill it in automatically. Paper will be pretty rare so it might be worth keeping it safe for the more complex level…

Infantry combat and entering buildings.

I've been working a lot on the game recently and I've nearly rebuilt it to the level it was before. Past that maybe, since now I have the beginning of a working combat system and the ability to save and load the game.


Infantry can now occupy a building. It's quite an abstract representation, since they stay at the door and turn invisible. But they can then fire from one of the windows and take damage from shots at the windows too. I think I've set it up well so that when building damage and destruction is working then the system should continue to work.

For combat I tried some new ideas, but they didn't work out that well. It seems that it's important that viewing range should be further than shooting range. Now shooting range is pegged at 18 units of distance, while viewing range can extend out past that.

In the above image one unit has an officer, so has further viewing range. The other can only see as far as they can shoot, a dangerous situation since the en…