Cardboard Wizard
Update 2
Good news everyone. I've finished the game!
On a serious note, I have been fantasizing about finishing this game as of late. I guess working on it for so long was bound to chip away at some part of my psyche. This post is a bit late. I had to move and do some cleaning the last week of last month so did not do much deving for a week or so
. But excuses aside, where did we leave off.....
Recap
I set out to accomplish some mile stones. Specifically the ones in the first post. For the sake of my mental health, I decided to tackle only a few of these instead of all at once:
- Finalize Player Controller
- Improve AI Combat Behavior
- Add Player Ally Character
Player Controller
The player not only has control over their avatar, but over an entirely separate entity within my games ecosystem(cardboard). So for this part, I had already implemented the majority of the player characters cardboard capabilities(say that 3 times fast)
Summon - conjure up cardboard element(limit is 3 at the moment)
Strike - to swing it around to bludgeon people
Release - to toss a cardboard element about relinquishing control of it
Recall - to call a discarded cardboard entity back into your sphere of influence
I also made a selection wheel in order to select which ability to use.
The aspects that I needed to finalize were related to the Release and Recall actions.
The player is able to use the release ability on cardboard and to attach the cardboard to other entities. the recall ability allows the player to retrieve the box.
Unfortunately the "Attachment system" I created was convoluted(my middle name) half broken and coupled to all hell in the codebase. Luckily I've rewritten it, and it now works better than ever. I decide instead of having entities manage their end of the attachment relationship, I would delegate the handling of that relationship entirely to a separate Manager Object. This object allows attachments to be formed when an attaching box intersects an attachment point and handles the dynamic of that relationship depending on the hierarchy of each entity in the relationship. Since attachments are a two way relationship, this object also allows either end of the attachment to break the attachment, which will be useful in different circumstances.
(left) Rock in box. (right) Box on enemy head(WIP)
there are only a few things left to implement for the attachment system and then the player controller(atleast this iteration) will be finalized.
Improve AI Combat Behavior & Add Player Ally Character
I decided to group the last two together because they pretty much tie in with one another. Essentially I am working on both an enemy AI and an Ally AI at the same time. They are 95% identical in regards to the code they run on. I just created a different Sub-controller for The Ally Characters overall Goal/State handling since they can be in additional states that enemies cannot. I will probably have to do the same for Bosses later.
My AI essentially use a state machine in conjunction with rules based decision making.
Example of one of those rules:
"rule": {"target_in_view":true, "target_dist_lesser":150.0},
"action":"avoid"
Rules are pretty simple and the state machines dictates which rules the AI evaluates before coming to a decision.
The problems i needed to solve in regards to AI were two fold for this month. One being that AI did not have a good way to manage multiple targets, i.e the player and the ally. The old method i used was to have the AI only be aware of potential targets upon them entering the AI's sensor field. This was limiting because targets were easily picked and forgotten when constantly entering or exiting the AIs field. I decided it made more sense for all potential targets to be fair game(no pun) from the outset. And The AI's state machine would dictate what targets for both the enemy and ally character AI depending on the state they were In I also gave current selected target a higher priority than other potential targets during the evaluation process. So Far it is working fantastically. Though there are others things that need to be implemented, which brings me to problem two that I need to solve. Defining what constitutes combat. Currently I have the following listed as drivers/initiators of combat
Player aggros an Enemy that is in the environment
In Game Event/trigger
If you didn't notice, I did not list the players ally as a driver of combat. That is probably subject to change eventually, but my initial reasoning is based on the idea of the players agency as well as being informed on the current state of players hating to have to "escort" an npc that keeps triggering everything from a squirrel to a slime to level 100 enemies(in your average party based rpg lol). But that last point not be relevant depending on how I define the relationship of the player and the ally in the context of gameplay and the narrative....
As for the Ally I have pretty much created a skeleton for them(figuratively). I need to add combat capabilities and animations(as well as finishing their design....will unveil in the next devlog...or 2)
Anyways, so these last few weeks have been anything but eventful in regards to working on my game, but it does feel like i'm getting closer to that fabled release. Lets see if I can have the game out by christmas
I will hopefully finish most of the above by the end of the month then I will start working on these things next:
- Add 3 Additional Enemy Types
- Add Important Channeling Mechanic
- Create Maps For 3 Areas
I've actually started planning two other enemy characters as well as sketching level design for an area, but i'll save those for next time.
Also i'm still figuring out OBS so forgive me for lack of gifs....
Community
