Brick Atelier 0.83 released

Download link:

http://koti.mbnet.fi/paulkp/brick/brick.htm

Brick Atelier news

It's almost ready for release. I still have to solve the editor pixel size problem, but I guess it's going to be quite easy to limit the max size of editor pixel when the tile size is getting too big.

This is the current development version. As you can see there are some changes made. The UI, while still trying to fit everything in one screen, is less crowded. I also spread the information about tile id which is now in bottom left next to the tile strip and there is now a new information screen that shows things like location and color values. I'm planning to move the brush icons at the left side of palette area, where that empty space is. Then the vast empty area is reserved for the editor tile and 2x2 real size tile, tile copy and clone brush.

Grid intensity

There is a grid intensity value in Brick Atelier. It's of course cooler than regular grids, because it's using the current pixel's color and darkening it. I wanted to add an adjusting option for the intensity, but the current dialog system was unable to handle that kind of adjusting. It was the way dialogs were constructed, using values and buttons as pairs. Buttons were linked to the dialog in Dialog_Set class. But then I realized that with more complex dialog items it was kind of difficult to set the locations of buttons.

I refactored the dialog system by adding buttons in the individual Dialog_Item class (a Dialog_Set is a list of Dialog_Items). Now, I hope, it's easier to add different dialog types. Refactoring this one was hard, and easy. Easy in a way that I have learned to write modular code and I only needed to change Dialog_Set and Dialog_Item classes. Everything else like setting up the dialogs and processing them didn't need any changes. That's the bonus you get from writing good public interfaces.

7DRL failure report

I made some stuff for Teemu 1.3 and the week started nicely, but then I was distracted by setting up a DAW for music making. From the demos I tried I liked Ableton and actually found a Lite version from my M-Audio keyboard package. So it didn't even cost me anything. There is a hard limit of 8 max tracks (or instruments) but if you keep things simple it might be enough.

I think I'm going to continue with Teemu, because it was a good start towards version 1.3.

The player

I'm in process of rewriting some stuff in Teemu's data-driven engine. The big question is how Creature and Player classes are organized. This far I've made "quick hack" solutions and wrote some checks inside the Creature class for the player. It makes some routines player only and it's bad from data-driven point of view. So I'm trying to rewrite those routines. Let's get an example. When someone throws something at enemy there is no way to determine who threw the item so it's always the player. There is a also a chain of routines leading to Level class without any way to determine the thrower.

The strict way to do shit is make Creature class routines generic enough so they can be used by the player and other creatures without any kind of special checks. Then use virtual routines to override Creature routines when the player needs something special. This is what I need to do now to prepare creatures for more sophisticated AI routines.

The pirate week

7DRL starts tomorrow. I'm probably going to participate with the next version of Teemu which I know will not be done in one week. But let's give it a try. I'm stuck in Kaduria (as well) so it's nice to switch project for some time.

The task of creating a custom role-playing system for Teemu doesn't look that difficult, but I guess it is. It's mostly the balancing and how to balance stuff with... other stuff, mainly weapons and armour. I have a cool idea about how to use armour, but no idea how it will actually work.

The second thing is trying to create a data-driven engine for all object types so you can like create new items and touch only the item type data and class. That way I could add insane amount of object types and surprise everyone with a new major roguelike.

Teros

Solved the problem with scrolling and offset, for most parts anyway. Now I'm trying to figure out how to implement the game system I planned before. The biggest problem is how to determine the values for each creature. It matters because with clever planning it's possible to determine some values from simpler data, such as the main type of the creature. If something goes wrong it's annoying to fix data. I'm not even sure about the game system itself. I need to write a simulator for it to check out what kind of values it will spew out.

Planning a role-playing system, even a simple one, is not an easy task. You need to get stuff right to give meaningful values for different types of creatures and also items that are involved in combat. Teros will be the hardest thing to implement for 1.3, but it will bring more role-playing feel in the gameplay.