ikaDB is done. (read all about what it is inside)

At the very end there was a horrific, time-consuming bug that cropped up. But it's dead now. Let's have a look at the finished product, shall we?



Here's some basic code for a hypothetical game database concerning items and a basic enemy.

Let's take a look at it from the editor.



The editor categorizes data by whether it's a parent data model or not- whether it descends from any other data models or not. From these it builds a tree view of all the instances of data. Above is where you select which parent model to work with.




Here are all the operations you can do on the tree- adding or removing data model instances, moving them around, and categories. Categories are basically non-data that's solely for in-editor categorization (though games can access them if desired)



Here we have a simple database filled in by me so you can get a feel for how categories work. As you can imagine, these would become quite useful in a larger database. We also see how the DB generates the UI in fairly obvious ways from the example code. All fields from the parent are inherited by the child so you can have a basic item class just for displaying its name/text and then create more detailed models for when it comes time to actually use the item, rather than having one giant data model for every type of item.



Here we have the Monster model. The important part here is the MultiForeign field that essentially allows you to store instances of other DB items. It has two main modes- new and set. New mode lets you create a brand new model instance then and there. Set allows you pick an existing one in the database. The two can be mixed if desired. Here we're about to see the new mode in action:



As you can see, it simply generates a panel identical to the others for inputting the new object's data. The drop-down box is so you can choose from multiple model types to create if desired. Next let's see how the set foreign field mode works.



As you can see it's much like the main tree view, except you can't edit objects. You simply double click to select the desired item. One last look at how it ends up inside the monster model instance:



That's pretty much how it works, I hope you like it. While it's functionally finished it's far from completely stable or polished, something I hope to correct while I work on my game and WIP works on integrating with his own. The release will be delayed until I'm comfortable with its stability. The other factor is that it's so tied with the new iked functionality that I'd like for ikedv2 itself to be further along before release as well.

Progressive Caveman

Finished up the read-only view of models (plus the different ways to view them). Added fully functional cut/copy/paste/delete to the tree view. All that remains are foreign fields and model editor-only displays, and some clean-up of the tree view (indicate that things are cut, disable rename on data nodes, add icons to distinguish categories/data, make right-click visually select an item). Almost there!

On the downside WIP pointed out pretty effectively that I couldn't really tack on an event editor as I had hoped which somewhat damages its utility for the upcoming Delta T and pretty much creates another future project. Oh well.

I am pretty sick of working on tools at this point so I am going to take a break to actually work on a game. It'll certainly make DT harder to work on than if I had finished the suite of iked tools I wanted to do, but ikaDB is enough to live with. I can -probably- hack together a dialogue tree editor with it for the writer it work on it and cheat on way points with the current ikamap by using an invisible layer.

I'm pretty excited! DT's battle system is nowhere near the complexity that Contrivia had that just drained the project, and for the over world stuff I'll be able to reuse tons of code from my other dead ika games. Plus, it'll be a great chance to finally put together an event system before worrying about how to do a graphical editor for one.

Progress end

Strings, integers, floats, booleans, and enums have all been added. It should be noted that everything you see in that screenshot is completely functional. You can enter data and it will be saved and you can easily load it into your game. All that remains are the two types of foreign fields which I've started work on but are basically the last big chunks of work on this thing. After that basic cut/paste etc functionality has to be added to the tree and some additional brush ups like how to handle DB syncing. Also the order of that screenshot is incorrect due to a bug, the final version will organize the GUI according to the order you define fields. It should be done in a week or two.

After that phase two begins where the new ika map editor is worked on and the DB is integrated into it. Honestly, I can't believe this thing is almost reality. I've had the dream for over 5 years now but my hate of GUI code has always held me back. But I think a lot of thanks is owed to WIP, without his back end work on the DB side of things I would probably have gotten sick of all the dirty work before getting to the interesting stuff.

When I wrap this part up I'll probably do a more detailed gruedorf post explaining what this thing actually does and why I made it, for those of you who missed my original explanation way back when. I'm also hoping to make a real fast demo game with it when I finish up just to illustrate the utility of it.

