Latter part unfinished (no plans for completion) [Unity] How to make a turn-based tactics game + How to create a unique, easy, and cool game architecture. Currently demonstrating scalability and reusability while adding content features.
This is an incomplete course where the latter parts of the curriculum have not been covered. However, the core content for prototyping and advanced sections is included. (Please refer to the announcement for further details.) ---------------------------------------- How to Implement a Turn-Based Tactics Game Part 1, 2 -> Basic features, basic combat loop (the core framework) As the assets available to me increased and the list of things I wanted to update grew, you can think of this as a guide for rapid prototyping. Based on the content covered in these two parts, you can infer how the updated (and future) features will be implemented. ---------------------------------------------------------- Updates -> Deepening and enriching the content built in Parts 1 and 2 cf -> Useful content for game development in this genre + alpha
41 learners
Level Intermediate
Course period Unlimited
๏ฝฅ
Edited
Issues identified after feedback on lecture content from another expert.
In the latest news, we have a variety of complex and strategically responsive states.
I told you that this could be solved by using the IEnumerator event with priority and category.
First of all, I think I should apologize. I'm sorry.
There were errors in what I said back then, and I suggested a less than desirable method in the outline I uploaded.
Today, I had another discussion with another person about this content from late lunch until the afternoon.
Thanks to that, I was able to confirm that the problem was in the solution I proposed? Or rather, in the method of applying it?
It is correct to solve it using IEnumerator with priority and category.
The context in which events are used and the up-down (top-down, where the creature directly calls the functions of the states it has)
It was clear that we had to distinguish when to do it. If there was no way, then it would be different, but if there was, then the up-down (top-down) in the creature is obviously right. It is not desirable for the functions of the states that you have to subscribe to the events of the creature (OnBefore, OnAfter, On / Attack, Damage, Death series). That was the part that you pointed out the most.
Besides that, I have to draw and talk from a person-to-person perspective? I also drew a game flow diagram that feels like a planning class, and there are too many things to do in skills (currently dividing them into player/NPC cases, selecting click targets, and executing skills). There is also a direction where skills are just executed. You also said that the category of abstraction was set large (for example, rather than putting them in at any time and automatically sorting them using priority categories, dividing them in more detail and customizing them seems to correspond to setting the category small. <- I just like the existing method better)
The overview description part is my thoughts on the things that I think would be necessary based on the scenario, so I will leave it as it is because I think such things could be of great help. The tracing direction and the decomposition and arrangement of critical routines seem okay, but those functions were event call functions;; The functions of the status that the creature itself has subscribe to the event, and instead of executing the subscription functions, they are sorted in up and down and called right away because they are its own status . <- Please correct this part and take a look.
From the next class onwards, I will make sure that there are no problems with that part!