Week 5

This is the second week before the game has to be submitted for marking! And, apparently, the perfect time to take a break according to my body. Regardless, I was still able to make some solid progress this week. The expeditions are more or less done and I am very happy about that. This should mean that the game is now fully playable and I am very excited to present it to my friends for testing. Testing is definitely needed because I am not quite sure how well the expeditions fit into the overall picture and how they feel at different game stages. I also added the mechanics of food and hunger to the game. Now monsters can get hungry or hurt, and die. It was honestly more heartbreaking testing all that stuff than it should have been.

First, I will explain how the expedition works in the game. An expedition is simply a very special room with 2 spots for monsters to go into. I am planning on adding functionality to improve how many monsters can go on an expedition in the future. When there is at least one monster in the room the player can send the monsters on an expedition by pressing "e" (will be changed in the future). When the monsters go outside they collect every kind of resource but the main focus is food. The monsters will run into different events depending on how long they've been outside.

Some events are harmless and don't give any reward, some events are harmless but to get the reward you need to pass a skill check, and some events can be dangerous to the monsters. There are different skill checks for different types of events. Those would include an intelligence check, speed check, power check, and strength check. Strength checks and power checks combine the strength/power of all party members, while intelligence and speed checks look at the average of their respective values. Each type of monster also has its own carrying capacity which affects how much stuff the party can collect before coming back. The idea behind having so many different checks is to force the player to mix and match monsters and create their own strategy for gathering resources. More intelligent monsters will be better at realising when they should fight an opponent and when they should back off, while strong monsters can defeat stronger opponents and it is up to the player to decide which approach is better. 

The implementation side of things is rather bulky, so to keep the devlog relatively short only the main aspects will be highlighted. The expedition class is another manager class. It mainly manages WHO goes outside and the general state of the expedition (exploring, going back, staying at home). It's also responsible for the timing of the events. It has another class inside of it that is actually responsible for the selection of the events, I call it the event generator (even though it doesn't really generate them). It has a "main" function that is called to get an event based on who is in the party and how long they've been out.

While developing the event generator I quickly realised how much work it is to implement events even if you already wrote them down on paper. This led me to create another class I call expedition event. It is meant to simply make my life easier by containing and handling big blocks of text so that I can basically copy-paste most of the stuff from a word file. The expedition event has links to two other expedition events inside of it, one for when the party passes the skill check, and one for when it doesn't. It also has a skill check function (as a parameter), the reward, and a bit array to represent when it is appropriate for the event to appear.

A minor downfall of this system is that most of the events will have most of their parameters as null as most events don't root into other events. This will waste some memory but since I don't intend to write thousands of different events that is a sacrifice that I am willing to make. Another, more significant downfall, is that an "event" will actually be made up of multiple events and they will all have to exist for the system to work. For example, if I was to make getting coffee an event it would go something like that: The person gets up to have coffee. [PASS INTELLIGENCE CHECK] They walk around the coffee table and successfully make themselves coffee (gains coffee) [FAIL INTELLIGENCE CHECK] The person hits their toe on the coffee table and cries (loses health and self-esteem). It would definitely seem like all of that should be one event, however, in my implementation, it would actually be 3 events linked together. Getting up is the first event. It would have a skill check and both pass and fail events assigned to it. It will provide the generator with the right next event to go to (pass or fail) and both of those will not have any skill checks, pass, or fail events assigned. That's how the program knows that they are the final events in the sequence. Unlike the first event, they will also have a reward (as much of a reward as losing health is).

Lastly, the thing that wasn't yet mentioned in this devlog is the raids. The work on them was started but paused almost right away. I realised that I was not satisfied with my plan. Initially, I was going to make raids a random event that appears once in a while. After thinking for a bit I realised that it would be rather blunt and boring if I did end up implementing it this way. The better idea I had was to make some sort of a fame system where the more loud stuff the monsters do the more heroes get interested in eliminating the hideout. In theory, this does not sound too bad, however, the idea needs a lot more thought put into it.

The player has to get stone to get energy to get more monsters to get more stone and more energy. That is the premise of what the player is doing inside the lair. The player also has to get food so that the monsters inside the lair don't starve. The player can't get it inside so they are forced to go outside. That is how expeditions connect to the systems inside the lair. However, I couldn't come up with anything that will connect the fame system to the other systems. The reward would go up as the danger goes up, so, being more daring would mean more food efficiency (due to travel time), which would mean more monsters at the same time. This is not a requirement however. The player could keep a low profile if they play with fewer monsters by just going on shorter expeditions. This isn't exactly what I want. As mentioned before the idea needs more thought put into it.

I am unsure if the raids will make it to the assessment but the next week I am planning to make a tutorial (very important). The feedback from last week basically sums up to the game feels too long (should be fixed with expeditions) and the game is very confusing (has to be fixed with a tutorial). I would like to add the raids if I could to complete the picture, but if it will be between raids and a tutorial I'll implement the tutorial first.