Brick Atelier development

Well, now it's time to continue Brick Atelier (former Stile), a sprite editor made for Kaduria. The thing is that I'm using it to draw all tiles and it's missing a key feature: import. I need that for some tiles. I haven't touched BA since last year so time is really flying fast. I had a new idea how to refactor the user interface. It's a needed feature for the release of new version. I don't mind about GUI elements getting in weird places but it's better to fix that for actual release. BA has 10490 lines of code so it's actually quite large project. The main reason for the large size is the custom GUI I made myself. Only the Windows file dialog is not a part of the custom GUI.

Feature days

I try to fix one feature or bug per day. It's a lot for the recent development speed. Oh, Duke Nukem Forever is delayed which is "good" news since I "promised" one level demo (or something) released at the same time when Duke gets out. But I somehow know it's not going to happen. I mean the release of Kaduria's demo.

Things look better now though. It feels like everything I do now is solid, something that doesn't need refactoring later. It feels almost sad to say that after 453 years of development.

The pit problem

A pit in two-dimensional game can produce unwanted logic problems. It's lower than ground level so there should be support for third dimension. But sometimes there isn't and that's the problem in Kaduria. Let's say you push a boulder in the pit. That's easy. What happens if there is something in the pit already, like another boulder or a monster? They don't fit in the same pit, but there is no way to put the boulder on top of anything, because there isn't support for third dimension.

I guess it's time to add that support. I really tried to go with only two dimensions, but it's impossible with the level of complexity Kaduria has.

Notes

Been fixing some difficult parts in the source code marked with note: comment. The overall development is also getting faster all the time. It looks like I have passed the obstacle of not knowing what to do. I have concentrated on dungeon generation to get it ready. The main idea of the generation is first create simple structure and then decorate it with automatic stuff like plant growth and decay. I'm quite happy with the current speed of development, it really feels like something is happening and I just have to fit some pieces in the right places to get this game ready for first 0.0.1 alpha.

Journey onward

About a week ago I got a second flu. This one was easier and I'm getting better, but I have been sick for month and a half! Today I tried to continue Kaduria, but it seems to get more difficult all the time. The source is full of problems that need to be fixed, but many of them are scattered and need fixes in many places and I'm always confused about how to fix problems that are like that. Then there are "impossible" features like sleeping. For some reason I wanted to show a graphical camping scene when sleeping, but it's just impossible, because monsters are moving and when they move the gameview is updated... maybe if there was a possibility to check the sleeping in one place before updating anything then it would be possible. But I think I'm going to settle for easier solution and show only the gameview when the player is sleeping.

Terrain refactor

It's funny how I have to fix the old school design yet to this day. I guess it was worse than I thought. I'm speaking of the terrain/object distinction. In the old model some terrain tiles were object-like and there were a lot of terrain tiles like that. In the new model objects and terrains are separated, leaving some basic terrain types. This doesn't sound too bad until you find out that every action routine must be rewritten, things like digging and kicking. I have found it hard to create a solid way to interact with the environment and limit the use of special case code.

This is where data-driven approach will help, but it doesn't happen by itself. Also, it can be possible that you start to refactor the data-driven implementation to achieve more detailed system. I think my plan with plants was too detailed and I need to stick to basic stuff to get something done in reasonable amount of time.

For a while I wasn't really sure what the hell I'm supposed to do next, but at least now I have this data-driven terrain system to create.

Searching

In order to search you need to have something hidden. Traps and doors are obvious... wait, doors aren't obvious. I have problems trying to figure out how to hide the door. Will it look like a wall? How is this wall tile handled, is it a normal terrain map wall? What happens if X happens to that wall (which isn't a door). Stuff like that.

Then there is an issue with hidden items. At first they were in a special list in the level, but I realized that handling hidden items will be more logical when they are inside the object which is hiding them. So, in order to get hidden items feature I have to write (possibly) a virtual mechanism for them, adding another type of container for hidden items. It could be easy now when container ability is ready, but you never know.

I'm also planning a data type for the search routine. It will continue the style I've been using in data-driven types. I have developed a certain kind of routine in programming for them so the data type will be quite easy to do, but it's always a matter of how it will be used in the rest of the source code. Programming data types for stuff like that may sound strange, but I'm always trying to reduce switch-case programming, because modular data types are so much easier to extend when you need to add something new, and they are also modular, meaning that when you get that module ready you can pretty much forget it and focus on other parts of the source code.