Kaduria

[Krice]

I have to do something about the item weight data. I had an idea to use material and the size to calculate weight, but it's not that simple if you have only one type of size. I guess using some kind of 'shape' data would give better results, but I think it's difficult to figure out the volume from a shape unless you just use manual values. So it seems I just have to use manual weight for every item, which also is super tedious, because you have to guess how heavy everything is. I think for this reason some games use imaginary units for item weights, like "stones", because it's just way easier than using actual, realistic weights. I'm thinking about doing the same, but with internal "scientific" weights to calculate some light-weight (pun intended) physics calculations etc.

 

[Krice]

However, I am now thinking that an abstract "shape" could work, if you had volume data for each size (they are also abstract, not exact). The proper volume could be determined by using real weights of items and matching the data to them. For example if you have a "stick" shape, you could use that to determine weights for stuff like arrows, spears etc. and maybe get close to realistic values. The size in this case would refer to each shape type as a scale.

 

[Krice]

Trying to get the internal clock (date) to work with turns. It turns (...) out that if one second is one turn then a month in game time is about 2,5 million turns. The "idea" is to not call the complex time advance routine each turn, but only when you do some less time critical stuff like check out your inventory etc. I guess you can advance the clock slower (or in this case I think faster?) if you divide the amount of turns with some value. It's funny I didn't see this coming, but being a genius I have no time to think about basics like this.

 

[Krice]

The bug number 222 is going to be legendary no doubt. When you kick a stack of items on ground it's supposed to remove one item and make it fly. This seems to work for items that I have tested, but for some weird reason a regular dart does something different. The dart seems to fly away just like other items, but the rest of stack under it disappears and the kicked item can no longer be picked up (you can still see it though). What makes this even stranger that when I look at the list of items on level, both the invisible stack and the dart that was kicked are in the list, which would indicate that they still exist. I tried to create a stack of poisoned darts and they work, so it seems to be only darts. What is so special about them?

 

[Krice]

The bug 222 was (still is) more boring than I thought. When you kicked an object it was destroyed before it was sent flying, so it was just a problem in the chain of events. I made the routine simpler by removing damage from the initial kick so when you kick something it always flies and is then destroyed on impact. The bug is not yet fixed, because the destruction itself is buggy and doesn't remove the item from level, for some reason. Also, this bug was partly a result of a long function that did more than one task, a classic reason for bugs.

 

[Krice]

While writing a class design doc and refactoring the asset manager I realized that you can make a "database" out of menus. There are tons of menus in this game so it's quite practical to use a database for them, that has the name and size etc. for the menu and then it adds the items for the menu. That way you don't need to create menus everywhere, the menu database will handle it. I've been using data driven style for other stuff, but just didn't think menus could be implemented this way too.

 

[d1r]

 

[Krice]

The menu database .cpp is 138 lines of code with comments (it has 6 menus now) and when you add a new menu it adds 7 lines of code in a best case. Refactoring is easy, you just have to add the data of some menu, remove old menu code and that's it. I don't have to do everything once, I can replace menus when I feel like it.

 

[Krice]

I've been thinking about the main gui, because it looks so bad. One funny idea I was thinking about is make the gui look like it was ascii... Then again the font size doesn't match the tile size. The main font size is 12 x 20, and the tile size is 32 x 32. The tile size was previously 24 x 24, so with adjusting font size to 12 x 24 would have been great. There is also a kind of problem with 32 x 32 tile size, it's too "small" for modern resolutions. Would be funky if the tile size was 24 x 24 and then doubled to pixelated 48 x 48 tile. This is difficult.

 

[Krice]

Creating a list out of classes at this point points out the fact that it's not about the source code or structure or anything like that, everything that makes the game work is just content. In other words stuff.

 

[Krice]

I think my medication is helping me to focus better than before. I've seen it in other things as well, there is less brain fog. It feels like the medication has finally began to kick in after 5-6 months I've been taking it.

 

[Krice]

Anyone knows or using some kind of software (UML etc.) to model classes? I think it would help to create a class diagram and at least filter out classes that don't need work vs. classes that are unfinished. VS has class diagram "tool", but for some reason it doesn't work and also you can't do anything with the diagram once it's done. I tried to find free UML software... I would actually pay for a working software, but I'm allergic to subscription model which most commercial software seems to use for maximum profit and greed.

Edit: never mind, I think LibreOffice Draw is good enough for this. Imagine if you had something like this in the IDE itself, you could view class hierarchies and tag classes. In this I have the Point/Plane -class hierarchy (Point is just x, y and Plane width, height -variables). Blue classes are not ready for whatever reason.

 

[Krice]

So, I did adjust the font size to 12 x 24 and also forced everything to that grid size which is great, because then you don't have to think about placing stuff in pixel level which I find pesky. I had to change the gameview size to 27 x 21 tiles, because as currently the tile size is 32 x 32 it's only possible to use certain sizes that are exactly divisible by 24 (or 12). The "result" is kind of "text-based" GUI with just some graphics. You can see it in this latest screenshot, the black borders around gui areas are 12 x 24 pixel blocks. I think black borders look ok, I guess you could use decorated borders but it's temporary for now. The vertical lines in right and left side stat areas are also for checking out everything falls into the grid.

 

[Krice]

I've been writing descriptions for game objects. It's really helpful in case you can't figure out what you are looking at based on the tile graphics. Incredibly enough only some constructs and terrain tiles are missing a description.

 

[Krice]

