brockgilbert-blog

[brockgilbert-blog]

Individual Postmortem: Pirates of the Ice Coast

Introduction to Game

Pirates of the Ice Coast is an action RPG where you play as a walrus humanoid named Kaijaq, a pirate ship captain trying to make his way in a world full of other pirate animal races.  After learning of some powerful loot discovered by a rival faction, Kaijaq begins a quest to find the treasure for himself.  Will he obtain it to keep it out of the wrong hands?  Or will he use it to pursue his own nefarious agenda?

This game features expansive levels totaling in fifty-nine maps.  Melee combat, ranged blaster combat, and dodge rolling are the key player character mechanics used while trying to complete quests and explore the world.  The main antagonists presented to the player include hordes of penguin and polar bear pirates that have been pillaging and wreaking havoc in the towns and villages.  Completing main quests leads the player to new areas and, their main mode of transportation while in the overworld map, Kaijaq’s ship.

This was the first game project I’ve worked on where I was the lead developer on.  It meant taking on a lot of work that I was not used to, and I needed to learn how to use a new engine.  

What Went Right

Engine:

    This was all done using RPG Maker MV, which I’ve seen used in a project in my capstone.  I really liked the idea of a simple and easy to use game engine in our project, especially if I was going to be the person putting most of the assets and features together.  It helped take care of a lot of the basic functions that were going to be used (character movement, character/enemy stats, item/ability setup, and event creation).

Chrono Engine:

Chrono Engine was a plugin I was told about that would allow for real time combat in RPG Maker.  After taking a look at what it could do, I got it working in our project.  It took quite a bit of time to get it setup and working how we needed it to work, but I feel that it made our game as fun as it was.  If it was all done in the normal turn-based combat, I think it would have turned out a lot less engaging.  Although we may have had a much easier time during production without it, Chrono Engine brought so much more to the table than the base RPG Maker tools.

There were a few of my teammates that did help along when implementing assets later in production.  One had helped with level creation and the quest system that was put in to track quest progression.  The other took the time to learn how RPG Maker grabbed images off of sprite sheets and made sure that all art would be altogether easier to get into the project.

Dodge Roll:

The dodge roll mechanic was initially going to be used to avoid traps.  After traps were cut we kept the dodge roll and discovered how much fun it added to map travel, and the animation tied to it makes it all the better.  Due to how jarring constant use could be, we decided to keep it affected by a stamina bar to regulate how much it was used.  It is by far one of the team’s favorite features in the project.

Team Structure:

From the very beginning of the project, the entire team knew what their positions in the project were and what was expected of that position.  This made dealing with accountability issues and questions regarding different aspects of the project a lot easier down the road.  Having done this meant I knew exactly who I needed to contact when asking for assets and documents, which saved me a lot of time

What Went Wrong

Team Investment in the Production Timeline:

Although the team seemed very excited to work on the project while developing the initial concept, it did not stay that way.  Once the first few day had passed, people would go quiet on our social platforms being used for team updates and troubleshooting.  The people doing this would only speak up again as we neared deliverable dates, most of the time the day before or the day of presenting.  This caused immense issues with QA testing and build polish time.  The team member in charge of QA had very little time to fully test out builds and ask questions, which meant I was given no time to look over feedback for bug fixing.  

    A big part of this issue was due to art and audio assets.  There was no continuous reinforcement of deadlines for assets.  When it was first imposed, those that were trying to get their assets into the build after the appointed deadline would beginning to argue that there was plenty of time to get work that “will only take half an hour” into the build.  This led to constant push backs for builds being uploaded.  It really brought down the team’s expectations for the project management, and raised a lot of tension between members.

Lack of a Clear Pipeline:

We began the project with the first milestone fairly planned out, aside from accounting for adding scheduling itself and QA work to the schedule.  The first issue came with us only planning out the first milestone.  When the second milestone came around, again we only planned out that milestone.  It wasn’t until the third milestone that we planned out the rest of the project.

I do believe that some of this occured out of cautiousness when not knowing what to do about features and assets that would fall behind.  People want to make room for tasks that would fail to make the deadlines.  I feel that if we had hammered out the schedule from the beginning to the end in the first week, we could have kept the team more focused on what needed to be done and when.

Unbalanced Team:

From the very beginning, I felt that the team was off balance.  Our group consisted of one developer, one designer/writer, two artist, one producer/audio engineer, and one quality assurance team member.  This does not sound like a bad mix of people with one exception, the issue I had brought up earlier, the team investment.  When the producer does not take the class project as high priority, the producer work must then be completed by other members.  When one of the artist promises an asset by the end of the night and is not heard from until the next day, the person waiting to put it in loses faith in that artist and has to find placeholder art.  When these things happen, it becomes very clear who is not taking a project seriously and who is.  This exact thing created a huge divide among our team that lasted throughout production.

