Monsterology: My First 3D RPG Project!
I have become very familiar with this main menu and seeing it come to life from the click-through to the final shipped version has been spectacular. I wrote the script that changes scenes using the OnPress function for NGUI ( a valuable lesson in re-usability taught to me by our senior UI engineer) so on touch device when a press is detected within the collision confines we move to one of the other scenes. This screen also became an important lesson in considering touch / contact area for users across ALL platforms. We ran into the problem of collision areas that were totally acceptable on the ipad being extremely hard to touch on the iphone so we tried to maximize the size of the collision boxes as much as possible.
One more important thing I gleaned from this screen and i will make sure to consider in any future UI-based positions i hold is learning user expectations for how a screen functions. One early comment from our client was being unsure what the collision area/ button press sections were of the main menu UI they believed the wooden blades containing the designated section text were the touchable areas however we made sure the collision boxes were centered around the bronze-ish buttons . I think for me this was the first time as a developer I experienced what "seeing too much"of the game" could mean. Something that to me had become second nature after seeing the game daily for several weeks was not a foregone conclusion to someone else. A valuable lesson in the " user experience" side of things.
I think one of my biggest tasks I worked on was the XP system ,a first for me and a definite challenge since i had to make sure my code worked somewhere in between the gameplay side of things in terms of calculating XP on the defeat of enemies as well as trying to update the information and its presentation to the user . then add that the users had t have a rank associated with their given level and it was definitely somewhat of a challenge bu I enjoyed figuring out how to make all of those things work together .
I had an array with public strings containing the given rank name ( Apprentice Journeyman, etc.) and a rank identifier( A,B,C) that was associated with that rank . It was all based off a level number stored in player prefs that was controlled by a current XP number that was also stored in player prefs.
I had an array with public strings containing the given rank name ( Apprentice Journeyman, etc.) and a rank identifier( A,B,C) that was associated with that rank . It was all based off a level number stored in player prefs that was controlled by a current XP number that was also stored in player prefs.
The narrative panels are another of the tasks that I was the primary engineer behind and it has changed substantially over the course of the game. When the player initially starts the game and presses the "play game" button we check if there is a " Completed First level" player prefs key stored in memory . If the key does not exist we load a narrative scene where we display 3 narrative panels and then the player is shown the map . After the player completes the first level we write the player refs key into memory and they are never shown the narrative panel again on their way into the world map scene.
The map seen saw several changes and the final one I worked on included the graying out of flags that represented locked levels . Code-wise a very small addition to the system of rendering unlocked flags I think it made for a nice touch in indicating user progress. Initially the player would never see a flag for a level they did not unlock, upon completion of a level we would check the highest level unlocked thus far and if this level was further down the progression chain we would update that number so that the next level and all levels prior would be unlocked. the rendering of the flags pertaining to each level was the product of an array as well, so I simply created a reverse array, the next level and all levels completed previously displayed red flags so I created an array that looked at the highest completed level and showed gray flags for all levels after it.
Unfortunately a feature that wasn't Entirely fleshed out , the trophy room was my baby , when the player hit certain milestones or unlocked certain achievements trophiess here would appear and be unlocked for the payers viewing pleasure. I cut out the original PSD's , reorganized the images through several re-designs, and most of the functionality ( barring the touch controls) incorporated into this rom was done by me.
my first task was to write the class for the scrolling of the library shelves, a task I managed by using multiplication and the current position of the book shelves. Then we placed and gave each trophy a dynamic text Description and title. The only trophies I believe that were functioning as of this writing were those relating to rank increases.
The rank increase trophies are displayed if a playerprefs key containing the given trophies name is detected in memory . For the ranks these keys are written into memory when the player levels up. If the trophy key is detected the trophy itself is activated and the player may press the trophy to learn more about what the given award represents. I am hoping that i get a chance to revisit the trophy room because I feel like a lot of work was done and really their are only a few missing pieces before it too can be an appealing and fun portion of the game.
I also wrote the initial scrolling controllers for the trophy cases which were based on button presses and essentially used the same concept as the original narrative panel functionality .
One of my earliest monsterology tasks included lots and lots of photoshop usage ( which is only natural for a UI developer right?) . The game contains 100 cards and a very heavy amount of UI work . So chopping images out of PSD's was a big portion of monsterology. This objectives screen is one of my most favorite in the entire game and I have learned that even before getting to the programming I really enjoy cutting these images out of the PSD and then positioning them within the scene as lose to perfect with the comp as possible . This was one more situation where I got to collaborate with a team member of another discipline to complete a task. In this case I asked our game designer for the text descriptions for the level that appear right below the level image he wrote most of them himself according to what the client stated the given context and items introduced in the levels were.
Another and eventually very important part of our development process for the game and a valuable lesson for me was optimization . Some of these Monsterology screen textures would combine to be 64 MB's ( atlas size) of memory Adding a substantial amount of size to the apps overall download size as well as weighing down the processor. While placing these textures in atlases would severely reduce the number of draw calls in each scene these atlases themselves were Size hogs. Eventually the team would adapt a very useful tool called " Texture Packer " that reduced the size of our atlases substantially. the best results I experienced? a 64 MB atlas being reduced to 4 MB . Considering we had possibly 20 atlases in all of monsterology this dropped our app size substantially, I believe we cut off 200 MB to our app size in texture savings . a great lesson in optimzation if you ask me.
All of the XP system code would eventually lead to this portion the Rank Up message which our senior UI programmer polished in terms of visual presentation and our technical designer polished . this was definitely one of my favorite parts of the game it showed me the benefit of team work and was even fun in trying to get into the thought process of the users when they see this message.
