Johannes Vuorinen, the developer behind Trials Evolution's highly-praised level editor, went indie earlier this year, taking everything he learned at RedLynx into his independent work at Frogmind Games.
Along with his partner Juhana Myllys, Vuorinen revealed Badland earlier this month, a side-scrolling action game for iOS devices, that is proving to be one to definitely watch.
Vuorinen has found that moving from "triple-A" to indie development has many advantages, and has helped steer him in a favorable direction. Here, the Frogmind founder details his top five lessons learned from his time at RedLynx.
1. The whole process familiarized
"While working with Trials Evolution, I had a perfect opportunity to see the whole process of triple-A game development," says Vuorinen. "I learned about the various milestones which are included in a triple-A game project from the first playable to the release candidate, and all the tasks related to those."
"On the technical side, I learned of course various details related to programming, but also many helpful tools, such as the huge importance of a CPU/GPU profiler to boost up framerate and the importance of making the "code change -> test -> code change" loop as short as possible."
On top of these tools, he also learned the importance of libraries like FMOD for sound, and Bullet Physics for physics-based action. "The knowledge I got by using these is now really useful when developing Badland," he adds.
"In addition, on the side, I learned about various marketing methods and events, which again brought me useful knowledge. It was also really interesting to experience how the development team worked together, especially sometimes in very stressful situations."
2. In-game editors are awesome!
"I must say that by far the most useful knowledge I got when working with Trials Evolution was the in-game editor and all the experience I got when working with it," says Vuorinen.
"Having the track editor inside the game itself and having level designers using it and testing tracks with the same controller and machine which the end user is also going to use is just awesome. If the level designers would have used some separate in-house PC editor with mouse and keyboard, the in-game editor would have not been nearly as good as it became."
As a result of this, Vuorinen believes that the tracks within the game would have also taken a hit in quality, such was the importance of the editor.
"I got constant feedback from the level designers on how to improve the editor and its UI to ease the development of the tracks," he adds, "and so the editor, and also the tracks made with it, kept improving all the time."
Vuorinen suggest that those studios looking to build an in-game editor to either help with development, or to provide user-creation tools, should consider why they aren't gunning for both.
"Why develop an in-house editor for years which is going to be used by only a few people?" he says. "Why not develop the same thing for everyone to use?"
3. Good ideas become awesome in small casual group discussions"I remember tens, or even hundreds of times when I had some idea and I went to quickly discuss it with one or two of my co-workers (informally, without any scheduled meeting)," Vuorinen tells us.
That good idea rapidly evolved into something brilliant, as his colleagues offered their own tweaks here and there to the base concept.
"This is something I want to emphasize a lot. But I have to say that this doesn't necessarily work too well in meetings of, say, more than five people, because usually everyone has something to say and the discussion often tends to derail to something irrelevant and the whole discussions just becomes a waste of time," warns Vuorinen.
He continues, "Talking about meetings, it's sometimes really surprising how much time can be wasted in meetings where tens of developers gather and some guys end up talking about something that 90 percent of the room does not care or even understand. But, this isn't an easy problem to solve because, on the other hand, these kind of meetings, especially if there are people from different fields of development, can sometimes be really fruitful too, leading to new fresh ideas which can make the game better."
In fact, argues the Frogmind man, sometimes just talking with a tiny group of people can lead to you realizing yourself how to improve the concept, simply because you said your idea out loud.
"It's funny when this happens, but I guess talking aloud and explaining things to others activates the brain differently," he explains. He notes that this works particularly well as part of a two-man team, and that if his team expands in the future, this is one key piece of advice he will always keep in mind.
4. Everyone has their own method for being efficient
"I have noticed that for me, good ideas and good code do not tend to come by force," says Vuorinen. "I cannot say how many times I have figured out a way to implement something or solved a design problem outside the workplace."
In fact, a lot of his most successful ideas have come to him while he was on the train to work. "But even that doesn't work if I am exhausted," he adds. "I have learned that by average my maximum period of efficient coding per day is somewhere between 9 to 10 hours. And I want to really emphasize the word efficient. Of course I can sit coding 12-plus hour days, but the quality -- at least in my case -- will eventually be terrible and the solutions will probably need to be fixed some day. In the worst case scenario, the whole 12-plus hour work effort could require a code rewrite of 12-plus hours."
With this in mind, Vuorinen argues that every person should make sure they know exactly what makes them the most efficient and motivated. "No one else can know it better," he says. "Forcing to some kind of common work format might only lead to less efficiency and also poorer motivation for that given individual."
This can be difficult in larger teams, where all the employees need to have common rules so that everyone feels equal, but is great for indie devs.
5. Self-confidence boost
"Lastly, one really major thing that has to be mentioned was the psychological factor of developing an triple-A game," says Vuorinen.
"Having finished Trials Evolution successfully and read all the praising reviews, this really gave me a nice boost on self-confidence. In addition, I realized that although triple-A games are created by really talented guys, they are not gods (although some of them are at least demigods!)."
"After Trials Evolution, I felt that I was ready to create something my own."
The Badland designer concludes, "Being part of an triple-A game development team was really helpful and gave me a lot of experience both inside and outside the code itself."
Ineffective meetings should be destroyed. Like the minute some yahoo goes off on an irrelevant tangent he should be stopped by the dude in charge. If that causes conflict then there is an issue of authority, or the wrong people are in the meeting.
The title said "5 lessons from going AAA to Indie" but this was really about his lessons from developing on AAA and contrasting the differences between his experiences with large and small groups of people.
I think the title is misleading.
In fact, argues the Frogmind man, sometimes just talking with a tiny group of people can lead to you realizing yourself how to improve the concept, simply because you said your idea out loud.
Never, ever, have poor meetings.
(the title of the article is quite misleading because I was the main programmer in the Trials Evo's editor)
I think the title is misleading.