Game Summary

Pirates of the Ice Coast served as yet another example of how important it is to use proper communication, both verbally and through documentation, when working in game production.  If standards were set and made clear from the very beginning, and followed through with, the project may have ended in a much better place than it did.     Though there were several pitfalls during the time spent working on Pirates of the Ice Coast, we came together and made a fun game.  We participated in a project that taught most of the team new skills that can and should be utilized throughout the rest of our careers as both students and professionals in the game making.  

[brockgilbert-blog]

Team Postmortem: Pirates of the Ice Coast

Introduction to Game

Pirates of the Ice Coast is an action RPG where you play as a walrus humanoid named Kaijaq, a pirate ship captain trying to make his way in a world full of other pirate animal races.  After learning of some powerful loot discovered by a rival faction, Kaijaq begins a quest to find the treasure for himself.  Will he obtain it to keep it out of the wrong hands?  Or will he use it to pursue his own nefarious agenda?

This game features expansive levels totaling in fifty-nine maps.  Melee combat, ranged blaster combat, and dodge rolling are the key player character mechanics used while trying to complete quests and explore the world.  The main antagonists presented to the player include hordes of penguin and polar bear pirates that have been pillaging and wreaking havoc in the towns and villages.  Completing main quests leads the player to new areas and, their main mode of transportation while in the overworld map, Kaijaq’s ship.

Our project was created for our Asset Management course.  As a team of six, we were to create a game of our own design.  The production lasted one month with four milestones to be met.  Three times throughout the production, we met with our instructor and went over the progress of the project at that point.

What Went Right

Engine:

    We used RPG Maker MV to develop and compile our project.  It is a fairly simplified and easy to understand program with plenty of tutorial available online.  With only one member focusing on the development side of the project, this played a major role in making constant builds available to the entire team throughout production was easy.

    The engine itself came with level editing features that already contained player collision, map height, item creation, skill creation, animation implementation, and quite a lot more.  Though this did make it harder to fine tune several features, it expedited the development process for someone with those with little experience with many game engines.

Plugins:

    The Chrono Engine plugin made it possible for us to create an action RPG that did not use a turn-based combat system.  The battles instead to place in realtime and relied more on player reaction and strategy.  The player was able to used long range to their advantage when they had distance on enemies, pick up and throw bombs to effect multiple opponents, and stave off enemy attacks with melee knockbacks.

        YEP was another plugin that was used to track quests within the player’s quest journal for reference during gameplay.  This would allow the player to see if the quest they were doing was part of the main storyline, and remind them of the general details for the quests.  YEP really helped out those that were making and fixing quests throughout the project by keeping them neat and easy to access.

Quests:

With the creation of the game we had a fun time with creating the quests. The quest were written in a timely fashion. They were then implemented in a quick fashion. We were able to continually grow are quests into more in depth and interesting stories. With the help of the YEP plugins we were also able to add a quest log that helped track the quests we made.

    The experience of creating these quests and implementing them was a great learning experience. Our writer learned how to implement the quests themselves and how to work with the engine. This was also a great way for our team to see and work with questlines. With these experiences we should be able to push our games forward.

Maps:

    As our game was an RPG we wanted to have a fun and interesting world to explore. This was key to our game experience. The maps came out looking really good and playing really well. We had a few road bumps with them due to issues with one of the plugins, but ultimately the maps came out working well.

    It was an interesting experience creating the maps for the game. The engine has several tilesets that make map creation very easy. It also contains a simple event system to allow easy implementation. The creation of the maps ultimately led to our game feeling more life like and expansive. Especially when in conjunction with enemies and quests.

What Went Wrong

Team Investment in the Production Timeline:

With the development of the game one of the key issues we faced was lack of investment to the production timeline. This lack of investment led to all sorts of smaller issues inside the process for creating the game. It caused communication issues that confused and pushed our production behind schedule. It also led to work not fully being completed. The issue also caused our teamwork to drop.

    What we can learn from this issue is the importance of putting your all to any project. This is especially true if you dislike the project. Due to team members lack of investment we faced many issues. They could’ve been solved simply by us acting more professional. It is important when working in any team environment to work together in the continual goal of completing the project. We also must remember it’s a team effort and not a one man show.

