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.


Design Changes Incoming

Our game designer has been making a lot of changes this week, and has started digging into combat. It's cool seeing your initial ideas morphed into something with more depth, but still maintaining some of the core aspects of it. Looking forward to talking about it more during our next team meeting as there's a lot we need to decide on.

I have a lot to think about when it comes to implementation. I've been making progress with the Design Patterns book (wow, could've saved so much time by reading this ages ago), and have been jumping between it and and 2 other topic books: object-oriented analysis & design (really need the refresher) and game design (it's fun!).

With all the design changes being made, I probably won't touch combat much this week. Instead I'm continuing my thoughts of how to architect all these interacting systems. I've started utilizing a mind mapping tool to get an idea of everything involved for combat, and will probably create a class diagram at some point. It'll be too easy to create spaghetti code, so I need to be cautious.



Search Is Over!

For about 2 weeks now we've been looking for a good candidate for our open game design position, and I'm so happy the search is finally over. After many messages and a few 30 min - 1 hour interviews, I learned it's really difficult to find someone that can meet all the requirements:

  1. In the same time zone
  2. Can commit a high number of hours per week
  3. Proof of good design ability
  4. Accessible throughout the week
  5. Bonus - programming experience
  6. Extra Bonus - experience with Unity 3D

Good things do indeed come to those who wait. Now I can go back to focusing on the game :)


Continuing Education

I've realized that throughout the last few years, life is a lot easier when you have background knowledge of a topic. For example, just a few years ago I didn't know much about version control or any programs related to it. I had a vague idea of it - it would help me save my work and revert it if I made a mistake - but not much else.

It was not until I worked in a team-based environment in a job that I understood more of its usefulness. You can do cool things like have one team on the core code while another team focuses on customizations, and combine them as a release package. You can even split the code when you're ready to work on a new feature, and blow it away if it turns out not working out.

That knowledge not only help me set up version control at home, but I was also able to help others. Recently a co-worker requested help setting up version control, and I was able to do so in confidence. Even though I had questions, I knew what types of questions to ask.

Just last night, I was playing a demo of Ace Attorney on my NDS next to my bookshelf, and I casually looked over and saw a book: Head First Design Patterns. I thought to myself "Ya know, I should've finished reading that book awhile ago". Not only do I have books to learn topics, but I have other sources as well: a Safari Books Online subscription and various educational sites like Code Academy and Khan Academy. Just then, I realized I have all these resources to become a better programmer, and I've drifted away from actually using that time to do so. Sure, working on a game itself is a highly educational activity, but when it comes to knowing the solution for a problem, or at least a good process to explore possible options, there are holes that can be filled with prior knowledge, which as a consequence can speed up game development. In other words, knowing the right tools for the job.

So I've decided to set a goal for myself: try to set up at least an hour a day to do something educational. I think I'm going to start with that Design Patterns book as I've been wanting to finish it for a long time now.


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 - schragnasher 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 kit 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.

Page 1 ... 2 3 4 5 6 ... 7 Next 5 Entries »