The Feeble Path
Art& Design Documentation Report
This report describes the process of design and implementation of the game The Feeble Path, an isometric 3D, platformer and co-op game for two players.
The first part, Design, shows the process of conceptualization and briefing, considering the scope and constrains defined in the coursework. Also, describes the strategy adopted by team, including role definitions, tasks assignment and working methodology.
Secondly, The Process, as the body of the document, lists and describes the contributions made by the “art department” (character design, asset creation, animation, UI design, etc.), as well as the interactions and cooperative work with our MSc teammates, in game and level design, implementation, blueprint edition and playtest. This chapter also, highlights the most relevant challenges and issues faced by the team on each part of the process and the strategies defined to overcome them.
Finally, the Conclusion is divided in three final reflexions about the overall process, each one made by a respective MA member of the team, which includes learnings, outcomes and analysis about the contributions made to the project.
1.1 Team members and stucture
Although leadership wasn't defined arbitrarily, the taskboard delineated a sort of structure, respected by all members of the team during the process. The tasks were asigned considering both expertise and personal interest.
2.1 FIRST MEETINGS: INTEGRATION AND REFLEXION
During the first three meetings, the team was focused in achieve a game concept and settle a team working structure. Nevertheless, as a team, we started the process discussing about personal interests, technical boundaries, knowledge gaps and expertise; highlighting the positive and negative aspects of our previous teamwork experience during the first term. Then, with those insights on the table, we analysed and decomposed the coursework definition and scope, settling a new common project definition to work on.
The design process consisted in a open discussion, in which the team revised ideas brought from all members. In the first meetings, all the ideas were analyzed and evaluated by the team in terms of gamepay, ownership, scope, art, production and programming requirements.
The final idea for the game was initially designed by Pablo Larenas, based on insights extrtacted from the meetings. The proposal was later refined with the team, using basic sketches and diagrams.
WIth the game concept defined, the team organized the main tasks from both art and programming perspective, identifying priorities and milestones.
The names of the team members, represented by leters, next to each key task during the 3rd meeting. The Roman numbers describe the priority of the tasks..
SCOPE AND CONSTRAINS (form CW description)
- The game engine will be UNREAL.
- The game must be 3rd person.
- person adventure/shooter, fighting game, strategy etc etc.
- The game must have one or more characters.
- The game must have AI.
- The game must have multiplayer.
- Will be marked as a team and extra credit given to individuals for participating in game design, team leadership and overall effort.
2.2 DESIGN SYNOPSIS
2.2.1 THE GAME
The Feeble Path, a PC isometric 3D, platformer and co-op game for two players. The goal is rescue and protect a group of disordered and unpredictable follower called "Feebles", from a dungeon-tower, passing obstacles, enemies and frequently failing in bloody (but always delightful) deaths.
In the game the players choose among two characters: Wizard and Knight, which has different and complementary abilities, necessary to achieve the goal of the game.
2.2.2 ORIGINAL GAME PLAY DECOMPOSITION
a. Players controls directly one of the characters with a set of abilities specific to that character:
- Movement control with keyboard
- Set of abilities in the UI can be clicked with mouse
- Interact with environmental challenges
b. Players must have a group of Feebles under their indirect “control”.
- “Slap, charm, inspire” Feebles to change their mood
c. Feebles can't attack or use any ability to help players.
- Automatic chaotic movement
- Different behaviour states:
Terrified: Run away, oblivious of traps, enemies and cliff edges.
Frightened: Stand still, paralyzed with fear; scream, attracting monsters
Calm: Follow the heros without causing trouble
Overconfident: Follow the heros, but insult monsters, attracting them.
Bravado: Seek out risks, “attack” monsters, play with traps, walk along edge.
d. Feebles can be founded along the level. They die when they are touches by enemies, traps or fall from level.
e. Each character have health that can be regenerated with collectables located in the level.
f. Win consition: Reach the end with at least one Feeble.
g. Lose condition: Be killed / All feebles die.
h. Characters have HP, regenerable by collectables.
j. There are pick-ups that work as busters that helps the players in their tasks related to trap or feeble control.
i. The level is a composition of tiles with different challenges.
- Isometric 3D
- No walls -> easy to fall -> Feebles die / heroes can be respawn after falling.
2.3 POINTS OF DELIGHT
- Funny situations: Laugh with exasperation at the situations and ‘juicy’ deaths that arise from the Feeble’s behavioral changes and player mistakes.
- Release your frustration upon the Feebles:
- Slap, deliberately kill when everything is going wrong anyway. Sounds and FX Slap.
- Get your own back against the world:
- Feebles insult monsters, the cruel narrator makes obvious attempts to downplay your success.
- Multi-tasking and challenging:
- Coordinate actions: defend, attack, control the oscillating behaviour of the slaves and resolve the path as a team, interacting with the environment
Dark comedy, where sarcastic antagonist forces and universal delight at sadistic and tastefully exaggerated NPC accidents reign supreme.
“Failing is fun!”
Punish hard and often, but don’t make the player lose. “It’s going so wrong, I have to cry with laughter”
Deaths, mistakes and arrival of challenges are met contextually with occasional voiceover derisive reactions from the game’s antagonist. Likewise, successes are mocked and downplayed.
3.1 Charcter Design
The character design process was extensive and highly participative, being developed by all artists and validated with the rest of the team. The initial task board considered the following responsibilities in the art department:
- HungLi Chou: Feeble’s design, including mood indicator and body language.
- Faris Omar: Enemies (Initially one melee attacker and one ranged attacker)
- Pablo Larenas: Heroes design (based on initial sketches presented to the team)
3.1.1 The Feebles
HungLi (Leo) was responsible for designing and modeling the "Feeble" character. Due the complexity and exigency of the them, as main characters in the game, Leo had some difficulties to design the character. Although, his fluent and transparent communication with the rest of the team allowed Leo to iterate several times, practicing his drawing and 3D modelling skills along the process. Finally, the character was co-designed by Leo and Pablo. Thogether, validated and tested the charceter in the level to see proportions, scale, visibility, appeal and personality. For example, the Feeble's fin, present in the first versions of the character, was deleted due the low visibility of it in the tests.
The Feeble’s design combined several attributes according to the game definition, such as: Clumsiness, innocence, weakness, humour and ridiculousness. Additionally, the character must have had a notorious capacity of communicate his mood and behaviour. Those requirements were particularly challenging, due the game’s camera (isometric), which shows the characters very small character and from semi top view, and the amount of characters in the game at the same time (at least 4 Feebles + 2 heroes).
Those inputs were taking in consideration, resulting in a highly minimalist and comic-book based style. The Feeble will change its colour and the shape of its hat depending of their moo, as well as it will "speak" using a sort of dialogue globe with pictograms according of its behaviour.
3.1.2 The Heroes: Wizard and Knight
The heroes design was made by Pablo with the contributions of Matthew, who provided additional feedback and insights related to gameplay during the process.
The hero’s skills were subject of discussion over the process, changing several times in the first three weeks, having an impact in the design process. In this sense, the cartoony style of the game allowed the designers to model freely in terms of deformation and topology, adapting the character to every game situation.
From an aesthetic point of view, the heroes were defined to look less masculine and aggressive, being almost agnostics in terms of genre (in the case of the wizard). Originally, the design contemplated the change of colours and some ornaments in the characters to make them completely agnostics. Although, those attributes were discarded, privileging more important aspects of the game in the task board.
To acquire more ownership in terms of appeal and concept, some drastic editions were made over the original design. In the case of the knight, the sword was removed, leaving it with a ridiculously huge shield only as defensive and offensive weapon. For the mage, the beard was removed, leaving it just with the hook to make it more androgenic.
Faris was in charge of create the enemies in the game, originally, a Dragon and a Goblin. For Faris the task was very challenging, considering his backgound as programmer, due the requirements of the characters has to meet the accent of the game in terms of poly count and also in aesthetics. Although, Faris showed fluency for 3d modeling showing intersting results, after several attempts to create a suitable goblin and dragon that matches the game’s accent. Faris also counted with the asistance of Matthew and Pablo, whom gave him feedback and guidance along the process.
3.2 Level Design
The level design proces started with the creation of the white box modular kit. Pablo and Leo defined a list of tiles, props, obstacles and mechanisms than later they modelled in maya and imported in the game engine. Those tiles were used in the initial versions of the level.
Through the first test sesions, using static meshes representing the characters, the design team had to adapt the scale and proportion of several elements of the kit to make them suitable in the level. Also, testing the camera angle, the team could evaluate several aspects related to gameplay , such as: speed of charcaters, size in relation to platforms, walking area, composition, saturation of elements in the environment, etc.
The inital testing with whitebox shapes, facilitated the design process. Once the meshes were validated , after following test cycles, the scale, prportion and variaty of elements were defined in a new TODO list in Trello, to track the progress of the final assets modelling.
With the characters and final meshes, the second part of the level composition started. In this stage, several test were made to validate the level elements and the response of the AI and player actions to them. In this sense, the blueprints facilitated the iteration through the use of public variables, which allowed us to edit level elements such as fire spawners, enemies speed and damage, spikes and falling rock speed and several triggerable objects as doors, levers, buttons.
3.3 Rigging and Animation
The rigging and animation process was extensive and highly participative, being developed by all artists and validated with Matthew as intern animation consultant. The initial task board considered the following responsibilities in the art department:
- HungLi Chou: Knight rigging and animation in Maya . Also assited Wizard's animations.
- Faris Omar: Wizard and Feeble's first rigging. Wizard Animations in Maya
- Pablo Larenas: Feeble's final rigging and animations in Maya.
One of the issues we faced in the rigging process was to settle a compatibe working platform for the three artist. Because Unreal plugging for Maya doesnt work in mac versions, some of the characters of the game are not based on a typical "human" skeleton and the intrinsic cracteristics of the game in terms of animation, the art team decided to make the rigging and animation manually in Maya, instead using predefined autorigg and animation components.
Being this the first time rigging and animating for most of the art team, the process was very intense and requierd constant comunication via Skype, Hangouts and Lab sessions. In these instances, all three members of the art departmente worked very close, helping each other in the use of the software, giving and receiving feedback.
In parallel with animation, the UV and texturing process was developed by Pablo, using Maya's auto proyections and then reconstructing the UV in 3D-Coat. The process continues painting the texture directly in the mesh with the new UV in 3D-Coat. Finally, the fbx is exported with the materials and UV textured files and imported into Unreal, where the material is cretaed, combining the color maps with normals, AC, metalness and roughness layers previously generated.
3.5 Sound and FX
The sound producing strategy was similar than previous projects. Once the level was defined, characters were designed in terms of skills, presonality and the mechanics were vaidated, Matthew and Pablo defined a list of sounds for the game which include all elements of it, from Charcaters to UI. The list was uploaded to the Task Board in Google Docs to track progress. Additionally, Leo assisted the sound database production, searching and testing several sounds in the level.
All sounds were extracted from royalty free sound database (freesounds.org). Character voices were recorder by Pablo and Matthew and edited in Audacity. Finally, the level's music "Shamanistic" was composed by Kevin MacLeod (incompetech.com), Licensed under Creative Commons: By Attribution 3.0 License.
3.6 UI design
The UI was designed by Pablo and Matthew, combining both communication and programatical skills. Matthew started the functional structure according to Pablo's design, whom imported the assets in the UI canvas.
The assets were drawn on Illustrator and edited in Photoshop.
Once imported, new play test were made by the team , highlighting some issues with some pictograms legibility and changes in the player's controls. Threfore, the UI was reformulated according to the new design.
After final gameplay test, new modifications were made to the UI. In this case in relation to the feebles. Additional pictograms were added to Feeble's communicatio, enhancing player's feedback.
3.7 Testing (Iteration Cycles)
Team meetings were fundamental instances of learning and iteration, in which not only the game was constantly improved, but also, we could share as a human team.
We engaged in regular team meetings over the course of the project (1-2 meetings per week). The first instance consisted in a collective brainstorming, where each member exposed ideas as a game to make for the project.
Once the game concept was introduced and validated by the team, different tasks were discussed and assigned to every member of the team.
Our official channels of communication and collaboration included:
Trello, where TODO lists were published in the first parts of the project. Once the level of intensity and control had to increase, we migrate the task boards to a spread sheet to have a more easy and fast update of the tasks.
GitHub, was used between programmers and Pablo, who was the member of the Art team in charge of compose the level. Leo updated constantly the project with new assets committing his changes in to the source control. Although, due previous experiences, we decided to minimize the amount of hands going around the source files. In this sense Faris and HungLi transferred their assets and updates to pablo, who managed the art assets in the project directory.
Google Hangouts and Skype were the most used channels. Specially for artistic tasks such as animation description, rigging and animation feedback, team meetings. Though this channels any teammate may discuss the problems they were facing and helped overcome them together.
The team managed a way to stay all the time in touch, without exceptions, and for prolonged hours. That connectivity generated a sensation of closeness that contributed in our success as a team helping each other with their tasks to produce better results.
Specific Task and Sub-Teams
Faris + HungLi +Pablo +Matthew = Rigging and animation
Nick + Pablo + Matthew = AI definitions
Nick + Pablo = Playtest sessions
Pablo + Matthew = Character voices
Pablo + Matthew = Puzzle design
Faris+HungLi+Pablo = Character design
Faris + Hung Li + Pablo +Matthew = Animation feedback
Matthew + Pablo + HungLi = Sound Design
Matthew + Pablo = Game Design
Nick + Pablo = Particle Systems
Nick + Abdullah = AI systems
Abdulah + Matthew = Debugging
Pablo + Faris +HungLi = 3D assets
Matthew + Pablo = UI Design
Pablo +Matthew = Team management
3.9 Main issues and problem solving
Knowledge Gaps – Modelling, Rigging and Animation
None of the artists in the team had prior relevant experience in animation. Although, we shared some tutorials and worked connected via skype, sharing scree and teaching each other in the different aspects and tasks about rigging, weight paint, joints and controllers. Additionally, Matthew, helped us and gave us some basic guidance along the process, acting as supervisor and consultant. Leo also shared some of his findings in tutorials and Faris, asked some friends about animation approaches. Overall, we managed how to find information and actively shared the new learnings inside the group.
As Faris and HungLi came from a programming background, their experience in modelling was basic. Although, their excellent attitude and hard work, was enough to overpass this gap after the first weeks. Pablo, also gave active feedback and guidance, explaining them the modelling approach according to the game requirements, showing some tips and creating some sketches and videos to help them in their tasks related to animation. The communication among the three artist was essential to generate a confidence
I had completed the wizard and goblin rigging completely but as shown above there were also attempts where I rigged the feeble and the knight as well but Leo took over the knight and also Pablo took over the rig for the Feeble where both of them produced better results. As for the animations which was the last step in designing these characters, I was in charge of the wizard. It was challenging at first as well but it was a very pleasant learning experience as not only did I learn how to animate but it made me want to dive deeper into how far animation can go. For the wizard animations, I have made the Wizards Protective Shield, Idle State, Running State, Death Animation, and also the Fireball Animation.
The members in our team are Pablo, Leo, Matthew, Nikita, Witek, Abdullah, and also myself. Although we didn’t appoint a leader nominally, Pablo was the one who organized everything in our team which in this case made him the true leader. He has been a great leader by keeping us focused on the matter at hand, making sure we meet our deadlines, and also the willingness to help other teammates. Leo has also been a great help to me as he has helped me with lots of problems that i have faced during the character development stages of the game. I believed that we consistently did what we were supposed to do, we were very well prepared and also very cooperative with each other. As for the programmers, from my observation they have done exceptional work by constantly updating and also brainstorming the problems that they have amongst each other. And also at the same time bringing new ideas to the table and putting them into action.They consistently went above and beyond.
What I learn through the project
Through the team project, I obtain the knowledge of using Maya to do modeling, rigging and character animation.
Modeling: Build modular kit in the same standard.
Rigging: Create joints hierarchy, binding, paint skin weight, create IK/FK and set controllers.
Animation: Set keys for the key pose of the character, use "Graph Editor" to adjust the "Transformation" curve, establish pipeline of exporting and importing characters and animations to UE4.
In this project the team have a balanced proportion of artists and programmers, which allows the team to divide the work into specific tasks for iterations. There are many methods we adopted to make sure everyone in the team had the synchronized idea for the game.
First of all, the design of game features was the conclusion of everyone, which avoided the appearance of dictatorship in the team.
During the vacation, there were no many intersections between two groups for the first iteration so the regular meetings were subdivided into an "Artist Group" and a "Programmer Group" to have a more coherent working process. The Facebook messaging, Google Handout, and Skype were the instant messaging for communicating working process and fixing conflict in Github, while the support of "Trello", "Github", "Google Sheet", and "Google drives" were providing a clear vision of the TODO lists and teamwork pipeline.
Regarding to the art, setting a pipeline for the creation of art assets is as important as for the programming. The assets need to have the consistent art style, made by the same method, so they have the same structure when imported to the game. This can be implemented by sharing and demonstrating the working process for other artist via "Skype" with its "Share Screen" feature.
Overall, this game project was a good learning exercise not just from an artists/designer perspective, but also as a team. The process was very chaotic in comparison with the first game we did with Mathrew and Robert (Telement), because the size of the team (6-7 team members versus 3) and, particularly, due the technical requirements of this particular game (multiplayer, AI and animations).
From programmatic dimension, the high-level of complexity and the gap of knowledge in some members, forced the team to invest large amounts of time iterating, putting on risk the viability of the project in some instances. For example, and although our team mate's attitude were always impeccable, we couldn’t deliver the multiplayer functionality in the deadline.
From the art side, our lack of experience animating was an issue. Leo and Faris, whom were very committed with the project since the start, invested an important time, learning modelling, rigging and animating, making me, as lead artist, very hard to request them additional activities to help with. On the other hand, their progress and learnings was shared with me, allowing me to make my animations faster in the last part of the project.
The art team communication was very constant, working almost every day, connected via skype, hangouts or in the lab and helping each other with technical stuff. Leo and Faris working ethics was impeccable. Always receptive to feedback and dialogue, respectful with our time and with the project, committed and transparent in the communication. Personally, I learnt a lot of humility and respect from them. Similarly, I was on touch all the time with the programming team, especially with Matthew and Nick, whom participated actively in the design process, iterations and playtesting, and, in the specific case of Matthew, in the UI and Animation process, acting as a consultant in this last one.
My technical learnings in this project were related to joints and skinning, FK animation, work with normal maps and shaders in the engine, configure state machines, work with skeletal meshes, mesh painting in 3DCOAT as an alternative to Substance Painter. Learn about Behaviour tree’s logic and working with Blueprints related to character AI.
Finally, but not less important, it was very important for me as designer, to have the experience of design this kind of game (3rd person, coop, multiplayer with AI) due the different of layers that must be considered to generate a consistent result. Although, the level of gameplay achieved was less than expected, through the process I learnt several design key aspects to consider in this kind of projects (player feedback, rewards on real time, composition, player controls) and the way all of the game elements coexists at the same time in a second. Definitely, this kind of games are the ones I like the most, and this experience is a first taste of their complexity that I really appreciate to have.