Oh, and school resume this week which means all progress is about to die. AWESOME.

Untriumphant Return

Oh what a surprise, still working on ikadb. Started on it again this week, though prior to that WIP wrote out the majority of the database-side code. To be completely honest doing this kind of application programming bores me stiff and also involves a lot of trial-and-error with wxPython so progress is retardedly slow. So far it sorts out the models into parent and child (with children capable of belonging to more than one parent though there's really no application for that) and then lets you choose a parent model to work with and generates the pop-up menu based on its children. That's it. Other, future differences from past versions of this includes that it'll generate a table-style GUI for working with the data instead of an actual table. I am gradually slipping into "oh fuck it, I'll just make it work and to hell with it working well".

In other news I started a new project to avoid entering the new Verge contest (codename Delta t), only to have a desire to enter the contest anyway with another game. Great.

Nothin'

Ain't gonna lie, I got nothing done this week for all intents and purposes. I have decided on a few changes about how to do ikadb, though. Firstly the database part of it will be more modular than originally considered- the ika implementation will use sqlite but if I want to switch over to something else it should be simple. Secondly, I'm keeping the backend's name as GRAPES rather than calling the entire project ikadb. Following that, the program itself will be able to run independently of iked. Simple fact is I want to take my tool with me when I have to depart from ika without having it too heavily tethered. Using separate Python code to define data types might be a little awkward but it'll do.

Aside from that I've done some consideration and decided that a more demo-oriented approach (as the original Gruedorf rules promoted) is probably a good idea. While it may not be the most logical approach in programming, the human side of it is much more inspired when it sees actual progress instead of theoretical progress. So expect posted builds from this point on (at least, if I can find web space to put them on).

The last few Gruedorf posts (notably grue's and overkill's) were remarkably more inspiring than usual, not that this actually promoted me to do much of anything, but I'd still like to take note of it. But since this is an awful filler post of "really I'm doing something guys honest" I might as well fill it with more filler in the form of the Gruedorf anniversary posts that a few others have done.

When I started this blog I was restarting Contrivia from scratch. Skip a year and we now have an almost-finished Contrivia battle system/editor (the second version of it, the first being pre-Gruedorf) with most of the documentation and around 65% of the art, a now-discarded partial version of GRAPES, and a finished Magical Unicorn Adventure.

That's awful. Contrivia still being so far away from being done is awful. Not having GRAPES done by now (and having to restart it) is especially awful. Magical Unicorn Adventure probably having lost the contest because we stalled starting on it for two months is awful. This is terrible. It's a mess.

V. little

Currently playing Mother 3 and progress is very difficult to obtain since if I had to describe this game in a sentence it would be: It makes me want to stop making games.

Otherwise, more planning on ikadb but no real progress. Between playing games, school, and worrying about the ever-nearing contest results...yeah. Awful, really. 

Maekin' Gaem Maekin' Tools

I was sort of worried about this before I ever joined gruedorf. It's inherently against the way I work: I burst between months of nothing but working and months of nothing but doing nothing. But at this point I don't care all that much about gruedorf in general so, whatever. When Contrivia is released I'll probably take a much longer break to really skyrocket that fail bar.

Nothing exciting this week. I resumed work on GRAPES this week. Mostly rewriting it from scratch since the previous build was mostly me seeing how to do it in wx. Major changes include it being built as an iked (ika's future IDE) plugin, using sqlite instead of a custom format, and a few general architecture changes relating to things I didn't think of last time.  As such, it's being renamed to ikaDB for the time being.

Right now it's very much early with a basic design doc and the beginnings of pseudo code (trying to do it for a personal project for once, it'll be interesting to see how it turns out. So far it seems much easier to deal with wx when you don't worry about it and just write your code the way you want it without considering it heavily).

Considering this is the third time I've started this project I hope I actually finish it this time. I just don't relate to application programming as well as game programming. But the general implications of getting this done are enormous for me and probably other game makers that I just cannot resist trying to get this thing out.