Art Implementation:

    Another problem we faced during development of the game was the lack of art implementation before each QA test deadline and the end of week presentation. This issue also resulted in a de-synchronization between our testing result from QA and the results showed within our end of week presentation, as more art was added late between the two. The contributing factors include artists not being available to communicate, minor complications after testing the artwork in engine, and art just not being completed in time to be passed along the pipeline for implementation. This dilemma was less prevalent within the end of the month and however still posed a legitimate concern for further discussion.

    The lesson that can be learned from this is that we need to better control our time. This means sticking to deadlines and knowing personal capacity. Doing everything last minute easily led to delays. This further added onto the appearance of less professionalism and inadequacy. In the future we all understand the need to better control our time and capacity.

Lack of a Clear Pipeline:

One of the things that went wrong was the lack of a clear pipeline. During our sprints every department finished their tasks independently, without taking into account the dependencies or the workflow of the whole team. This lead to many problems, one of which was having contradictory information on the slides. QA was done at the end of the sprint, so it gave the team no time to fix any issue. An ideal pipeline would have had 2 builds, one in the middle of the week and one at the end of the week. If we did QA at the middle of the week, and then worked on a final build addressing whatever issue QA found; we would have had a much stronger build to present.

What we can learn from this is the importance of having a good pipeline, and the importance of being aware of the dependencies in any project.

Lack of Evenly Spread Disciplines:

Another issue that we faced was the lack of evenly spread disciplines. Not a lot of team members worked on the project within the engine. That lead to some team members doing extra work when any issues came up. It also affected the quality of our final product.

The lesson that can be learned from this is that having evenly spread disciplines is key to a project success. For future projects team members that don’t know how to use the engine could learn and implement at least some minor features.  

Game Summary

    Throughout the course of our games production we encountered all sorts of things. We pushed through the issues and continued to make our game to the best of our ability. This was at least true for portions of the team. The game is a short demo of what we can make. We also have made it in such a way that we could add and expand onto this game as needed. This is a game that could easily be pushed all the way through and into completion.

While we had issues during the making of this game it ultimately served its purpose. This was a great learning experience and ultimately taught us all a great deal. These lessons we can take into the future and to help us with all of our future endeavors. Pirates of the Ice Coast is a short game made in a month that taught us all a whole lot. In the future we should be able to adapt and grow even more.

[brockgilbert-blog]

Month 7 Team Post Mortem

When going into the month of February our team was tasked with creating a new game. Thus we came up with the concept for Ratatest. Ratatest is a sidescroller infinite runner. Players take control of a lab rat who has the ability to change size as they are the experiment of a mad scientist. With the creation of Ratatest our team experienced many things. We had our ups and downs. We’ve grown and learned a lot about the iterative process. This allows us to move forward and be a better team going forward into our next months.

When we were creating the game we had a lot of things that went well. The creation and development of our features and gameplay went very well. This allowed for us to quickly adapt and grow the features. We were also very quick at distributing tasks and making sure everyone was involved. This enhanced our productivity and helped the game get developed quickly. With distribution of tasks our artist was capable of focusing on the character and animations. This lead to a character we are very proud of and we feel functions properly. All of these combined to create a series of good prototypes that allowed us to hone in on our concept. In doing so we refined and stuck to our original concept and created a game we can be proud of.

Throughout the month, our team collectively agreed that communication was lacking. Discord was the only platform that was utilized, which was inconvenient for some team members. In addition, there were repeated absences from various members during team meetings. Apart from communication, we struggled setting up the repository, so it was hard for some team members to have access to the project files. Both the importance on capstone participation and the reluctant communication and disagreement between some members further contributed to the unsynchronized production of the digital prototype. The conclusion we made was that both the scheduling and enforcement to adhere to the schedule were found lacking. Moreover, the negative attitudes of some team members affected the overall productivity of the team.

After analyzing what went poorly, the team came to the conclusion that improving communication, team building, and technical knowledge is a necessity for future projects. To improve communication we need to have multiple communication channels, a better meeting structure, and a designated producer in charge of scheduling and task tracking. After completing this project, we realized that team building plays an important role. If there is tension between team members it should be alleviated as soon as possible. Finally, having team members with technical skills would improve the speed of the development process and the quality of the final prototype, however, if the team doesn’t have members with technical skills, a good mitigation strategy is to take the time to define some tasks that are adequate for their skill level.

        In conclusion this made for an interesting project. Ratatest taught all of the members of the team a few new things. The things we did well have shown us what to do in order to meet success and continue to create games we enjoy. While what we did poorly showed us how to improve and how we can grow further. Our love for games and thirst for knowledge lead us to create something we hadn’t made before. We hope to possibly further develop Ratatest or look forward to our next game.

