SDHAWK'S PROFILE

We've been working on this for awhile so I'm pretty excited to start showing it off. Basically, it's a tool for automatically generating a user friendly GUI for manipulating an ika game's data. After reading it I'd like for you to consider the following questions if possible:

-Is the presented interface adequate compared to the tools you're currently working with?
-Bearing in mind that you'd still have to program all the core functionality of your game, does a tool like this make the intimidation of such a task any less? In other words, does this tool make you consider trying out ika to be more appealing?
-If you're already used to programming most of your games, does a tool like this appeal to you and make you consider switching to ika for it? (Remember that the GUI generated is based on your own code so it's very flexible)

Of course the ultimate goal of this is to eventually make it possible to make an ika game with very minimal programming, but that's a long ways off requiring many more tools and a game library. Still, we're curious as to whether this makes ika any more appealing to you in the present. Thanks for the responses!



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.