Monster spawner

It's almost ready. With monsters there is need to filter more powerful monsters to certain type of levels. I'm not yet sure how to do that, but maybe adding a generic level theme type (cave, deep cave, outdoor level, etc.) and then select monsters along with the individual terrain type. I could also try to make monsters more or less data-driven with maybe some special cases that are possibly easier to handle directly. There is only 25 monster types in Teemu so there is plenty of room for new monsters.

Before I start wildly adding monsters I need to look at the monster family class and see if it could hold more basic type data for monsters, taking some data out of the monster type class. That way adding a monster requires less data input and a longer list of monsters is easier to maintain.

Item spawner done

The item spawner is already creating more interesting set of items which are a lot more unpredictable than were the old level theme based items. There is a resolution problem in finding free places for objects. It's a classic chicken-egg -problem: if you first find places for objects it's going to include unwanted places where some objects could be created. For example monster search includes water tiles where some flying/swimming monsters can be created, but not the land crawlers. Then again, you can't select a monster first and search after that, since there is no guarantee that such place exists (not all levels have water).

The solution could be two or more search patterns combined with specific set of monsters for that place type. I can think of four such scenarios: terrain/cave, forest, beach and water. Maybe the level creator could actually determine those places automatically by searching and counting the size of each area type. That's surely something to try with monsters.

Spawner

I've started to implement the spawner for items in Teemu. First the spawner collects data from items and determines where items can be created. When the level is created the spawner is scanning the level terrain and creating random items selected from the filtered lists. There can be factors like where the item can be placed and how rarely the item is made and other stuff like that. With the spawner the creation process of items becomes automatic and I can start to add more item variety which is one of the main features of the next version.

Messages

The way messages are handled gets complicated when the engine is becoming more generic. My plan is trying to have the responsibility inside Message class as much as possible to avoid if-code in the caller function. I've created several types of message functions from simple message to object message checking the distance and visibility to the action object and changing the message when the player can't see the action for that object. Then there are of course player vs. other object problem. At least for now most messages need to change the message structure for the player and some if-code is there. However I think I can manage them the old school way, without need to create a more sophisticated message system.

Kicking ass

Level::Throw_Loop is now generic. It came with a cost though, since some operations needed to be moved back to caller, especially deleting the object if it's destroyed in throwing collision. I have to see if it's possible to write a generic destroying routine, but I think it will be difficult.

When testing kicking with creatures I also noticed that the projectile has to be removed from the level list while it's flying. You could do self-checks, but only for some things. The list routines are buried such deep into the level structure that it's just easier to remove the object, then make it fly and after that add back to the level list. This could mean some extra Add/Remove -functions for different types of objects, but it's only a minor style issue.

It was nice to see that I could kill another monster by kicking a monster at it. The damage routine isn't very sophisticated, since you can kill a monster effectively by kicking a chicken at it. That needs some adjusting, but it's closely related to the gameplay system which is very crude at the moment. The projectile could also be damaged and even killed. If you kick a chicken at elephant you expect the chicken to take damage while elephant only gets angry.

It wasn't that hard after all, other than the bug when monsters are kicked to water: they seem to freeze there, unable to realize that they are in water.

Throwing chairs

I have moved Throw_At_Me function in the game object base class and it's not even a virtual function, mainly because it's calling virtual functions to get different types of results with derived objects. However I think the main throwing loop must be made virtual, because there are type specific things involved. Another option could be a collection of smaller virtual functions.

An example is the way object is landed after throwing. When you throw something at a big object like closed door the object isn't placed at the same place, but in front of it. The rules also change when you can throw other objects than items. This rule could be a small virtual function. The reason I need virtual functions is that I planned the base class so that it doesn't know the main type of the object. It's a small but important detail and leads to a design style where virtual functions are responsible for getting the proper result when something is done with the object. I think that's how it should be done, because the other option would lead to type-check code with special cases and that's something to avoid when you try to make a generic engine to drive the gameplay content.

Throwing coconuts

Refactoring Teemu's GO_Creature::Throw_At_Me routine to generic collision routine between two objects of any type. It has involved some thinking and five new functions. When it's done it should not be too hard to change the actual throwing loop to handle all object types. It means that in future you can throw other objects than items. The main application are smaller monsters that can be kicked away, but maybe also chests. Even doors could fly away by force like explosion.

Gui programming part 4

For some reason Brick Atelier hangs for a long time when loading tiles. That bug appeared from nowhere and maybe related to a memory leak. GDB gets puzzled of course (I'm developing BA with DevC++) and has no idea where the bug is, it doesn't even report anything. So, once again I need to move this project to Visual C++ to find bugs. The map editor is quite ok, I found a partial solution to the ellipse routine which is giving me a big headache. It's this stuff again: the world doesn't have a C++ ellipse routine that produces symmetric bresenham type (one pixel edges) ellipses in all x/y radius values. I'm too dumb to understand math in that context and unable to program ellipse routine myself. Well, maybe some day.

Gui programming part 3

Another long day at work. I have added an option to adjust the editor pixel size between 3-7, but that's all. Usually when I get some feature done I'm already adding a new one to the list. Bugs seem to work the same way. Next major thing before anything else is get rid of two fonts and create one font, better than both current fonts. That should make some gui stuff easier to create.

I don't know yet how to handle the hovering help system, because at the moment events are check only when there is some action (mouse moving, clicks, keyboard) so you can't hover on gui elements to get a popup window. I'm aware that help system would make it easier to learn how to use Brick Atelier. It's obvious to the developer, but painful to other people trying to figure out how the program works.

Gui programming part 2

Refactored the map editor of Brick Atelier, though it's missing implementation of some drawing tools. If I want to get them working I need to create another layer and a mouse hook just like in main editor. I guess it's not that hard and it's nice to have circle and box drawing routines for map editing.

It was easy to add the icon set for map editor tools and I'm glad I wrote a (more) modular icon set class earlier, because I was already thinking about icon sets for other than the main editor.

I'm programming Brick Atelier mainly at work which is kind of strange, but I have some spare time to spend and I'm just slowly programming stuff and trying to make the time fly faster. It certainly does. I don't know any other activity that makes time go faster than programming. Well, maybe it's the same for things that require concentration.

Gui programming

One thing that makes development of Brick Atelier (former Stile) hard is not only the low level gui programming but the fact that the way I programmed the "engine" was really not that clever. It's not impossible to fix the problems, but I found out it takes some work.

For example I had defined consts for zoomed pixel size and of course used them everywhere. Now I want to be able to adjust the pixel size (it's the way to make the app window smaller or bigger for different resolutions) with an option. Replacing consts with a getter for external classes is not that hard, but it's also quite risky code, because of initialization order stuff. So I need to pass the pixel size to both brush classes (which could be combined by the way), but they are allocated in Drawing_Tool class and that class could be refactored out. So making changes like this may sometimes require a lot more work than just simple replacing stuff.

This constantly reminds me about the importance of planning. When I start the next project, whatever it is, I'm going to plan it well.