Superku

Felix Pohl is one of the top Gamestudio programmers; any forum user can testify it. Not only that, but he also takes the time to answer other people's coding questions and shares his great code snippets with us. Superku, one of his amazing projects, is being discussed in this month's AUM interview.

Q: What type of game is Superku and what makes it unique?

A: Superku is a modern approach on the classic side-scrolling platformer genre and is inspired by games such as the 2D and 3D Mario and Metroid games and some other titles which I used to play and love growing up (mostly on Nintendo platforms). Contrary to many more or less recent indie titles, Superku does not focus on a single unique mechanic, but gives the player a bunch of abilities and challenges him to use and explore those in various situations, with a heavy emphasis on actual platforming and less on puzzles.

The game has a story which starts out as a basic rescue mission, so the player gets into the action quickly, without having to read or watch minutes of cutscenes and story, but soon (as you enter the big tower after the first 5 levels) it gets obvious that there is more to it than meets the eye.

You control the game's main character Superku, the son of the missing hero with the same name who battled darkness and evilness many years ago, and experience the game and story through 40 varied linear and non-linear levels, either by foot, flying in spaceships and planes, skateboarding and so on.

Here lies Superku's strength, too, that is huge variety, versatile movement and precise controls and a medium to very high difficulty that will provide a fair but tough challenge even to experienced gamers in later levels.

Q: You have built one of the few games where the player can actually walk on walls and ceilings. How did you do that?

A: This is probably the easiest part of the movement code. Superku's main action basically is a state machine where the default walking and running state is by far the most complicated code (especially because of some special circumstances and obstacles and the like which only occur in one or two levels), the (vertical/ horizontal) wall running stuff is each only about 100 lines of code short. There are no special tricks involved, just some c_traces and c_moves and should be pretty straightforward to implement if you are interested in doing so for your own game.

Q: How does the “unlimited levels” feature work?

A: At first I planned to feature certain gameplay elements, variations and styles in multiple levels, that is create two or more levels in snow, darkness and so on but then I scrapped that idea and only applied those on single levels each.

As a result, there is only one unlimited level in the final game which is inspired by those of old 2D Mario games. The camera auto-scrolls from left to right and you are offered multiple ways to pass the current room. If you fail to choose and go the designated route the room will repeat over and over until you figure it out (you get help in form of visual and acoustic cues).

Q: What was the most complex piece of game code and how did you implement it?

A: By far the most complicated and frustrating thing that I tried to implement was rotating levels (which to my knowledge still has not been done in any regular platformer apart from games like LocoRoco or similar). The natural way probably would be to rotate the camera and the player as well as the gravity but as I've already had way too much movement code completed and wanted to do partially rotating levels as well I had to try and go a different route. I've spent 2.5 to 3 months of my free time working on this feature consecutively but in the end it did not work out, which frustrated me so much that I almost stopped working on this game simply because of said failure. Especially the transitions from wall to ground and vice versa, which occur on the rotation of a platform (wall) and corners turned out to be highly problematic. At first I blamed acknex' native OBB collision detection for the issues, which led to me writing my own AABB movement function, surprisingly without a single noticeable difference because all problems remained. It was not really a coding but a conceptual problem, including but not limited to Superku's behaviour to slip on steep surfaces and to align with sloped ground (which is why future movement codes of mine will most likely not do said things and rather stick to a Super Mario style ground treatment).

Q: How do the grappling hooks work?

A: As I've said before Superku's primary action is a state machine, so is the grappling hook which basically only realizes some sort of pendulum. The difficult part however was to allow and implement player input as a mixture of direct and pendulum movement (i.e. steering against the pendulum, holding the maximum point a little longer, starting from standstill and so on). If I kept it realistically, the potential of this ability in terms of gameplay and skill would be very low. The only thing you have to take some special care of when implementing grappling hooks and other abilities via a state machine is transitions between different modes. This can get especially tricky when you have to blend animations (as well as attack animations that can range across various states), so the best solution I could come up with so far is to have a separate function that handles the animation of all modes. (Almost) nothing gets set or changed by states directly, instead said function observes player behaviour and movement and tries to animate accordingly.

