Saturday, December 22, 2012

Fallen: Closing Remarks

Well, I finally turned in the "final" version of Fallen (well, last week I was enjoying some rest). Final is in quotations because the version is really nothing more than a demo showing off the mechanics that we wanted to do. I can honestly say that I am satisfied with the product we were able to deliver, but disappointed that we couldn't release the full scale game that we wanted. That is mostly because of time. There just wasn't enough time to complete the full version with the resources we had. If we were to continue on with this project, it would probably take at least another semester of hard work, work I have to allocate elsewhere. As much as I would love to complete this game fully, I'm just too busy with school work and other projects for the next semester. We may pick this project up again during the summer break, but I don't know if we will carry through with these plans.

If we were to carry on the game, there would be a lot of things I would like to change but couldn't to keep consistency and stay on schedule with the completion of this version. The biggest thing I would like to change is the tool we use to build it. I would scrap Game Maker in a heart beat and use another language. I suggested Actionscript 3.0, but that was only to fit within the time I had. I would like to start this game from scratch again and use the lessons I learned making it to better improve the product. If I were to go all out on this game and assuming I had the resources and time to actually do it, I would love to have this game as an open world 3D RPG. This would require 3D artists and animators, the artist we have is an awesome 2D artist, but he will be the first to say that his 3D work is basically non-existent. I would like to recruit some more programmers on this task since the workload will be extremely heavy with a sufficiently large game that would be like any other RPG you've played (like Dragon Age). If we are keeping things to a pipe dream, then this game could be your next AAA game. So if I were able to have all those variable accounted for (some how), then the tool I would most likely use is a combination of C# and C++ most likely using the .NET framework and possibly UDK. If this game is to be scaled back drastically, but able to keep the open world 3D aspect to it, then I would like to use UDK or Unity.

With that, this concludes the series on Fallen. You can download the demo here. I will take a rest for the rest of this year and pick up again, when next semester starts and I start the next Game Development course. The course focuses on Alternative Gaming, so it should be interesting what the result may bring and a chance to do something bearable this time without Game Maker. Who knows, only time will tell.

Monday, December 10, 2012

Beta and the Pit

I just had beta testing for Fallen and what an experience that was. You can test for all anomalies and bugs in your game, but only those who have never played your game will find the bugs. Users found two recurring bugs that I thought couldn't happen. The first bug was during a certain time when Vengeance was swinging his sword and the radius variable wouldn't initialize. I fully don't understand why that occurred, mostly because I couldn't step through the code and see what actually happens, but I was able to fix the bug by simply initializing the variable to just outside the range of a hit then have the code check for the actual range.

The second error was a variant of the sticky wall problem (where the character sticks to wall when the player walks and jumps straight into it). The player wouldn't stick into a wall, but if they were in contact with the wall and continued to press the space bar, then they could climb up the wall. This was a bit harder to fix, but I was able to fix it by creating a boolean to check if the player is jumping and have the player act appropriately when next to a wall based on that boolean.

The major complain that we did receive about the game was that the player didn't have a chance to use all the upgrades and fully traverse a tree since the full game is not complete. So we decided to create the Pit.

Pit mode is like any arena level or game where you start at a base level and waves of enemies come in at you. This does automatic upgrading when a person gets to the next level since the waves are continuous and the player can switch trees instantaneously. Initial responses to the new mode were favourable. The hardest part about creating the mode was random enemy generation and having enemies spawn at a pace that would start out easy, then get harder as the enemy progresses.

My method for enemy generation was to first create a range that would start out large at lower levels then get smaller and smaller as the player progressed. My initial formula to generate this range was Max_Level - Level;. So as the level grew, the range got closer to zero. This is still the formula I am using, but it is not optimal as I will show below. From the range, it would then pick a random number from [0, Range]. Then it will pick a smaller range by choosing a high and low number. It will choose the low number first by choosing a random number from [0, Range], then it will choose the high number by picking a random number from [low, Range]. Then it will check to see if the number is in the smaller range of numbers. If it is, then it will generate an enemy, if not then it will try again.


void generate_random_enemy()
      if(num_enemies < max_enemies)
             var range = max_level - level;
             var valid_number = random(range);
             var low = random(range);
             var high = random_range(low, range);
             if(valid_number >= low && valid_number <= high)


The problem with this algorithm is that even though there are many permutations, the computer can work through them extremely fast and enemies will still be generated at a fast rate. One thing that I do want to try is by playing around with the range and generating a new formula to get a better and larger range. Another thing is to have the algorithm sleep for a certain amount of time. So after it has generated an enemy or not, it will wait for x amount of time before it starts again and x will decrease as the level gets up. For now, I just limit how many enemies are spawned at a time, with the number of maximum enemies grow with the level.

Now that Beta is over, I have to work to get bugs finished and the game polished for it to be turned in by the end of this week. I will post one final time about this game with my final thoughts.