[brockgilbert-blog]

Month 5 of my Full Sail classes!

For the fifth month of my mastery journey at Full Sail, I attended my Methods and the User Experience course.  It was interesting to consider the methods used by people that study user experience.  The complications that come with eye fixations and visitation repetition in eye tracking. Using physiological testing methods to gather raw data to determine what physical reactions test participants are having to the tests being done.   During this class, two classmates and I performed a study comparing the UI used for Hearthstone on mobile and PC platforms.  We took on 20 participants for testing, 10 on mobile and 10 on PC.  The first portion of the testing involved the participants navigating the menu system outside of the gameplay.  This included stuff like finding purchasable player characters, changing system settings, finding cards in the “My Collection” section, navigating to the “Solo Adventures”, and beginning a match with an AI opponent.  The navigation portions of the study were timed and followed up with a brief questionnaire.        Our hypothesis was new players will have an equal understanding of UI navigability in both PC and mobile versions of Hearthstone.  We, as a team, did not feel like that changes in UI layout would drastically affect player understanding of the game interface.  Our results showed a slightly better understanding by participants on PC, but our testing was by no means flawless.  We finished up the class with a presentation that covered the study in detail, along with all the limitations.

[brockgilbert-blog]

(10-12)

[brockgilbert-blog]

(7-9)

[brockgilbert-blog]

(4-6)

[brockgilbert-blog]

Here are some slides from my most recent classwork.  It outlines my future courses, including this one, and some goals I want to reach while progressing through them.  A couple more posts to come.  I can’t upload them all at the same time.  (1-3)

[brockgilbert-blog]

A pretty touching video from Rick Davidson.  You’ll never start your game making career if you are not actually making games.

Davidson, R. [Rick Davidson - Career Coach]. (2014, April 25). Don't Give Up - Motivation for game creators [Video File]. Retrieved from https://youtu.be/c1eh6VY26tg

[brockgilbert-blog]

Hey, guys!  Give my LinkedIn a look see!  I’ve had it for a while now, but I will be updating it more frequently in the future. Visit my page here: LinkedIn

[brockgilbert-blog]

Cool little logo I made using logogarden.com.  I really need to get back into using image editing software like GIMP.

[brockgilbert-blog]

Wow!  I had no idea sites like this existed.  It compiles feeds from multiple platforms to make one giant customizable one.  I’ve added several game news outlets and developers so far.

[brockgilbert-blog]

I’ve created a Papaly account!  Seems like it will be a nifty tool to keep my sources in one place.  Check out some of the links on there for some good design insight!

[brockgilbert-blog]

Another interesting video from Extra Credits!  Here they are discussing AI complexities and how they can be managed well.  I really enjoyed the section where they talk about “reactive” NPCs.  Duck for cover!

[Extra Credits]. (2017, August 16). Game AI - Funtelligence - Extra Credits [Video File]. Retrieved from https://youtu.be/1FBGR6vmNeU

[brockgilbert-blog]

Here is a presentation by Shimpei Takahashi about his method for coming up with new ideas for design.  I really want to try this out with some friends of mine and see what crazy stuff we might come up with.  Word association used in an interesting way.

[brockgilbert-blog]

Statement of Intent

    I intend to broaden my knowledge of the game design field by means of practice and research into areas that I am unfamiliar.  I have had a passion for gaming since I was very young.  I was taught proper resource management through my analog and digital experiences instead of grade school.  Games speak a language and it is that language I wish to steep myself in.  

    Some areas that I feel I currently need to improve upon would have to include programming.  I will be the first to admit it, I feel that it can be hard to concentrate on.  I can understand a variety of commands and able to read into what scripts may be trying to do.  I want to be better than that.  I want to be the guy that can help in almost any aspect of a game's production process.

    Being an avid music lover, I feel that all player experienced aspects of a game should convey feelings appropriate to the adventure that they are taking.  Every game has a sort of story to tell, even something such as a casual puzzle game that speaks of the player's wits and ambition to focus their skills. As all compositions have a beat, games too have an appropriate flow to follow.   Finding the correct pacing can make or break the entertainment value of a game in both digital and analog formats.  I will do my best to hone my ability to find these hidden tempos and setting my games to the correct time signature.

    It is my dream to work within a developer group that wants to show their love for the art to the people playing their games.  I care immensely for the player's experiences while playing games.  Hearing stories about them falling into intense immersive state and feeling all aspects of a game.  The point where the player has a moment of complete understanding of a game and turn it's mechanics to their favor.  That is what I want people to feel when they play the games I will make.