Q: The game includes stuff I’ve seen in some of the Mario games, but also lots of unique ideas that are perfectly implemented. How do you get the inspiration to create these things?

A: I've always been more of a (gameplay) coder than anything else, in particular my level design skills are severely lacking. I had to learn this for Superku and not try to follow a Super Mario style of levels but find my own level design style which makes use of all available abilities, verticality and oftentimes non-linearity. This resulted in about 50 deleted levels (or rough level sketches) and basically all of the remaining levels which found their way into the game have been remade at least once. I still find it hard to keep a level going for multiple minutes without repeating too much of previous stuff which is why most of the levels can be completed in about 120 seconds (and thus most of them don't have checkpoints) if you are just fast enough. Instead of trying to come up with new challenging platforms and sections over and over I try to implement completely new stuff (such as a new vehicle or the like). Then I can spend most of the time coding and fiddling on gameplay stuff instead of spending my time in WED, so it's more like a “forced inspiration”, which most of the time means I'm drawing and sketching stuff with pencil and paper.

Q: I want to buy a copy of your game. When will I be able to do that?

A: Currently I'm working on the finale of the game, then only two more levels need to be created, all others are at a stage where they are at least playable. We all know how much time game development takes so I say don't expect it to come out before November of this year.

Obviously I will try to get my game on Steam first, should Greenlight still exist then I would be happy for every vote that I get!

Q: Please give us some tips for the beginners to game development.

A: As a long-time reader of the AUM, issue #3 or #4 to be precise, I've thought on numerous occasions when reading the interview and this question in particular what I would say as the interviewee. Now that the time has come I can hardly think of anything I wanted to say, however please hear the following:

It should be obvious, but please don't try to create the next best Skyrim / GTA / CoD / Assassin's Creed because there were a few things you did not like about it / could have been done better in your opinion. This is just doomed to fail and even though you may and probably will learn quite a few things doing so, you end up with nothing presentable and probably get frustrated; it will always fall short compared to the triple A titles. In short: Start small.

However, even when you start small, that does neither mean that you will someday be able to create such games on your own (you won't, no hobby developer can) nor that your games have to be or stay “small” at all. To me the phrase “start small” means something different but very important, that is ask yourself what you want to create and if the answer is “an RPG /... like *insert AAA title here*”, start again with the very same question.

Try not to think in terms of numbers or approaches like “better / more / ...” and so on, but what would result in fun game mechanics. Start with a prototype, not with a design document. Iterate on those prototypes until you have something fun and playable in your hands – this is btw. how Nintendo does it and always has done it - then think about content creation.

Find a way that allows you to create content quickly, even if that means you have to lower your sights, don't blindly stick to any design document or notes that you made some time ago. A perfectly functional shooter script does not count that much when you are not able to create the levels necessary for a good experience. You may be thinking that you could hire or find a level designer which does the work for you, but you have to realize that it is most likely not going to happen, no hobby developer creates some 12-15 nice and complete levels for you and buying them in pieces (from online shops) will most likely only result in an expensive, but inconsistent mess.

Then find a graphics style that suits your needs and obviously fits to the game (and to a degree to the story and atmosphere), again with a focus on preferably low effort in terms of work. A tip: Heavy normal map and other fancy map usage as seen in modern triple A titles is most likely not the way to go; in my opinion, at least 99% of hobby or indie generated normal maps just look awful. They need to be generated from high poly meshes to look at least decent, which conflicts with quick content creation.

This leads me to my last point: delete stuff! Delete normal mapping on your walls, don't keep it just because you spent some time implementing it, or because most other big games have it. Delete levels, delete gameplay abilities, remove SSAO from your game if it does not enhance its visuals, remove or decrease Bloom and especially remove DoF (in most of the games it does not only look bad, but has no right to be there at all and only hinders the experience) and so on.

This probably was the most important thing that I learned when designing and working on Superku, I removed over half of the abilities (such as double/ triple jump, a flying mechanic, a split-up ability, …) and levels, which only resulted in a better experience and overall game.

Thank you a lot, Felix!