Doesn't they say the same thing about photography when it was emerging? ;)
Agreed. This is just depressing and is a detriment to society. If this keeps advancing at its current rate, good art will be so trivial to generate that it won't be special anymore. Art will slowly morph into a banal distraction, with creating an original piece being as easy as applying an Instagram filter. The role of the human artist will change from a craftsperson to someone who picks a bunch of parameters, gives it to the AI, and chooses the best output. This type of technology is a threat to the very existence of art as a craft, will completely devalue artwork, and will make the journey of training to become an artist obsolete. I hate these researchers for what they're doing to a field that I love.
I disagree. There will always be demand for real artists. Like any other digital software, this is just a tool with the possibility to help artists create compelling worlds faster and add realism that would otherwise have taken days to make using other methods. As a 3D character artist, I would love to use this to create quick backdrops to place my characters in to enhance final renders.
We were fortunate enough to talk to a small indie team Freshly Squeezed behind the award-winning game Defunct. Members of the team made a small post-mortem and talked about the creation of their first title, challenges they faced, the way they worked out the game concept. They also gave some hints on creating products with Unity.
Freshly Squeezed consists of seven people, who met while studying game design at Uppsala University – campus Gotland. After winning Swedish Game Awards: Game of the Year with Defunct we created the company and decided to move forward together and release the game.
Here comes a list of the company people, although we list roles for everyone, it should be remembered that we really do a lot more than our roles say, because of the size of the company everyone has to do a lot of things.
David is a programmer, third party manager and CEO. He handles the communication to outside companies and handles the operation of the company. His inbox is full of mails and his head is full of code, the perfect combination.
The multi talent of the team. He is mainly a programmer, but can really do most things; he has done some graphics, some effects, some level designing and some programming. You name it, he’s done it. He is also the only one on the team that has released a game before.
Robert is a designer and level designer. He also takes on the role of producer and project manager. The more technical of the art/design people. Half of the time he is occupied with making scrums, planning and producing, the other half he is making levels. When he is not doing either of those things he is probably teaching other designers and art people how to use different tools.
A visionary. A level and game designer. His mind is sprawling with ideas and he designs for a unique experience. A man with specific taste, but an open mind when it comes to games.
The animator who is responsible for all the character animations and he brings the Defunct robot to life with his masterful animations. When he is not animating he is probably playing Street Fighter.
The artist responsible for most of the 3D assets and concept art in the game. When he is not sleeping or making music he crafts the most wonderful assets for the level designer to put in the game.
The man responsible for the particle effects in the game. He’s also worked on some 3D models, pickups and water. He does a little bit of everything. A man that likes to sleep, and needs his power naps.
At university we were each part of different projects but during the last course of the second year we all came together to make a game. It was here that the journey of Defunct started, it got enough attention that we knew we had to continue working on it and that this was our chance to start our own company. Since then we have been working on Defunct and step by step making our way into the games industry. Now we have all graduated and are working at Freshly Squeezed full time.
For us as a company, and for most people in the company, Defunct is our first commercial game release and also the first commercial game we have worked on.
Jonatan: Defunct was an extremely iterative process from start to finish, with us scrapping, adding and modifying mechanics and designs constantly. We were not going to settle if players found the game boring or too confusing.
The game was initially created at our university within an 8 week deadline. Therefore we needed to transform the original concept, which was mechanically simple, calm and entirely story based, into something more accessible and action-filled.
Defunct became a full-blown arcade game where the plot (similar to the one in the final version of the game) was in the background. This, what we now call the alpha version of the game, was more about finishing a level as quickly as possible while collecting as many point-boosters as you could.
At the end of our ten weeks; people really enjoyed how the game felt and looked. However, few people actually understood the gravitize mechanic and played it “properly”. So despite how well the game was received and all the awards we won, we still saw the game as a “fun mess”, and weren’t satisfied.
We decided to make a complete makeover of the game, replacing all graphics, rewriting most of the code and created an entirely different level-design principle. We wanted an adventure where you focus on the gravitize mechanic and the story, rather than playing in an arcade-sandbox.
In the end, Defunct became a mix between the two. With a narrative-driven progression while including an arcade-mode to all levels, resembling the gameplay from the alpha. Because if there is one thing we noticed during the development it is that people who play tend to enjoy the game in very different ways, so including as many of them as possible seemed like the right thing to do.
Building the Right Game Feel
Petter: We did not have a standardized way of approaching building the game feel, it was mostly just trial and error while doing a lot of play testing to get the feel right.
As we made the game it became clear to us that we needed very high resolution terrain so that our character could ride smoothly on the surfaces. In other games where you drive cars or bikes on the terrain they don’t need as high resolution since they have two or more wheels connected to the rigidbody, automatically smoothing the values out. They also usually have suspension for the wheels smoothing the result out even more. Our character only had one wheel and no suspension but it worked great on the resolution we had chosen for the terrain in our game. Sadly when we updated to the Unity 5 engine the terrain collider started to interact strangely with our character and the terrain did not feel as smooth any more. We did not want to increase the resolution further for performance and production purposes, the higher resolution the unity standard terrain uses the smaller the tools for modifying the terrain gets which could be really hard to work with. Our solution was to interpolate the height values from the ground and smooth them out. In the end our character was never actually riding on the terrain, it rides on top of a plane that always lay underneath the player using the interpolated values. It’s like the character is riding on a magic carpet.
Interpolation was important for the game feel in other ways too. When the player is airborne he is always interpolating his rotation towards as good a landing as possible for the position where the landing will occur. This makes jumps feel very satisfying since you feel like the character is in control.
The most important thing to achieve a satisfying gameplay feel was just as simple as playtesting a lot. We looked at how the player was interacting and tried to see if there was some way to improve the experience, made small adjustments and repeated the process.
One of the trickier problems we had was to adjust the playtesting to how new players would play it. We all worked from home and did not have easy access to new play testers which meant that most of the playtesting were done by us, which could be quite misleading as we had played the game far too long, making us ignorant to problems we had gotten used to. We had also become good enough at the game to not feel that difficulty other players might struggle with.
One of the most important design decisions we made for the flow of the game was the ability to stumble around and over objects. We wanted to populate the environment with a lot of stuff so that the world would be enticing and to enhance the feeling of going fast as the environment flied past you. The problem was that you could very easily drive right into these things when going in high speed, making you lose all your momentum. That was a real flow stopper, so we decided to implement stumbling. If you are going a little bit faster than what your broken engine can handle you stumble over things instead of stopping at them. Stumbling over something is actually not slowing you down, but it still feels like an obstacle and something you want to avoid. This allowed us to have a lot of objects without interrupting the player’s flow.
We wanted to make the gravitize ability feel strong so that players would really feel its impact, and make them able to pick up speed easily. But we could not just make it as strong as we wanted. If it would be as strong as we wanted to in low speeds, the players would be way too powerful and reach max speed way too easy. Therefore we made the gravitize mechanic have a greater impact in slower speeds than in faster. This made it so that you easy could feel the impact in low speeds, but also make it more of a challenge to reach high speed and keeping it.
Other things that also helped the flow and feedback of the game were the effects we used, the different speed boost laid out in the game and the broken engines ability to get you a second chance by driving up on a hill and starting trying to get up in speed again.
Using Unity Engine
Petter: I would say that the most useful part about the Unity engine is the ability to iterate fast. It is quite easy to setup basic mechanics and features which is good for concepting and testing out ideas quickly.
The ability to change variables through the inspector is great since it makes for easy customization for multiple objects and for designers to change stuff without the need of digging into the code.
Unity has an easy way of making your own tools and extending the editor in a way that was really useful for us in some situations. We made tools to improve the speed of simple time consuming tasks, create assets like roads and ziplines much easier, improve performance and a lot more.
Another really useful thing about the Unity editor is that there is good documentation since a lot of people are using it. If you encounter a problem, someone has probably had that problem before you and you could search the internet for it. I would say that about 80% of the time you can find useful information about your problem and maybe even a solution directly.
Using the Unity Mecanim animation tree was really useful for us, as it is quite easy to setup and make the animations look much better since it has the ability to blend between them. I think that without Mecanim we would have encountered a lot more problems with our animations and would have to spend a lot more time getting them right, we would probably not get close to what they look like now.
We did not use a lot of tools from the asset store since we were very limited on money. Many tools could probably have saved us a lot of time but we could not afford to buy and test tools on the off chance that they wouldn’t be useful to us. The benefit of the situation was that we learned to create many of the tools we needed ourselves. Which will be a useful skillset to have. Some of the tools we did use are listed below.
- UVC, Unity version control. UVC is a version control tool that uses SVN as backend, which made it possible for us to work together on the project. It was extremely important to us during development and is also free to use which made it an obvious choice for version controlling.
- FMod Studio. David: To give our audio designers more control we decided to use FMod studio. It gave us the power to program sounds and make them context sensitive which we feel brought Defunct to life even more. The reason for using FMod Studio as supposed to any other similar software is simply due to their indie license deals.
- Steamworks.NET Petter: Steamworks.NET is a C# Wrapper for Valve’s Steamworks API. It was very helpful for us as it made it possible for us to use Steam’s API inside unity without the need to write our own Wrapper.
Building the visual style of the game
Mikael: To talk about how the style came to be we need to talk about the project when it was only an assignment for school. With the strict timeframe of only 8 weeks of production to fill the world with assets we had to come up with a time economical way of producing said assets. The first iteration of the art style was very simple and random. There were little to no thought behind the process of making the assets. The only thing in our minds was to produce stuff, do it fast and make it look reasonable coherent to everything else. In our minds a world with only a handful of gorgeous assets do not compare to a world filled with assets that might not have top-notch quality to them. Even if they don’t have AAA quality to them the world will still feel occupied and living, indications that someone or something is living in the world independently of the player.
One thing we did develop however was the texture process. It was very primitive so even the programmers would not have a problem jumping in and fill our shoes. By using the cutout filter in Photoshop on regular photos we got a result that felt adequate and gave a quite interesting result.
This mentality carried over to the second version of the game but more refined and thought out.
Anders: When developing the texture style for the new version of the game, we needed something very process-oriented, with clearly defined steps that could be followed to produce a coherent result whether the texture in question was for a rock, a car or a spaceship. There were two main reasons for this.
First of all, we are two very different artists with unique personal styles and completely different approaches to making art. Plus, we’re not that experienced yet. We needed to ensure that our assets would be compatible with each other in the game world. Also, there wasn’t a guarantee that we would be able to make all the game assets ourselves. If someone who was not primarily an artist would have to step in and make some assets, they would need to be able to make something that fit in as well.
The second reason was time constraints. We needed our texture process to be fast if we were to produce a whole game’s worth of art assets between two people. So, an art guide was produced, with an exact description of how to build a texture from the ground up. We start with flat colors, trying to give each part of a 3D model its own color to really get it to read well. Variations of color, for example patches of rust, are then added in using the Polygonal Lasso tool.
Then, we apply a lot of photo textures to add detail. We download royalty-free textures from the internet and run them through Photoshop’s built-in Cutout filter before multiplying them onto the flat color areas. We used this method to add in all sorts of detail, from metal rivets to wooden planks as well as dirt and grime layers. To add more detail and add visual interest, we add artificial shadows and highlights all over the model. If something is protruding out of the model, it gets a big highlight to make it read even better. If a part of the model is retracted, we put a shadow there, etc. The highlights are done by putting down shapes of pure white in Color Dodge mode, and playing around with the Fill value until it looks right. Lastly, we add a grain layer in Overlay mode on top of the image, to give it a little more grit and texture.
Anders: We decided early on that we didn’t want to include any normal or specular maps in our graphical style. Using only diffuse maps meant faster production time, and less risk of things looking bad. Our only option for normal maps at this point would have been to use an automatic normal map generator, which we tried briefly, but the results we got when we used it on our textures were pretty hideous.
Anders: The model style is fairly low-poly. Aside from being a stylistic choice, as sort of an homage to the old PS2 games we loved as kids, it was also for performance reasons. Being in school (soon to be fresh out of school) and with little experience in making 3D games, we weren’t sure how well the game was going to be able to run. Staying as low in polygons as possible was a way to cover our bases and ensure the game wouldn’t lag too badly as the levels grew larger. Of course, time constraints were also a factor, as simpler models are naturally faster to make.
When modeling, we focused on creating nice silhouettes. To achieve a fairly cartoony style, we played around with the silhouettes a lot, squashing and stretching here and there to make it look more interesting. Pipes couldn’t be perfect cylinders, they had to be bent and tapered towards the ends. If we were making a simple square-shaped model, the corners were pulled to give it a more cartoony shape. We also had the state of the world in mind. In the game world, these objects have been abandoned for a hundred years. Therefore we tried to make everything look as beat up as possible, pushing and pulling at the silhouette even more to achieve this look.
Aliens vs Earth
Anders: One thing we tried to convey with the in-game art is the juxtaposition of alien vs. human. In the world, alien robots crashed their mothership on Earth’s surface a long time ago and are now living on the planet as fun-loving little racer bots; playing around with old human architecture as they please, constructing ramps, halfpipes and dwellings out of old world materials, with some of their own technology added to the mix. We wanted to highlight the differences between the aliens and Earth by using color palettes and shape language; Earth assets are more brown/red and square, while the aliens are round, sleek and use the opposite side of the color spectrum with a lot of blues and teals.
Anders: In the game, there are a lot of assets that are completely identical apart from their colors. Examples include containers and cars, where we have several color variations for each. At first, each of these color variations used their own texture, which we realized was a problem. So instead, we decided to go with a more effective method – having only one texture and using a special shader that tints certain areas based on an alpha mask and vertex color attributes.
First, we created a new texture where the previously colored areas were pure white instead, and which also had an alpha channel to mask off those areas. Then, we went over each model and set its vertex color values to that same color that we used in the texture beforehand. Thanks to the shader that Petter made us, the masked-off areas were filled in with the correct color based on the vertex color value of the mesh. Now we only needed one material for all of the different colored cars!
Building the World of the Project
Robert: The world building was a real challenge. One of the design goals was to make it feel very open and because the robot’s speed is so fast it also had to be very large. We also made the world by hand, no procedural generation at all. So it took a very long time to place everything and fill the world with things. The world as a whole went through a lot of iterations and remakes as well, which added to how long it took to make.
We knew we wanted as few loading screens as possible so we decided to use streaming to load new maps while you were moving along. We split the world up into “Sections”. Each section was its own level, with a beginning and end, and its own theme; a forest, a junkyard or whatever. Jonatan and I had to work on different sections and then put them together to make the whole experience.
We began by just making the gameplay in the levels, then moved on to details and decoration. This was by far the toughest part to do. Because of the players ability to stop at any time, we needed to decorate the levels to a fairly high detail. This was a very time consuming thing to do, we had to just put down bushes and trees or whatever else and then playtest. We continued this way until every level had a high level of detail to them. Which for the most part wouldn’t be seen, because players might just drive by with high speed. In the end we decided that the time it would take to make the world as detailed as possible was worth it.
Jonatan: Guiding the player was quite tricky, since we often wanted huge environments you could play around in while always heading towards a specific spot. In places where you are not guided through a narrow path we wanted the player to have objects to follow, such as neighboring radio towers or asphalt roads. In open areas with battery puzzles, we use wires that connect the batteries to the door you want to go through. If these guiding objects don’t help a player on the subconscious level, they eventually are the only logical things to follow if the player would get really stuck/confused.
Creating the Character
Anders: When developing the character concept, I took a lot of inspiration from dirtbikes, sportbikes and segways. There were many concept images drawn that played with different aspects of these designs. In the end we settled for a very human-like robot that could animate and emote like a person, something we felt was important. In a technical sense, the design is very primitive, with a ball joint that connects the arm to the torso and a simple hinge for the elbow. Again, this was an issue of personal skill and time constraints. My only previous experience with modeling and rigging a character was one school assignment where we did that.
I wanted to make sure that I could model and rig it so that it would animate good, so that’s why I opted for a very simplistic kind of design. In a more general sense the design is very much inspired by classic PS2 games, especially Ratchet & Clank which is one of my favorite games ever. You can see the influences from Clank the robot, especially if you look at the hands of the character, which work about the same way.
Simon: I would say that the most interesting part about the robot which makes it feel alive is that it is not your typical stiff robot with no emotions; it moves and acts like a human would. The timing of its movements are also that of a human. It acts upon its emotions which is shown through various animations and cutscenes. For example, in the opening cutscene, the robot tries to fix itself but instead breaks his engine, and instead of acting like it is nothing it gets frustrated. When the robot picks up a collectable or things goes its way, it shows happiness.
To show that the robot is broken, it sometimes corrects its arm that gets dislocated and hits the engine when it makes weird noises. This also helps the character feel more alive.
Small Team Production
Robert: Our production was fairly chaotic. We had only done small 8 week projects before, so we really had no idea how to make a game over a long period. We didn’t have a game design document (when working on 8 week projects the scope was so small that we didn’t consider a full game design document necessary), so we never exactly knew everything the game would need. So making the schedule was a nightmare. I basically had to make educated guesses on how long things would take and what exactly we had to do. But in the end I had no idea if it would be enough time or not. Fortunately we did not have deadlines and milestones from an outside company until the last couple of months when the release date was set. So the schedule had a fair amount of wiggle room and the closer to finished the game got, the easier it was to make out what exactly was left to put in the game. Since we didn’t have any funding and didn’t have a lot of money, we couldn’t really afford spending money on things outside of licenses, so we had to use a lot of free software for the production.
We all worked from home, so we used a number of different communication programs. We used Ventrilo first, then Skype and then Discord. Because of the poor planning we had, communication became extremely important. We had to actively remember to talk every day and try to just work while being on whatever communication program we used at that time. We used Google Docs for people to write down everything they noticed needed work, or if they came up with something that needed to be done. So people could go into Google Docs and see what work had to be done. We also talked about things that had to be done and had a lot of meetings about what was a priority. It was constant communication. Often people would ask me what they needed to do next because we didn’t have a schedule that everyone could see, it was only I who had some kind of understanding of what had to be done and what time we had left. I gave out tasks to people depending on what was needed so communication was really important.
Later in the production, when I actually took the time to sit down and think about what was left, we transitioned into a scrum. We used HansoftX as our scrum software. There I would put in every task that needed to be done so people could see what they had to do. We had to iterate a lot to find what worked best for us. We tried to have weekly sprints, so every week I updated the scrum with new tasks and removed the tasks that were done. We tried different layouts; team based or individual based. Eventually we found something that worked fairly well, which was just having a scrum that got updated continually. When someone came up with a task that needed to be done we put it in the scrum right away and when I had the time I went in and removed the tasks that were done, to clean up the space.
One of the things that happen when you are a small team trying to make a fairly ambitious game is that you quickly notice everyone has to do a lot of different things. I was not just a level designer, I took on a number of different roles, like production managing and sometimes a bit of producing. This applied to every member of the team, and I think this was a big part in making the production a bit smoother, having an open mind to who does what and making sure people are not overworked. If the artists had too much to do, the animator (who perhaps didn’t have as much to do) stepped in and helped the production.
Fortunately everything worked out in the end, but I wouldn’t recommend doing what we did. Having a design document is extremely important for making a schedule. Seems obvious now, but was very easy to overlook at the time.
This was a real problem, the production was a very bumpy ride. We had no design document, so much of the game was designed on the fly. Which could create problems for things that were designed earlier or later. So we had to redesign things constantly.
Because of this we also couldn’t make a very good schedule or have internal deadlines. Since none of us was really sure on what exactly needed to be done, or what exactly the game would be. A problem that arises from poor planning is also a split vision of the game, different people working towards different goals can create conflict as well.
Production pipelines were also affected by poor planning. Some people had a much harder time to work because some production pipelines were never planned. A lot of assets couldn’t be used or had to be redone because of the poor planning. Optimizing also suffered from poor planning. We didn’t do any tests beforehand, so we didn’t exactly know how many assets we could put on the screen or how big a level could be.
The lesson learnt is that the time spent planning things is easily regained later in the project, because a lot of things don’t have to be remade and the game gets better. Also many problems will arise in the planning stage, instead of surprising you in the middle of production, where it is much harder to do anything about them.
Working apart from each other
During most of the time of development everyone worked from home, as we don’t have an office and we live quite far away from each other. This made the development harder as you got feedback much slower than usual and don’t have as easy access to questions and such. When working together it is quite easy to just grab someone that is walking by to ask for ideas, or to see someone struggling with something that you might have a solution for. When working at a distance these kinds of things are not as easily accessible and the project will suffer for it both in quality and development time.
Marketing and Promotion
David: Marketing has been the hardest part for us, we’re all just developers and have no clue on how to get the word out there and that’s why we got in contact with a company called SOEDESCO. They have handled press releases and other things we weren’t quite sure on, as well as giving us advice for the future. We also try and mail as many people as we can, we have some contacts in the press that we’re using to try and get reviews and we’re not picky with who we send review keys to.
We’ve started to get some attention from some speed runners which we’re extremely excited about since we’re all fans of speed running. We are trying our best to support the community by not destroying their exploits. Lastly, award submissions will probably be a big part of the future of Defunct. Our old teacher Marcus Ingvarsson is very adamant about the importance of awards, even if you don’t win them. It’s basically about putting yourself out there, submitting the game to various awards is how the project got from a prototype to a full game, it only seems right that it’ll continue playing a part, even after the game has been released.
Special thanks to NP Statham for his help in arranging this interview.
Source: Freshly Squeezed