My name is Max Loh, and I am the musical composer for Fat Loot. This project was very interesting for me because the game is simultaneously thrilling and comical, so I had to find ways to blur the lines between these two emotions in the music. I also needed to make the music evoke the feeling of being in ancient China, which is why I chose to record Dizi (Chinese flute, performed by Monica Williams) and Erhu (Chinese violin, performed by Hui Jin and Tung Lan).
For the main menu, I wanted to create a theme song with a memorable melody and an oriental sound. The Dizi and Erhu were perfectly suited for this task, because they are two of the most beautiful and iconic Asian instruments, and are well-suited for playing melodies. I took care when writing my melodies to make them pentatonic enough to evoke the feeling of ancient China, yet catchy enough to appeal to more modern tastes. I also added accompanying Guzheng (plucked instrument), pizzicato strings, as well as various light percussion in order to provide an exciting backdrop to get players excited during the menu screens.
https://soundcloud.com/maxloh/fat-loot-main-theme
For the mist level, I needed to create the feeling of tension and mystery while also keeping the mood lighthearted to suit the comical nature of the game. I found a synth patch that really sounded "blurry" and simulated the feeling of being in fog very well, but the mood it created was much too serious, and made the game seem more like it was about stealth assassins than stealthy fat women trying to steal a treasure. Fortunately, I was able to lighten the mood significantly by adding marimba and plucked strings. The result was a unique blend of both stealthy and comical music genres. The benefit of incorporating these elements together was that I didn't have to resort to using cheesy sounds to express humor. I believe that cheesiness as a solution to comedy is a lazy solution that should be avoided; music can and should sound "cool" and pleasing to the ear even when providing the backdrop for comedy.
https://soundcloud.com/maxloh/misty-loot
The temple level seemed like it had an emphasis in nature, so I decided to feature a Native American flute in the beginning. However, during my experimentation with my Native American flute, I was pleasantly surprised that by pulling out the mouthpiece slightly, I could achieve a beautiful airy tone that did not sound anything like a Native American flute; it sounded more similar to a Shakuhachi (Japanese flute). I recorded a melody for the temple level using this "modified Native American flute", to great success. As well, I decided that the music needed something to put the players in a temple setting, so I inserted clips of overtone throat singing throughout the piece to evoke the feeling of monks chanting.
https://soundcloud.com/maxloh/temple-loot
Overall, Fat Loot provided me many opportunities to explore new frontiers and genres in my musical compositions, and I was very pleased with the unique atmospheres I was able to create for the game. Working on this project has been smooth with no major pitfalls or music rewrites, and I would love to work with the Fat Loot team again. If you enjoyed listening to my music, you can find more on my website, http://www.maxloh.com.
Hello, I’m Chen and I’m the team leader of Fat Loot. It was great to attend GDC this year. Lu, our lead engineer, and I had the Summit pass and went to many lectures that we found inspiring. I’ll talk about some of them here.
On the first day, we attended a lecture from Simon Unger about animating cameras in games. He was the cinematic animation director for Hitman: Absolution. In the lecture, he talked about camera fundamentals, composition, and conventional techniques used in game. More importantly, he talked about how to reduce motion sickness for the audience, which is a problem Fat Loot is experiencing currently. Third person camera, if not handled well, will easily induce motion sickness. Simon used a clip from a demo he made to show the difference of visual feeling between different camera shaking amplitudes — stabilizing the camera while character is moving can reduce sickness significantly. Then he showed a clip from Ubisoft’s Watch Dog. The camera zooms in when player enters a room. Closer to character and wider FOV suits confined indoor space well.
After the lecture, we talked to Simon and showed him Fat Loot. He liked the game and gave us some suggestions for improvement. The most important one is to improve frame rate — there’s noticeable frame rate drop when player gets into the Mist. When players are close to walls, our camera will zoom in quickly to avoid penetrating the walls. He suggested to have an invisible sphere around player, and force the camera to move along the surface of the sphere. This method can prevent the camera from sudden snapping and force a smooth interpolation. It’s a very interesting idea and we decided to test it in our next iteration.
Another interesting talk was from Joel Burgess on Bethesda’s level design process. It’s a one-hour talk and they detailly talked about their iteration in Skyrim and Fallout 3. There are many great points that we missed in Fat Loot. Bethesda iterates all levels at the same time, and they let artists polish in the level editor when the layout is locked. In Fat Loot, we don’t have much freedom on these decisions because we don’t have many artists. It’s great to see how the industry leaders work and tackle the problems we have also met.
One more lecture I would like to mention is Pocketwatch’s Andy Nguyen talk about maintaining vision in Monaco. Monaco has a competitive stealth mode that has given Fat Loot many good inspirations. In this talk, Andy mentioned during playtests they have received many feedbacks that challenges their vision on Monaco. For example people don’t like the restricted sight and randomized AI routes. They want more information so that they can plan ahead and solve the puzzle. However, the developers didn’t want the game to fall into traditional stealth genre. So after they found the problem, they told players that Monaco is not a stealth game, it’s a game about getting spotted and running away. That is the core experience that makes Monaco fun. For players who want more information, they added a character the Lookout that can see the location of AI not in sight.
There are more lectures that I would like to share but only have time to write about these ones related to Fat Loot. Thanks for reading!
Fat Loot engineer Ravi Teja Sanampudi describes his experience at GDC 2014, below.
GDC!
I almost did not go for it.
Thought it was too much effort and cost to go to SF from LA, pay for the Pass, stay at a hotel and eat outside for a week. Especially considering I’m a student spending each dollar and each hour thoughtfully. Plus, I can’t possibly leave my precious assignments and personal projects for a week, right?
Lucky I am in a circle of game developers. Many from my college were going. I reconsidered. Our super helpful TA, Powen, gave a good perspective on pros and cons (none really) of going to GDC. So I thought, ok, let me take the cheapest Pass avaialable. But when I looked at the schedule, I saw awesome talks from developers of The Last of Us, Bioshock Infinite, Infamous Second Son, Assassin’s Creed, etc. Really exciting. But I’d have to pay $900! Are you kidding me??!! I could get 2 PS4s for that! Pay 2 months of living expenses! Or just buy 900 chocolate bars. No way I’d spend so much. Maybe.
After a LOT of thinking and a final discussion with my Dad, I finally bought it! The Main Conference Pass!
Then we booked the hotel and travel and just forgot about GDC.
Monday, March 17
First day! Sachit and I picked up our badges around 10am, saw the Video Game History Museum, picked up free (yay!) game dev magazines and walked around the North and South Halls. Then we went to Microsoft Lounge where they had Development Challenges setup. I started with the Unity Challenge. It was a tutorial on making a simple 3D treasure hunt game. Took about 30 minutes for that. Then I did the Project Spark tutorial. That was new and interesting. It seemed friendly to artists because there’s no code per se, but being a programmer, I’d still prefer to write code for gameplay logic. For building terrain, assigning textures, placing assets, etc the interface seemed pretty good. The designer sitting beside me built an awesome level within 1 hour (he was told to leave eventually because there were others waiting to use the computer!)
Sachit had the Expo and I Main Conf Pass, so there weren’t any Talks for us to attend. We left around 3pm and toured SF (was our first time here). Fisherman’s Wharf was good. We walked till the end of the ports and noticed a road going way up.. almost 35 degree slope!. We walked, walked and when we reached the top, wow what a view! long, uninterrupted views of vehicles, buildings, lights… and the sky! We just ran around like little kids. Every where we turned there was something awesome to see! North, South, East, West .. brilliant. We fell in love with the city then and there We walked around till almost 9pm then finally returned to the hotel.
Tuesday
I went to Unity Developer Day session. It was packed beyond capacity and I was in waiting line for almost 30 minutes. Met a designer (Joe) in the line, had a good chat. Finally got in when they were announcing new features in Unity 5. The way they convert the C++ and C# code to WebGL and asm.js for deploying on the web was cool. It’s great that now Unity games can run on browser without any plugins.
Went to the Student Narrative Analysis posters section and saw a guy (Mostafa Haque) showing his analysis of Soul Reaver 2. Wow. One of my first and favorite games.
In the evening was Sony’s (not so secret) VR announcement. Went in 30 minutes prior to the event and saw a line of … just 300 people. haha. Noticed Dean Takahashi (Venturebeat reporter) just at the beginning of the line. I think he was there like 2 hours before the event. In the midst of the long line, suddenly I saw someone that looked like Andrew House. I looked at his badge and omg, it was him! Whaaat! And Shu Yoshida right beside him! They were walking hurriedly in some direction. Later when the presentation started, Shu spoke about his interest in VR technology and how they were prototying it from a few years now. Was pretty exciting to just see a legend talking right in front of me ..plus, he was lively: giving thumbs up gestures and grins to the audience.
After that I attended the USC Games Dinner. Surprised at how many people there were! At first I just sat down with Chen, Lu & Sachit, but later went around and talked to quite a few people. Good fun.
Wednesday
The 1st big day for Main Conference attendees! The awesome lectures start today!
I woke up early, planned my preferred and backup talks, packed the nutrition / energy bars and water in my bag (like Richard Lemarchand suggested) and ran to West Hall. Wanted to reach by 9am for the XBOX One talk, but was late .. so went for the Flash Forward event where speakers gave a 45 second preview of their talks for the rest of the week. Pretty interesting. Discovered some cool talks that I otherwise would not have known from the schedule.
So my first talk: Rendering Technology of RYSE! Some of it made sense. :-/ When they went to low level rendering details I couldn’t grasp the awesomeness. Then Crystal Dynamics hosted Student Networking lunch! I saw people get Tomb Raider T Shirts and I was so excited! When my turn came I asked “wheres the T shirt, wheres the T shirt? Hope you didn’t run out of them!” Then Lindsey (the HR) said the shirts were for the developer team only :-/ .. sigh … But I did get sweatshirt, artbook, comic book, bag, keychain.. OMG so much swag!! Drool~~~
I talked to the 3 programmers present there, along with the other bunch of eager students all gathering around the rockstar TR programmers. They were pretty nice and explained the technologies, tools used and general culture (designer – programmer teamwork) at Crystal Dynamics. Maybe some day I can join and help with a Tomb Raider game (dreamy eyes)
There was a raffle. Unfortunately I didn’t win anything, BUT my roomate Lu won a bag full of goodies. Later at night we saw that it had a TR Collectors edition set, and a TR T shirt! I was so desperate to get it! I told him I NEED THAT! Luckily it was M Size and wouldn’t fit him, so YAY I got it! (Definitely one of the highlights of GDC for me )
Anyway, the event ended too soon (just 1 hour ) and then it was back to the lectures!
I was looking forward to this one. The Visual Effects of Infamous Second Son! Heelll yeaaahh! (Fan of Infamous 2). It was pretty interesting; Matt Vainio talked about the stages of the Smoke and Neon powers’ implementation from concept, references, art and expression editor for iterating on effects.
Next session! Rendering in Battlefield 4!
This was a bit technical, and the presenter didn’t help to make it interesting so I couldn’t follow much and left midway. I ran in and out of couple of other sessions for the next 30 minutes.
Then at 5pm, my first Naughty Dog talk!
The Last of Us – Human Enemy AI
This was actually the talk I could connect with best because Travis McIntosh talked about AI features in TLOU, some of which I too used for the guards in Fat Loot. I heard him talk about solving the vision and navigation problems that I faced with Fat Loot guards. Of course, Naughty Dog had more sophisticated and clever solutions compared to what I implemented, but the general ideas were similar. Some points he made addressed unfixed issues with Fat Loot AI. So maybe I can use that to make our AI awesome too
At the end of the talk I actually asked him some questions (wow, I’m talking to a big guy now!) and it was quite informative.
After that were the IGF and Game Developers Choice Awards.
Came to know of the innovative new Indie games out there.. Papers Please was like a monster, just hogged all the awards.
Then we saw Ken Kutaragi receiving the Lifetime Achievement award! OOO~~.
Sachit and I stuck around after the award ceremony and just went close to the stage. To our unbelievable astonishment, we saw the BIG guys walk out one by one: Brandon Beck and Marc Merill (Founders of Riot games), about 10 members of TLOU (OMG, the winners of Game of the Year award, right there in person!!), Lucas Pope (Papers Please), Shu Yoshida!! (Whaaaatt!) and Mark Cerny. We even got pictures with some of them. Wow.. that is definitely the highlight of GDC for me! Crazy stuff.
Sachit and I walked back home pretty high from the experience.
Thursday
10am was tough.
A talk by Jason Gregory (Lead Programmer of TLOU!!, and whose texbook I am reading)
Versus
A talk about TLOU Melee System (which my prof at USC, Artem is working on, I think)
What to do, what to do, what to do … AAAAAHHHH
I went to the second one. Was decently interesting. But at the end (10:50am) I ran out to the room of Jason Gregory’s talk.
Was just in time for the Q&A session. I was glad to be able to see the man in person! But as a bonus, I got to stand beside him for a few minutes and even utter a few lines about how I’m a student of Artem at USC. I think he heard me. There were like 5 others trying to get his attention, so yeah...pretty hard to chat one on one.
From there I ran to another building for the Assassin’s Creed Black Flag – Road to Next Gen Graphics talk. That was pretty good .. learnt about some PS4 hardware specifics and programming techniques for parallelizing and getting performance from the GPU.
One thing I noted was that most of these top games were using Deferred Rendering. Glad I did a project on that last semester, else I might not have understood many of the talks.
During lunch time I met up with some people from Sony at the Expo Booth and then just walked around the Expo Floor. I felt like I was back at E3 .. all the flashy stuff and big booths and cool swag Was good.
Next, I went to Solving Visibility and Streaming in The Witcher 3. After that just cuz I wanted to hear a japanese talk, went to Rain postmortem.
4pm: Engine postmortem of Infamous Second Son. Was informative.
5:30pm – Lighting in TLOU by Vivian Ding. Was a pure art talk (no programming), but it was interesting to learn how scenes are built from concept stage to final rendering.
That was a long day full of great lectures!
Just went home, ate and slept!
Friday
The final day! I was pretty much overwhelmed by all the awesome talks so far, and constantly seeing people from the greatest game companies just sitting and walking around me .. it really felt like I was at the heart of the game industry. But just one more day, let’s make good use of it!
Went to Bill Rockenbeck’s Infamous Second Son Particle System Architecture talk. He explained some cool algorithms in a simple way. Good talk.
I was about to go check out Career Fair (which should probably have been my first priority considering I was looking for internships), but then I noticed one of the schedule boards with the name Ken Levine on it. Whaaaattt! The guy from Bioshock Infinite, here?!! I had to check it out. I had automatically filtered it out from my schedule because it was neither a programming track nor art/ graphics track (which I was focusing on). This was a talk on Narrative. I wasn’t so sure I’d connect to that. But Ken talked very well. It was actually fun listening to the system of replayable and player driven story pieces. One of the best talks for me at GDC. And just check out the line of people for Q&A at the end! Wow! This man is popular and you know it!
After that I had a choice: Have lunch or check out the career fair which would close at 3pm. Well, it was an easy choice. I just ran all over the Career Fair, picking up business cards, information brochures, and cool swag when possible
Swept over the Expo floor as well.. Saw CryEngine running on Linux, Project Anarchy’s free native engine source code for mobile development, some of the IGF nominated games, British and Canadian game industry representatives, and so much more! Could have just spent a whole day there .. but yeah, it had to end.
All in all, a fantastic, informative and fun experience. Now I know how much I need to learn before I can be part of the games I enjoy.
So, back to USC and on with the project work hurray!
Hello everyone! My name is Velin Tchalakov and I am one of the level designers on the Fat Loot team. In this blog post we will be exploring some of the nuances of the mist level, and the changes I made to it to make this level more fun to play. The three things I will talk about are: Guards, Teleporters, and Artistic Design of the level.
The mist level allows players to sneak through the palace to capture the treasure, while trying to not get caught. One of the main ways of getting caught is by a Guard. These little guys patrol the corridors with their lanterns and won’t hesitate to catch anyone caught in their light! Even Fat Lady gets caught sometimes.
In previous play tests however, we saw that the guards were more annoying than anything. So it was my job to go ahead and fix the annoyance factor. The first step was to get rid of half the guards. The previous iteration had 10 guards! I was able to get it down to 6 by expanding the current guard routes. Below you can see an image of the new paths:
The next thing to do was to make the Teleporters more useful. Before, no one would use them because they were out-of-the-way and didn’t add much value. They didn’t get you closer to the treasure nor did they make it easier to steal it from another player. To this end, I changed the routing of the teleporters as such:
They are still out-of-the-way to get to, but now you can teleport closer to the treasure. Finally, I made them one-directional. It may be easy getting to the treasure, but it is still just as difficult getting out.
I also made the Teleporters slightly more noticeable. Instead of being a faint particle effect on the ground, they are now Guard statues!
And our talent artists are now working on giving those statues an animation, so that when bonk their nose, a trap door opens up underneath you, teleporting you to your new location.
The last thing I want to briefly mention is that we are changing the aesthetic of the mist level as well (time permitting). In its current form, the level has a polished look, almost as though you are entering the Queen’s Private Gallery! But that is not the intent of this level. With mist fading in and out throughout the corridors, the level is the epitome of damp and slimy. Our artists are hard at work updating existing textures to emphasize the sliminess by having vines growing on the walls, rotted bookshelves, and more! I can’t wait for the new designs to be ready so that we can all experience the Mist Level of Fat Loot in all its misty glory!
My name is Jason Ronzani and I am a 3D artist on the Fat Loot team. My main focus has been character modelling and animation. This semester we introduced 3 new playable characters all with brand new abilities, which means we’ve all been very busy!
One of the things that makes our game stand out is its Chinese influenced art style and our lead artist, Henry, designed some amazingly cartoony characters to populate the game. When I first saw Henry’s first character sketch of Lady, I knew I had to work on this game. She was so round and pudgy had a lot of personality. It’s always a letdown for me when I see excellent 2D designs get muddled up when they make the transition to a 3D model. So, when I was modelling our characters it was really important to me to maintain all the life and personality that made Henry’s 2D designs so great.
Our characters are very bulbous and round so I was constantly rotating the camera while I modeled the characters in Maya to check the silhouettes and make sure that the curvature was correct from all angles. I found that roundness is can be somewhat of a challenge with low poly modelling, but with each character I made, I became better at recognizing where to place the geometry in order to create a pleasant-looking yet efficient character model.
As for the animation, our characters have very distinct personalities which helps us to figure out how they all move and attack. Lady is a sassy master thief so she’s sneaky with quick bursts of energy and she has a lot of movement in her hips. Shorty is an ex-employee of the royal guard, so he has stiff and snappy militaristic movements. Ginseng Baby is naive and carefree, so she has loose, flailing childlike movements. Tiger is an adorable bunny with an identity crisis, so she has very innocent idle and walking animations, but her attacks are ferocious.
This has been a really fun project to work on, and I think the personality in the art and animation compliments the fun and frantic gameplay. I can’t wait to get together with my teammates when the game is complete and play some Fat Loot!
Melody is a level designer for Fat Loot. Here, she describes the process of re-designing or re-thinking the new Temple level.
Design is all about iteration and communication.
Through play testing and feedback from fellow team members, I concluded that there were several flaws with the map: 1) the size was too big for our tiny little character 2) the open space was too large when without grass 3) the player can get the treasure easily just by going up the stairs, and then jumping down 4) once the player got the treasure, it was hard to chase her down. To add to all that, the art progress for this map is slow, as the art team has to create completely new assets. This is an outdoor level, so the assets are completely different from our other, indoor levels.
So I’ve made a lot of changes to the map. First, I shrunk the map and simplified the design by removing the four fancy corner stages and the stages where the player spawns. Second, I staggered the position of the central top platforms so that the player won’t be able to go straight forward to the treasure place. Third, considering the factor that it was too easy for the player to get the treasure and then just jump away, the lead designer, Pat, proposed an idea that I could make the top platforms inverted. I thought it was brilliant and I did that. But later in the play testing, I realized I didn’t like that layout change very much and to prevent the jumping issue, I could just add a small wall on the edge of the platforms. So I decided to stick my original design and put the walls on. Finally, I painted grass, the key of the level, on the ground.
After so many changes, I still stick to my original concept – open, large view, outdoor scene. That’s how it looks now:
Next week is Advanced Games Project’s midterm date. Basically, what this means is that the Fat Loot team has to present to our three instructors and show them that we haven’t just spent the past two months sitting around twiddling our thumbs.
The basic rubric of the presentation is as follows:
What have you learned from presenting at Demo Day?
What have you learned from user-testing since Demo Day?
What are you doing to make your game better based on Demo Day & User Testing input?
What will you have for Spring Demo Day?
Back in December, the team showed off the polished Lady Qian and our basic map level. based off of feedback from Demo Day and playtests, we found that on the design side, players found the map too small and restrictive and also wanted more interactions outside of belly bumping (though they found belly bumping to be extraordinarily satisfying.) There were no ranged options, so the treasure was always lost once one Lady Qian was close enough to their base.
Based off of this feedback, the design team put together the Mist level and the Temple level. For Milestone Two (which was due last week) we’ve been focusing primarily on the Mist Level, hence we’re primarily focusing on that to show off for midterm. In any case, both the Mist level and the Temple level are much larger than the basic level, and both allow for players to be stealthier. The mist and the grass, for instance, allow players to hide in them. It isn’t until another player enters the mist or the grass that they can be seen.
We’ve also animated and textured Tiger, Shorty, and Ginseng Baby, the three new characters that we developed for this semester. To show off their abilities, Pat’s created a “safe” level in which characters are able to show off their unique abilities. For instance, there’s a guard left trapped behind a wall to demonstrate Shorty’s Firecracker ability.
We’re also going to be highlighting the elements of the Mist level in a live match/demo. Two of our team members, Ravi and Jason, will be sitting in the audience during midterm presentations to play with Chen and I as Pat speaks.
We’ll be presenting next Thursday. Hopefully, all goes well.
Today, I’m going to be posting on behalf of Henry Zhang, our lead artist. He’s busy at work getting all of our art assets together for the Mist level in preparation for our class midterm presentation, which is going to be on Thursday, February 27th.
In any case, standby for an explosion of art concepts.
One of our concept artists, Rebecca On, threw together the below beautiful arrangement of concepts. She was commissioned by our lead designer Pat Jenkins to come up with some unique side rooms for the Mist level. In the Mist level, there are empty pockets in the level (dubbed “jungle areas” by Pat) that he wanted to have players be able to have unique interactions with.
Ultimately, after a production meeting between our art producer Lawrence Jung, Pat, Henry, team lead Chen, and myself, we opted to implement the Curtain Maze and the Ground Smoke Cannons.
The Curtain Maze will be featured in the Mist level as just curtains covering the empty side room “jungles.” Players will be able to avoid guard detection by sneaking behind these curtains, breaking the guards’ line of sight (and therefore confusing them.)
The Ground Smoke Cannons will be implemented as an explanation for why there’s mist in the Mist level. The Smoke Cannons will not be functional. They will only be environmental pieces with a particle effect that give the appearance of emitting mist.
Rebecca worked on more concepts for the treasure room. Unfortunately, of the beautiful concept work that she did, we were only able to implement mist, due to production time constraints.
The last piece of concept art I’m going to show you (below) are some more of the mist emitter concepts based off of Rebecca’s original work. Henry worked on some new ideas beyond dragons for potential mist emitters. Pat mentioned that the aesthetic of the Mist level was one that felt old and rundown. Things are a little more creepy and dark, unlike the nicer basic level we worked on last semester.
Xu Zhong is an engineer on the Fat Loot team. Here, he describes the process of implementing mist into the new level with David Dai, another engineer.
Design
The design of the mist has gone through several iterations. It functions much like the grass in League of Legends. Essentially, it prevents the player who is outside of the mist to see in and shortens the field of view of the players who are standing in the mist.
Although the logic of mist is pretty straightforward, carrying out the idea into our game on the engineering side is kind of complicated and confusing. In the following part, I will describe the technical implementation in detail.
Technical
David, the interactive systems engineer on the team, made me a trigger which detects that player enter(Touch) or leave(Untouch) the mist. A RepNotify variable mistNum is defined to tell the server to detect this value. mistNum is defaulted to 0, which means the player is outside the mist. Once a player steps into a mist, mistNum is set to a specific value according to identifier of the mist. For instance, mistNum = 1 means player is in mist #1 right now.
When mistNum is updated via replication, ReplicatedEvent is called with the ‘VarName’ function parameter set to ‘mistNum’. What the function does is broadcast different information to each of the clients running the game.
In the body of the function:
The variable ‘self’ is always the pawn that updates value of mistNum. The server will check if mistNum equals to 0. If mistNum is not 0, the server knows one player is in the mist.
Line 5 checks the role of the player. If he’s the owner of the client he’s playing, he will search the status of other clients(players). The other clients can be in three states: in the same mist, in the mist but not the same one, or not in any mist at all. For the first condition, the server makes the player visible and covers it with a partly transparent mesh. For the second one, owner simply sets the client invisible. For the last one, the client is in normal state which can be seen by all players.
Line 9 is to say the pawn who enters mist is a guest, not the client owner. Then, a search will be done on all players to find out who is the owner of the machine. The status of the other player will be compared with the client owner to decide whether or not the client owner needs to be set invisible or not.
Problems
At the very beginning, I treated the mist like a disguise power-up. To regard the clients as a whole group and as two separate groups makes a huge difference. My first attempt at making the mist work out failed because I was not on the right track. With Lu’s (our lead engineer) help, I was able to figure it out.
To-Dos
The shape of the trigger of the mist is cylindrical, while the mesh of mist is a cube. This causes a problem, as the trigger cannot cover the whole mist. What we see in game is that the player reverts back to the visible state when he’s still in the mist. Although this bug could be fixed by cleverly arranging the layout of mist, it’s not a perfect solution.
And according to our designers’ idea, a new feature that guards could light up and dispel the mist to catch players hide in it is expected to be implemented in the future. This could be done by turning the trigger on or off.
Andy is one of the engineers on the Fat Loot team. Here’s a post of his personal project, in which he modded the camera for Fat Loot.
Multiple Camera Modes
OBJECTIVE
This project’s objective was to implement various new camera modes and effects, like shaking and Dolly zoom, for the Fat Loot game.
SUMMARY
Various independent camera modes have been implemented for use, in addition to regular gameplay. The camera modes that I had proposed to and have succesfully implemented are:
Over-the shoulder view camera.
Top-down (aerial) camera.
First-person camera.
I additionally implemented a fourth camera mode, that I call the ‘Vantage-point’ camera.
The uses/benefits and specific metrics of these camera modes have been discussed and finalized in collaboration with the designers on the Fat Loot team.
Incorporated into the normal gameplay, these camera modes have significantly enhanced the overall Fat Loot experience.
DETAILS
Usability
Initially, the user had to switch between camera modes with a key press. However, after iterating from play-tests and discussions with designers, most of the camera mode shifts now work automatically, based on the situation.
A screenshot of the default camera-view (for reference):
One of the most challenging parts of this project was finding a way to make the camera mode shift as and when needed. For this purpose, I defined my own camera class, inside which various new variables were defined to represent the camera settings. The more important class variables were designed such that the designers had an easy understanding of them and were able to play around with them.
• Over-the-shoulder (sprint) camera:
This camera mode was made to give the player a sense of high-energy during moves meant to keep the player excited. In the current version of the game, the camera shifts smoothly between the default mode and this mode whenever the player sprints. Most importantly, this camera mode is located closer to the character’s body, and increases the field-of-view (FOV), increasing the intensity of the action. Feedback from play-tests on this camera mode was generally appreciative, though a couple of comments hinted at motion-sickness due to the change in FOV.
• Vantage-point camera:
The camera shifts to this mode when the player decides to hide in a vase.
The vase not only assists the player in escaping the guards, but is also designed as a place for the player to observe the vicinity safely. To achieve this purpose well, I created a mode where the camera would move higher and further out, with a drastically increased FOV, allowing the player to take in more of the world around (hence the name ‘Vantage-point camera’). On moving the mouse, the camera rotates around the vase allowing the player to see around corners and other places that were previously out of view (from the other camera modes).
• Top-down (aerial) camera:
This camera mode gives the player a top-view of the world. This camera mode changes gameplay significantly.
The world is now always viewed from a constant orientation, i.e. there is no camera-rotating. Also, the character now moves in 2-dimensional space, controlled by the movement keys. Though a clear use of this camera hasn’t been defined yet, it would most probably be used along with some sort of a “cheat” power-up or a spectator mode, giving the player the ability to see the world on the other side of walls. The vantage-point camera and over-the shoulder (sprint) camera are disabled when in this mode.
• First-person camera:
This camera mode gives the player a more immersive experience, by putting them in the character’s shoes and closer to the action. It serves as another ‘primary’ camera, meaning this is not a mode that the camera shifts to only under specific circumstances. The sprint-experience is also extended to this mode, so that the player feels the FOV change directly without the camera shifting between the default mode and the sprint-camera mode. However, similar to the default mode, there is no “looking” up and down in this camera mode.
0 Camera-effects:
The camera effects that I implemented are:
Camera shaking: The camera shakes slightly when the character is belly-bumped by another. This was done completely with the use of Unrealscript, without using any camera animations from the UDK Editor.
Camera zooming/FOV change (aka Dolly zoom): While sprinting, the camera moves closer, while the FOV increases, imitating the ‘Dolly zoom’ effect.
Smooth camera shifts: The camera always shifts smoothly to and from any view mode.
CHALLENGES / LESSONS
Some of the challenges I faced during the course of this project were:
Finding a way to have a variety of camera settings ready for use, without defining them in the UDK editor as they had to be responsive on any level/map. For this purpose, I created a custom camera class, overloading key functions that I felt necessary from the default camera class.
Smoothly shifting between different camera modes. I solved this challenge by having 2 sets of variables for the important camera parameters: a current set, and a target set. On sending a command to change the camera mode, these values would smoothly LERP to their target values, creating a smooth view-shifting effect.
The sprint-camera hinting at motion sickness when shifted to and from repeatedly. I solved this issue by constraining the camera-shift only when the player holds/releases the right-mouse-button, or runs out of energy. This hence reduced the frequency of sprint-camera shifts.
Re-implementing the purpose of mouse/keyboard input with the aerial camera. For this purpose, I created a function in the controller class, which overloaded the default camera-rotation and didn’t have any effect when the top-down camera was enabled. I also now changed the movement mechanics to move the character in the N/E/S/W directions according to keyboard input.
Disabling the automated vantage-point and sprint cameras when in the aerial camera mode. I achieved this by having carefully-placed checks in the general controller code.
Combining the character and camera rotation into one unified control in the first-person camera mode. Though not the best means to solve it, I got to it by simply attaching the camera to a fixed location near the character’s mesh, and hiding the mesh. I also placed checking code at any mechanism that depended on the character’s direction, such as the belly-bump, and handled it accordingly.
Extending the sprint dolly-zoom effect into the first-person camera mode, (i.e. without moving the camera’s location).
After experimenting, I managed to create a global FOV that would change on sprinting. This allowed the dolly-zoom effect to occur even when in the first-person camera mode.
ACHIEVEMENT OF INITIAL OBJECTIVES
The achievements of this project definitely matched up to the initially-proposed objectives.
All proposed camera modes have been implemented.
Though many of the possible camera effects still don’t serve any purpose in the current version of the game, they have been implemented and can be used.
A new camera (the vantage-point camera) has also been implemented in addition to the initially-proposed objectives.
An unmentioned objective and challenge, however, was to experiment with and learn new mechanics and ways of scripting in Unrealscript, especially with camera code, which I feel I have achieved to a satisfactory extent.
FUTURE IDEAS
There still exist a handful of possible directions and improvements to be considered in the future.
First and foremost, occasional glitches in the first-person camera need to be fixed. Mesh effects aren’t evident in the first-person camera, which would be another area to look into.
Additionally, all the camera modes could also use further polishing with their exact positioning, orientations, and metrics, with help from designers, artists, and anyone experienced with cinematics. Each camera mode is still static for the most part. These camera modes can be made more dynamic, i.e. keep subtly moving (not necessarily between two modes) whenever there is new crucial information.
Pat Bayles is the lead designer on Fat Loot. Here, he describes the process of developing new characters for the game.
Towards the end of the last semester, I decided that the design expansion of the game would be new characters. I wanted to have three new ones, for a roster of four for the next semester. I wanted there to be more characters because I felt that it would make the game more varied, allowing for different combinations of characters in a game, which means a number of different mechanics colliding with each other in different and interesting ways.
During our brainstorming period, we threw around a lot of ideas, some of which can be seen above. We drew inspiration from Chinese tradition, from concept art drawn by artists, and from ideas with a purely mechanical basis. For example, the skeleton and ghost were both inspired by ancestor worship. The skeleton was suggested because I really like skeletons, and the ghost was inspired by an engineer who wanted to give players the ability to move through walls. (I also like ghosts though, for the record.)
The character designs were chosen based on both art and mechanics. The skeleton, for example, had some mechanics that were not feasible to do in the timeframe that we were aiming for. We ended up with the three new characters above, Tiger, Ginger and Shorty, who, with Lady Qianqing, represent four different approaches to stealth.
Our original character, Lady Qianqing, has a very fast approach to stealth. She is not the best at hiding, but is adept at staying out of sight of the guards by being somewhere else when they turn to look.
Tiger was originally suggested by our lead artist, from this piece of concept art:
Originally, Tiger was going to burrow underground to hide and then burst out to attack the other players. These abilities were later swapped with Ginger, so Tiger got Ginger’s Tiger Roar and Earth Dive. Using the Earth Dive ability, she is able to travel quickly over short distances, and her Roar allows her to stun at a distance. Tiger is most similar to Lady Q, but where Lady Q has much more raw mobility, Tiger is more content to stand back a little bit. She is less involved in the chaos of the brawl, but that also leaves her further from the treasure when it pops out.
Shorty was suggested by an artist, and was chosen because a guard offered a unique opportunity for stealth. Inspired by the Hitman series of games, Shorty uses her disguise to her advantage, raising the alarm to alert the guards to other players, and can put on her helmet to just walk past them. Shorty uses a stealth paradigm based around disguise, and while she is slower than both Tiger and Lady Q, she has more tools for dealing with guards than those two, being able to redirect them, or to ignore them.
Ginger was originally supposed to use the Tiger Roar, named Mandrake Scream, and the Earth Dive, but was given the Burrow and Burst abilities instead. Ginger can dive below the ground, and use that state to bypass obstacles, guards and players, but such a move is tiring. It can also explode violently out of the ground, hitting players in an AoE and leaving it in a prime position to pick up the treasure. However, it can only attack when it is burrowed. Ginger hides, and represents a behind cover, more patient approach to stealth.
All four of the characters represent different approaches to stealth, and hopefully offer different ways of playing the game. Lady Qianqing is sneaky, Tiger is almost a sniper-esque character, Shorty disguises herself and Ginger hides deep under the ground.
Catherine Cai is one of the producers on Fat Loot.
Welcome to Fat Loot Spring 2014!
We’ve been on radio silence for the last month. After Fall 2013’s Demo Day, we all went on a well-deserved month-long winter break.
USC’s Spring 2014 semester has started and the Fat Loot team is getting right back into the swing of things. For spring, we’ve made a couple of changes. Quite a few of our team members have graduated from school and have moved on from the project. We’ve also had a change in focus. In the fall, our team’s main focus was on completing a fully-functioning game within a few short months. Now that we’ve wrapped up the core game, we’re going to spend the spring focusing on adding new features that will mix up the mechanics and hopefully make the game more interesting and fun to play.
In the next few weeks, we’ll be posting more updates on what these new features are. For now, here’s a sneak peek of the new character concepts that our lead artist Henry has worked on:
The following is written by Melody Wang on a new level she has been working on.
Before I started creating the new level, I highlighted several keywords I wanted specifically in the level: no walls, no maze, high, large, more choice, more variety.
Then I came up with this: a puzzle map related to light. Initially, the center treasure is highly guarded by four guards. The player can only distract the guard away by turning off the light(s) they stand by.
After I turned this concept into an UDK map, I realized it was too small and the whole layout was not balanced. I was out of inspiration for days. I knew I must create a great map. It would be a next big thing for Fat Loot.
To get some inspiration, I talked to one team member about my thoughts. First, he reminded me of our concept art, which was this:
Suddenly, I felt that was the exact direction I should follow: large vertical and horizontal space, two layers through stair approach.
He pointed me to Tomb Raider (2013), which is an action-adventure, exploration, survival game. He showed me some awesome pictures of that game:
“Yes! The outdoor scene, with rocks, grass, trees! That’s exactly we should pursue!” I was instantly inspired.
Then, I restarted the design from scratch after I did some research on Tomb Raider and Uncharted (see the pic below.) I redesigned the treasure stage the same as that in the concept art and kept the light puzzle which I felt was unique. I added four corner stages for holding four light switches, four player-start-places decorated with line of pillars, side stairs for going up to the second layer and clear paths to each event place.
I drew the inspiration from the following scenes:
I made the four players’ spawn points higher than the ground because I wanted the player to see the full scene of the level and get a general idea of what was far away and what they would experience afterwards. Once they entered the game, I wanted the player to be merged into the scene by standing high and looking far.
After Pat, our lead designer, looked at my level design, he mentioned something interesting when we were talking about the guards: the path in the grass. Then, I thought maybe we could make the player hide in the grass instead of just in vases like with previous levels. Just like the right picture below, when the player was hiding in the grass, she could get a view of the far structure.
Overall, the basic concept is finalized. I still have a lot of things need to think about, e.g. where should put the guard, how to make the light puzzle not hard and reasonable. Stay tuned. There’s more to come about this level…
Lawrence Jung is one of the producers on the Fat Loot Team.
Hi Fat Loot fans! It’s been a while since the launch of our website. I have been working with Cat and Chen on improving our production workflow and handling the specific needs of each team members. Since the beginning of the semester, our team has grown to 36 strong. The current team breakdown is:
3 Producers
14 Artists
4 Designers
13 Engineers
1 Composer
1 Sound Effects Artist
One of the major tools we implemented early on is Trello, a web-based task management application. The boards are divided into the categories of: To Do, In Progress, Future, 99% Done, Done, Bugs, Polish and Informational. Each card contains the task title and a description of the task. Appropriate team members are assigned to the card and the relevant label is assigned for easy sorting. It was difficult initially due to the amount of people needing to create a Trello account but over time it became integral in task management work flow.
One of the neat features of Trello is the ability to attach files to the cards. This allowed us to easily reference important information related to the task such as a design document or UDK tutorial. It also allow us to attach documents within our shared Google Drive. Google Drive and Dropbox integration within Trello makes sharing and referencing files easy between team members.
Our milestone deadlines are 3 weeks apart and are coordinated with the major deadlines with our Advance Game deadlines. With each milestone, I work with Leads to see if we have hit our require targets. When we miss any targets, we re-evaluate on the feature and see how it will affect our future milestones. It is really important for us to make sure that we know what direction and the state of the game is by that deadline due to the fast paced timeline of the Advance Games Course.
During the development of the game, I noticed some ways we could improve the workflow by making the team faster and more efficient. By dividing the team into feature pods, it will allow us to quickly iterate and test features. Each pod contains a designer and a couple of engineers. Each pod has their own branch in which they can experiment. We divided the pods into Artificial Intelligence, Interactable Objects and Character Features. This is to help continue to improve on the game while maintaining a stable bug free version of the game at all times.
An important aspect of the development process is taking attendance. It is crucial that all team members are here to handle any major issues that may arise. Each member is responsible for a small section of the game that when put together create the Fat Loot experience.
I have been working with my assistant producer Catherine Cai on organizing fun events like a team trip for dim sum and a Thanksgiving Party. This is to help the team members take a break from work and enjoy time together. It is a great team building activity. Other quick team building activities include playing Nintendo Wii U game sessions in the game laboratory.
Other activities we work with our team is professional development such as helping them making their website and refine their resume. It is important for them to be able to create a professional presence online and in print. I have found some industry professional resumes online and shared them with the rest of the team.
I not only focus on the development of the game but also the publicity of Fat Loot. We have a Facebook Page that our fans can like to follow the development of our game. It is a central portal for updates like our team activities and blog post written by our team members. I also help design and maintain the Fat Loot Game website. Information about Fat Loot, concept art by our artists and updates from team members can be found there. It is a great place for players who are interested in our game to find out more information.
We have had many ups and downs during this past semester as we developed the game, but it proved to be a very fruitful experience. I have learned a lot in what a producer does on a game of this scale. I believe I made the team stronger at the end and am excited to see the game as we enter into the Spring Semester.
The following is by Nick Pallares and the work he has been doing on Fat Loot.
General Experience
I came into this class not knowing anything about developing for the PC/Console/etc. or using UDK/Unity/etc. All project proposals either had something that I felt would either be difficult to work on or the game itself didn’t feel like a game and would be boring or unrelated to the type of games I’d like to develop in my career. I chose working on Fat Loot (then Sneak to Slim) because it seemed to have the potential to be a fun game. Looking back, I’m glad I made this choice because I’ve learned quite a bit about making a “real” game. I’ve never been stressed during development and my co-workers are nice people to work with. Before now I’ve hardly done any game programming so I’m glad to see development of not just the game but my abilities coming along.
During the first month I had to read up on how UDK, networking, and various other things worked. I hadn’t made much progress during this time but once I got past this initial hurdle, things went smoothly … for the most part. I’ve worked on creating basic interactable objects, a minimap, and an UI that uses “fancy” Flash assets. Throughout the entire semester I’ve dealt with lots of different bugs or minor things that needed to be fixed or added. Most of my work seems rather unimportant in comparison to my peers who have worked on AI, gameplay, networking, etc. so I got more involved in helping design the game and give some input on how I thought things should be made and the kinds of philosophies our game should follow.
Interactable Objects
My first real task as an engineer on this project was pretty simple. I created a “fountain” that teleports the players to another pre-determined location. One common issue I had, not just with this but nearly every task, is that most of the online tutorials used the editor while I was looking for examples that used only code. In the end I had to use a mix of code and editor settings to get this to work. In the editor I placed the trigger and the destination node on the map and through Kismet I set up the action and links. In the code I checked to see if the fountain was available for use. This class is pretty bare but I can make future adjustments in this trigger class if needed.
The second thing I worked on is a vase that a player can hide in, exit, and smash. This was also pretty simple to make but bugs slowly emerged throughout the semester after its completion that I had to fix.
After these were made I debug them whenever complications showed up and made adjustments to consider different scenarios that could occur. I also wrote up some tutorials for the designers on how to set these up.
Debugging
While I mostly dealt with bugs during the middle of the semester, bugs continue to pop up anytime a change is made. Most of the bugs I’ve dealt with usually crash the game if unresolved or usually had to do with not showing up on a networked game session. I was able to solve most of these because I looked at how the code was structured and what each class and object was doing. One bug I “magically” fixed was when two actors overlapped each other’s meshes (usually when fountains are used) and both were unable to move. All I had to do was set a variable and it literally fixed the issue like magic. There are lots of more bugs I can go into detail about but it’d take forever to go over all of them.
Minimap
This was my first real major task because it wasn’t finalized in the design and was added due to playtest feedback. I had to work with the HUD, pawn, and my own minimap class because most tutorials I found online used complicated compass maps and had flash assets I didn’t have. I wanted to keep this simple so all the map does is display a picture over the entire screen when a key is held (for reference, the key is “M.”) Over time some more things like dots were added to indicate a player’s location and where they’re heading. One thing about this task is that it needs a better map image and icons to show where objects in the map are. This will help make the feature more useful because right now it’s… Not the prettiest. My biggest problem with this task was converting the player’s 3D world space to 2D screen space. I tried using matrices but it didn’t turn out as expected and naturally, the task was complicated. I decided to use vector math and two numbers. I had a hard time finding the map’s width and height. I ended setting up placeholder nodes at the corners of the map and finding the dimensions using them after the map is loaded. The placement of these nodes is crucial as the player’s location won’t be 1-to-1 with the screen size unless it’s perfect. Needless to say but this got more complicated than expected and I plan on cleaning it up during the second semester but for now it works.
Flash Health Bar
This is really an energy bar, but I called it a health bar because that what first came to my mind.
Before working on this asset, I did some research about how to use Flash in the editor. I got it to work on a random sample I found online and even figured out how to use it as a material texture that can be directly placed on objects in the level editor. After downloading a trial version of Flash Professional CC I had to watch YouTube tutorials about how the health bar is created in Flash and how to use it in the editor and code. One problem I came across was that I had to work with Actionscript 3.0 and nearly every online tutorial uses version 2.0. The differences are greatly significant and will affect how the code of the project works. Luckily I wasn’t stuck on this difference for long and even managed to figure out how to get the code to directly affecting the script itself to change the bar’s color depending on the value’s range. The code changes I made are in the HUD class where the flash movie is created/loaded and during the “draw tick” where it calls the GFx class’ tick method. The GFx class I created for the health bar is extended from an existing class in the Engine and it has simple initialization, tick, and default code blocks. As of now, I’ll work on creating something for when a player uses an invisibility power-up and the scoreboard. Demo day is only about a month away so after this I feel I just be refining my existing work and won’t work on creating anything new.
The following is by Andy Devanapally and the work he has been doing on Fat Loot.
A quick post on most of the things I’ve worked on with the Fat Loot team. I don’t have much in the way with words, so bear with me please ^_^. I’ve been working on mechanics related to character movement since the team started work on the game this semester. For the first week or two, I spent time going through general Unrealscript language basics and techniques. It was a slow, draggy start. The real fun began once I got to focus on my specific work for the game.
- -
The first area I focused on was character sprinting. It turns out that the guards had trained well in chasing down ninjas, and our lady needed more than just her usual walking speed to evade them. It was a simple concept to start with: hold down a button and move to sprint, release button to return to normal movement. Though I know better now, it seemed somewhat complex to me at the time, with the regenerating energy posing an obstacle, especially considering the fact that the sprint- button could be held down even when the character wasn’t moving, and the energy would continue to regenerate. Regardless, Unrealscript is a fun language (and really easy, once you to get a hang of the basics) and I finished the sprinting mechanism in good time. Our lady shot across the map… like a ninja?
- -
The next task I worked on was a new camera implementation for the game, one where the player and camera could move independently of each other (like in Prince of Persia, GTA, etc). It was initially a little demotivating, because I didn’t even know where to start. At the time, I was still an Unrealscript noob. All I’d done so far was mess with the basic classes (Pawn, Controller, etc) and had never really ventured into creating a new class myself. After some work, the new camera class was born. I’ll hold for applause. After about a day’s research, I was actually enjoying how the Unrealscript camera was programmed (at least the basics), and was well on my way to getting the new camera working. With another day’s worth of work, the new action camera was all set.
[Quick pause to let everyone know that I keep uploading my work with Fat Loot to my YouTube playlist at http://bit.ly/GUfy3swhenever I find the time]
I had the new camera working at that point. I also had to mess with how the playerController handled movement input to get it working perfectly.
- -
The next thing I worked on was also camera-related: seeing through objects that block the view of the character, such as walls. This was needed since the designers thought the camera was better at a fixed distance from the character. I don’t think I’d implemented this in the best manner possible. What I did essentially was:
1) A ray trace from the camera to the character,
2) Find any object in the way, and pass its reference to a global array
3) Make every object in this array transparent for a duration longer than the frame-period.
This meant every object blocking the view would be rendered transparent at each frame, and the transparency lasted just over the duration of the frame-gap. If an object still blocked the view for longer than the frame-period, it would simply refresh its transparency at the start of next frame, and so on, seamlessly. Anyhow, like I said, this was somewhat a ‘hacky’ way to get it working. Good news however was we didn’t need all this with my re-implementation of the camera, as the team later decided to simply move the camera closer to the character whenever an object came in the way.
- -
I worked with Xu (who has also been working on character-specific mechanics from the start) for a while to improve the belly bump usage. One fine morning, I discovered the Unrealscript TakeDamage function and suddenly, everyone started to love using the belly bump :D. It was pretty fun, though no one probably even notices it anymore… :( I then worked on making the victim get stunned on being belly bumped into a wall. The designers decided there wasn’t enough punishment for someone who’d gotten belly bumped, so voila! I worked on the core logic then. Xu has done a much better job of it now, after we improved the states in the playerController.
- -
I then started work on designing the existing playerController states with Xu and Thomas. We were cleaning up unnecessary code in the Pawn class along with other work that doesn’t need mention here. For a while after the basic character finite-state machine was set up, I worked on making the player increase/decrease speed gradually (i.e. acceleration/deceleration) rather than the sudden switches she made in her speed previously. Once that was done, I returned to the playerController states, where I’m currently working on all the Invisibility, Disguise, and Treasure-carrying related states. It’s taking some time: handling all the possible transitions and possible cases, but knowing that the code will run much more efficiently after this provides good motivation.
- -
Behind everyone’s back, I’ve been secretly plotting on my evil personal project: implementing a variety of different cameras. I’ve been working on an over-the-shoulder view where the camera smoothly glides in and out while sprinting and changing the FOV simultaneously to give it a very action Gears-of-War-esque feel. I’ve started work on a top view camera mode as well, which Pat (our lead designer) suggested would be of great use for a spectator mode. I’m also working on a first-person camera mode, though I’ll have to discuss with the designers as to where in-game we can use it.
I’m at a very unconvinced spot about these cameras right now: confident and excited to show the team my (so far, hidden) work, yet slightly concerned about bugs that might pop up, killing all the fun. XD I’m taking my time on that one, going slowly but surely towards some pretty kickass camera modes.
–
With all that said and done, the most important thing I came to this course for was to learn, and that I have definitely been doing. Learn Unrealscript programming? No doubt. I’m now confident to take on any sort of character mechanics. Learn to work well with a team with separate sub-teams? Sure. The Fat Loot team has pretty much a flat structure, but I don’t think that makes the effort needed for team communication significantly less. I’ve also enjoyed our game nights (at least those times when I’m not bogged down with other work). I definitely feel like I’ve made the most of my time working on the game (yet), and I’m looking forward to see where the game ends up in the next few weeks.
The following is about the particle system implemented by one of our graphics engineers, Qing Mao
Dynamically generated particles are widely used in games to make the visual expression more interesting and more interactive. One of the things I really like about it is that its a combination of both technical and artistic aspect.
You take something as basic as a white solid circle on a background like this:
Then you take some numbers and apply some math to it, then it becomes this:
I don’t know how other people, but it sometimes just feel like magic to me. > . <
The Particle System in UDK is a group of emitters, and in each emitter there is a TypeData which determines what kind of particle it generates. For example, you can use a 3D mesh instead of a 2D sprite, but I don’t think we will need that any time soon. There are also all kinds of modules in the emitters, which determine the attributes of the particles, e.g. how they act and what they look like.
(The Particle System Editor in UDK, I spent a lot of time playing in it. Tweaking the numbers is a lot of fun, sometimes really small changes can lead to dramatic different feelings in the particles.)
General Design
The design of the particle system largely depends on the overall visual design of the game. So, I spent a lot of time discussing with the artists about the art direction of the game. We find a lot of good art references, which helped a lot when I was actually creating the particles for our game.
Looking at the concept arts for our game, we are looking for an art style that is more cartoonish, funny and sometimes absurd if you saw Henry’s drawing about the lady blown up like a balloon when doing belly bump. So what the particles in a game like this should look like? We start by looking at games that have similar art styles as ours.
The first idea we come out with was Plant vs. Zombies: Garden Warfare.
We really liked the abundance of objects they used to fill the map with, so the view of the player was never boring. But we also felt that it might be a bit more realistic for our game. I personally really like the splash effects when the plants do attacking. There is actually small pieces of dirt (and fractures of peas) that splashes with the smoke. If our game would add an ability for the main character to break walls, I think I might try to add this kind of effects into our game. : D
Then our art director, Henry, mentioned Pikmin 3.
(Looking at the little shining stars among with the other particles, the feeling would be totally different without them. They are just so cute and pretty!)
Even though the environment sometimes feels too empty compare to that in Garden Warfare, and it is totally a different game type than ours, with a totally different camera angle, its detailed and elegant rendering of the objects just immediately captured everyone’s heart. Even though we might not be able to do graphics as good as this, at least it gives us a target to work towards.
Several days later, when I was struggling with what the smoke bomb effect should look like, Henry mentioned to me the movie Rise of Guardians.
The clip of the explosion of the Easter eggs totally matched my imagination of the look of the smoke bomb. A beautiful, thick cluster of smoke cloud, with a touch of mysterious color. This is it!
This is the current in-game version of the smoke bomb effect. I think it still have space for improvement.
Another particle system in the current game is the treasure chest.
In Game:
Currently the art team is doing a lot of changes on the treasure chest (texture, lighting, etc.) and thus the particle system would need to be modified quite a bit.
The biggest challenge for now is to create the particle effect that is used when the player gets the treasure from the treasure chest and when player drops the treasure. We referred a bit from the Sandman in Rise of Guardians, in which he forms different objects when the sand, and the sand disperses to form another object elsewhere.
To create this effect would require the location of the emitter to be dynamically changed in the game. And currently I am doing some research on how to accomplish that. Hopefully this feature would be able to be added in by next week.
If we have got more time before demo day, there are a lot of fun effects we could add into the game, for example, some sparks when player get belly bumped, and some little birds/stars flying on top the player when he get stunned.
It is just so much fun messing up with the particle system editor ^ O ^