The message system is so rigid that sometimes is fails to work properly. I have a problem with drinking from fountains etc. If the fountain dries up the message tells "You drink from a dry fountain", because the liquid extraction routine changes the fountain to dry and the message is using the object handle... The solution is just manually create a message in this case, because the message system just sucks. It's probably the single hardest thing to do properly, so it would work in any situation without having to manually construct the message everywhere.

 

[Krice]

Drinking potions has the same bug, when you drink the potion is changed to empty one and tells "the empty potion is now empty." I'm just going to remove that from message routine using the object handle and switch to manual style. This confusion actually partly comes from OOP in a way.. because when objects change you can't easily put that in the right place with something like messages etc. That's why actually I like to write long "C-style" functions for anything that has to do with actions and logic (has if-statements etc.).

Fixed with a manual, procedural C-function:

void show_container_state(const char *kontti, int state)
{
    string s("The ");
    s.append(kontti);

    switch (state)
    {
        case Container::Empty: s+=" is empty."; break;
        case Container::Now_Empty: s+=" is now empty."; break;
        case Container::Almost_Empty: s+=" is almost empty."; break;
        default:
            s+=" is now in a quantum state.";
        break;
    }

    message->Write(s);
}

When I was testing that I found out when you drink lamp oil it shows that quantum state message. You always get a new bug when fixing one.

 

[Krice]

Fixed all potion related bugs. Thinking of fixing rest of the bugs, it's an option when you don't want to work on important stuff like RPG system etc. There are 10 open bugs so not that much, but some of them are quite interesting like that kicking bug where only one item type seems to fail, for whatever reason.

 

[Krice]

The kicking bug... I can't understand how it works. There are two main issues, first one is that the item breaks when you kick it, or it seems to break, then it changes back to the original item, then starts to fly. Even when it hits the wall it doesn't stop in the loop that handles it, but the object movement routine stops it. The collision check doesn't work. When the object breaks it can't land properly and the dynamic lighting routine fails. It has to be some kind of memory corruption, because nothing works as you would expect.

 

[Norfleet]

Drinking potions has the same bug, when you drink the potion is changed to empty one and tells "the empty potion is now empty."

But can you get ye flask?

The kicking bug... I can't understand how it works. There are two main issues, first one is that the item breaks when you kick it, or it seems to break, then it changes back to the original item, then starts to fly.

It seems to me that a lot of your issues spring from the fact that an object's state is changed by an action, but the message or reaction occurs before the state change. Like your potion-drinking ones change a flask to empty first, then notify the player using the new namestate of the object. Your kicking one is probably similar.

One of the rules I've used in a current project is that objects can never have their state changed externally: Things get hit by shrapnel, not the other way around. So if I kick you, this doesn't actually do damage, you getting kicked is what causes you to take damage, because I'm an external actor and therefore cannot change your state. This prevents Gruesome Thread Accidents, as everything that is happening right now is read-only and only the owning thread responsible for updating an object for the next tick is allowed to actually change it, and it can only write into the state for next frame, not alter the current state (which is in the past).

 

[Krice]

I don't know what I just read, but the bug was quite "obvious" after all. When you kick an item it's placed in a list which is processed later, so I had to return from the function right after that to stop anything else happening to the item when you kick it. I think there could be even better way to split the routines to kicks that make the item fly and another which doesn't, it just kicks the item. Or maybe limit the distance to zero when kicking a heavy item, so everything would go through the same routine.

 

[Norfleet]

I don't know what I just read, but the bug was quite "obvious" after all. When you kick an item it's placed in a list which is processed later, so I had to return from the function right after that to stop anything else happening to the item when you kick it.

What aspect of the list is processed later? I mean, objects should be capable of having multiple things happen to them. What happens if two actors kick an object at the same time from different angles, for instance? Both kicks should obviously count, but if you only count one kick, which one? And is all this being resolved in a single thread, forming a performance bottleneck when tons of things are kicking other things?

 

[Krice]

The idea of the list is that it contains all the items flying in that turn, but I guess player and the enemies have their own turns.. anyway, there will be more than one enemy throwing or shooting the player so those items fly at the same time. I don't know, if you think about timing even in a turn-based game it can get funky.

 

[Krice]

I'm working on "physics" stuff, finally, after 69 years... Always thought it would be a nice idea, but in practice you have to make it simple and less physical for the creatures or they would just die easily. This is related to flying items which are going to be more lethal at close distance and lose power when trying to attack from too far away.

 

[Raghar]

Drinking potions has the same bug, when you drink the potion is changed to empty one and tells "the empty potion is now empty." I'm just going to remove that from message routine using the object handle and switch to manual style. This confusion actually partly comes from OOP in a way.. because when objects change you can't easily put that in the right place with something like messages etc. That's why actually I like to write long "C-style" functions for anything that has to do with actions and logic (has if-statements etc.).

Fixed with a manual, procedural C-function:

void show_container_state(const char *kontti, int state)
{
    string s("The ");
    s.append(kontti);

    switch (state)
    {
        case Container::Empty: s+=" is empty."; break;
        case Container::Now_Empty: s+=" is now empty."; break;
        case Container::Almost_Empty: s+=" is almost empty."; break;
        default:
            s+=" is now in a quantum state.";
        break;
    }

    message->Write(s);
}

When I was testing that I found out when you drink lamp oil it shows that quantum state message. You always get a new bug when fixing one.

Base object is potion, not empty potion.

 

[Krice]

Anyways.. one of the biggest problems in this project is the game message.. thing. It's giving so much trouble, because it's so complicated. In this I should be using some kind of actual database or scripting for message data, but I don't even know how to approach this problem. Maybe I should make some kind of plan and try to find out the best way to add more complex behavior like distance and visibility as modifiers to what the message is.