Entries in combat (3)


10/26 Progress + Pokemon

Been really busy this week, mainly with doing a lot of modifications to the combat system architecture due to our game designer's awesome design changes. I've started using Visual Paradigm's free uml tool to organize the relationships between sub-systems (e.g. if the weapons system goes down, the individual weapons can no longer be used in combat). I'm glad I'm going this route instead of jumping straight into the code as even the diagram needed design changes after discussing it with Schrag (we had some pretty long debates on how weapons should function).

Other than programming, I've been having fun playing Pokemon. I didn't think I could get into it again after playing most of the previous versions, but they've made some great improvements to the game such as

  • pokemon level up faster
  • easy to improve your pokemon (e.g. super training)
  • get equipment to move faster earlier in the game (rollerblades, bike)
  • much larger variety of pokemon to capture
  • access GTS from anywhere

The only thing I really don't like so far is that Fennekin evolves into a lady with a dress on :-/ not sure what the appeal of that is supposed to be. I immediately switched to a Charmander as soon as I had the opportunity - no regrets! I now have an awesome Charizard.


Combat Design Part 2

I implemented the effects system, using for testing 1) 2 skill-based and 1 equipment-based effects and 2) effects applied to targeted enemies and the player. Most of it working well, though this week I need to revisit how effects are created and set up - a problem I ran into is that I wouldn't necessarily have the variables needed at creation time (e.g. "what is the player targeting now, and is what they're targeting valid?").

One thing I've learned is that sometimes even obvious things aren't always clear from the start - Josh had suggested calling a setup function to verify the game is in an appropriate state (e.g. the player/enemy does indeed have something targeted, so look at x). It's guaranteed that if they targeted an enemy, it'd be valid since all enemies are space entities (including the player), regardless of they're a ship or a space creature. From there, I can look at more information about the targeted enemy. Wow, problem solved.

In our weekly meeting, I presented my progress to the team. They seem to like the direction it's going in, though with the new, real-time mechanics, I've been requested to implement a pause system. I've heard that implementing pausing in Unity 3D is a big pain and that one should avoid changing the Time Scale. Thankfully there's a great library for that on the asset store that supposedly avoids the headaches of time scale. As a bonus, it's programmer friendly, so I should be able to take advantage of the API to do more complex pausing if necessary. If all goes well, I'll be able to integrate it with the rest of our systems this week.

Besides requests, we also discussed ways to add depth to combat. There are some really interesting ideas, but I'll need to think about them more and try them out in-game. Unity 3D has been a godsend for trying out ideas relatively quickly, so I'm really, really excited to see where combat goes from here.


Combat Design

Combat design has been very much a moving target, and I've have to combat (excuse the pun) both incorportaing new features, and refactoring existing code. I wish I was a master of architecture and knew all the systems we'd need from the get-go, but I know that's not possible with 1) iterative design and implementation and 2) doing a lot of things I've never done before.

One big thing on my mind lately is if combat should be real-time, active-turn-based, completely turn-based. Originally we were going completely turn-based - I thought turn-based was a good idea to make combat feel really strategic, but when I played the prototype, I don't think it really gave enough of a sense of urgency for the user. That's probably partly due to missing features, but also with the combat I'm trying to create, the user wouldn't necessarily do a lot in a single turn (restricted by power meter). Because of all this, I had to click on the "end turn" button so many times. It felt unncessary and not very exciting.

Just this week I decided to try out a real-time, recharging meter. Every time it filled, it gave the player a couple of power points to use for an action. In addition, enemies would have their meters recharging in the background. The player would never be 100% sure when the enemy would attack next. So as the player scrables to decide what to do next, the enemy will continue attacking. In addition, the strategy is still there - users still have to consider whether they should wait for more points; use up some of their points; or use up a lot their points (different actions use up different amounts of power points). Much more interesting.

Another big thing on my mind is as I start implementing new systems (e.g. Effect System for buffs/debuffs), I wonder 1) How should it work? 2) How should it interact with other systems? 3) Who should be responsible for using it? 4) What, if anything about the system, should be a Monobehavior? To help me in answering some of these questions, I've done some initial research to see how other game developers have implemented it for Unity. It was quite enlightening, and I now have a basis for a proper system.