Dev Blog

We at Super God are already hard at work with new projects. Riptale still needs some updating with the Mac and Linux builds, but the people who cannot offer any help there are doing something quite different.

First off, we’re at the pre-production stages with a game we’re calling Saint John. It is an action platformer about a skeleton archer who’s cherishing his resurrection.

Second, we’re developing an episodic point n’ click spy adventure called Split Town. In this cold war era parody, secret agent Leonard Nimby is trying to prevent a horrible disaster from happening.

Future is looking bright!

Riptale has been on Steam for almost a week now. The reception has been positive. The Riptale Soundtrack is also releasing on Steam today. It contains a bunch of bonus tracks, some of which aren’t in the game at all. We tried to fit every piece of material in there that was worked on during the development.

What’s in the pipeline for us? We’re still fixing bugs and making small adjustments to the game, such as adding idle animations for the enemies. When we feel like the game is in a good enough state, we’ll do the Mac and Linux builds and the focus of possibly making even a mobile version.

These blog posts are turning into checklists, but that’s how the last few weeks have felt like; one checklist after another.

What has happened? Well, we moved again. And the state of AC in the new office suggests that we’re not going to be staying for long. It is quite strange how we haven’t been able to find a single office in Oulu that was designed with software development in mind. Yet.

Other than that, we held a Riptale test evening yesterday. It was a success. We discovered bugs that we had never seen before. No matter how solid you think your game is, just keep on testing. You’ll be surprised. It just takes someone who does things a little bit differently from you to bring the system down.

So, Riptale is launching next week. We still have no trailer. Luckily, we were able to record four hours of solid gameplay in yesterday’s event. Now all we need is a smidge of editing magic. How hard can it be?

The feedback about the game has been mostly positive, although you can’t really take anything people say at a face value. What matters is if the game excites new people enough that they’ll pay money to get a chance to play it. We think it’s got what it takes. Now we just gotta wait and see if our gut feeling is right.

If you are a streamer, YouTuber, or a game journalist, and you want a review copy of Riptale, throw us a request at our Keymailer.co page.

This week’s blog post is a simple announcement, due to various more important tasks at hand.

Riptale will be released on April 27th on Steam.

Enjoy the teaser trailer.

What a frantic week!

The release of Riptale is creeping closer. We’ve been doing a lot of work in Steamworks… now that we actually gained access there. Check your spam folders, people, if you happen to have one (our service provider failed to provide them). Adding trading cards turned out to be more work than anticipated. Not only do you have to draw the card pictures, but they also require you to do six different badges, five profile backgrounds, and five emoticons. Easy enough, but still something we hadn’t pre-allocated time to.

A proper trailer is something we want to do, but that’s a lot of work, too. For starters, somebody needs to capture a lot of gameplay footage for it and nobody at the studio has the time to do it. The editing work isn’t easy, either. We received a lot of comments about our Greenlight trailer saying that it had too frequent cuts and that you couldn’t really tell what was going on in the game. Fair enough. Professionals cost a lot of money, though.

Regarding beta tests, we’ve sent the builds out to our selected Linux and Windows testers. The Mac testers will receive theirs next week. We definitely want to support those systems, but it is possible that we’ll have to push the Linux and Mac versions a bit further past the initial Steam launch. Time will tell.

There was one specific section in Riptale that presented us with a lot of problems graphically. The Underground Forest.

The issue was that due to the amount of vegetation, enemies and platforms were incredibly difficult to see. Some of this was by design. To put it simply, there’s a reason why soldiers wear camouflages. It would add another level of challenge to the game. However, too much is too much, which is why we went back to the drawing board in hopes to find a solution to this conundrum.

During the many play tests an idea came up, that maybe the enemy sprites should have some red in them to indicate danger. Naturally, the screen is often filled with blood, but even so, we didn’t really see any downside in adding red color to the sprites, so that was the first change.

The other change (as you can see) was to the vegetation sprites. Any amount of white in the background graphics in a three-tone-palette adds confusion to the game action. This is why we decided to try “backlighting” the most dominating assets. It’s a trade-off, but one that’s necessary in an interactive medium such as games.

The downside to doing major changes to the tilesets is that now there’s a good deal of levels that need to be fixed before the game is ready to ship. Sometimes that’s necessary.

Since there’s no game made in this day and age that doesn’t have achievements, we also planned to include them right from the get go. For these purposes we’ve created a customized achievement system to suit our needs. This was done to ease achievement yielding process and some of them may yield an additional reward.

First we created an object called oAchievementListener. This object’s sole purpose is to listen to achievement progress. When the object is created, it will fetch current achievement data from a data storing/handling object we called oDataStorage, in which achievements are stored in booleans (set to false by default). All achievement data is written and fetched in and out of a file. GameMaker: Studio has methods to do this easily.

The achievement listener will proceed to listen to all achievements in step-event based on which achievement listening booleans have been triggered aka set to true. Some triggers are handled by the listener object. For an example, when a new room starts, it causes a Room Start event to occur, in which some achievement listening booleans might be checked based on some criteria. Some triggers are set elsewhere in the program.

When a specific achievement listener is triggered, based on what requirements the achievement has, the object will proceed to check out the criteria. If an achievement requires active listening, the object will count event occurrences or wait for something to happen. This will either set the listener off or yield an achievement. Achievement data is then sent to data storing object, which in turn will save it in a file. At the same time the program will send Steam API a message to unlock the achievement in Steam’s own system. Thankfully, GameMaker has built-in, easy to use tools to do this instead of having to write a custom plug-in.

This week, the programmer of the Spitter Dragon enemy talks about how to face the math-heavy challenges of projectile trajectories.

In the midst of brainstorming, came an idea of a stationary enemy that spits fireballs in an arc. This would be fine and dandy if it wasn’t for the fact that it meant I had to refresh my long-lost memories of physics math.

And so began the grand internet search for trajectory calculation formulas. There are a large number of those, but my personal problem is I never could be arsed to learn any of them when I was still in school (which I should have; have a +1 to score, my deceased math teacher). Thus, I have hard time reading them.

I managed to find some more down-to-earth explamations about how the formulas work, now I just had to translate them into GameMaker code. After reading and learning about projectile trajectory math for a solid work day, I managed to put together an unpolished formula that showed somewhat satisfactory results. Well, I am not satisfied until it’s actually good, but that would require more studies. Book shopping time it is then.

Oh, and now I have to figure out how to place this enemy in the game with enough room for it to operate.

This week the programmer who adjusted the jump system in Riptale talks about the process.

For gameplay fluency’s sake, we wanted to make it possible to perform a jump within a brief moment after passing a platform’s ledge and falling down. This can be done via a variety of methods, but the one we use goes as follows:

First, a method that detects whether you’re touching the ground, returns a boolean and stores it in a variable called e.g. “grounded”. Thus, whenever we read the variable “grounded” we know whether we’re touching the ground or not.

Next, we have a bool variable called “stillJumpable”. Whenever our player character is in grounded state, stepping over a ledge, and entering falling state, “stillJumpable” is set to “true”. During next frame, when the program reads player states and sees that we’ve entered falling state, it will check for “stillJumpable”. Since it will be true the first time it checks, we will now check if a timer or an alarm has been set, which it hasn’t by this point.

In GameMaker: Studio we’ve been using both GM:S’s alarms and manually crafted timers for different sorts of purposes. Here we’re using an alarm. Set the alarm for how long of a period of time after entering falling state you wish to be able to perform a jump. The alarm’s purpose is to turn “stillJumpable” to “false” after it has rang.

Right after the previous alarm check we have an if-statement check that asks for “stillJumpable” to be “true” and jump button to be pressed. If yes, then jump actions are performed and “stillJumpable” will be set to “false”.

This sort of optimizations are important, because they affect the feel of the game. It comes down to what players expect when they try to jump from a ledge. Without this method, it feels like the jump is disabled near the ledges when in fact the game is working perfectly fine.

This week, the programmer who engineered the dying effects in Riptale talks about the process.

Instead of just destroying the player character like alpha version did, we decided to make an actual death animation for our brave-yet-foolish hero.

When the hero’s health reaches zero, he will enter a dying state. With all character input blocked and facing fixed, the hero is sent flying backwards. Colors will flash between red and white for a couple of times for of a dramatic(ish) effect, which is done by using various blending possiblities in GameMaker: Studio. All movement and animation will slow down for a moment as we see the hero’s lifeless corpse fly and hit the ground.

It won’t end there though, as we wanted to spice this death up a bit. The hero disappears into the ground and a headstone will emerge from below in a slamming fashion. The headstone has a different symbol, an epitaph if you will, based on specified criteria. Game Over will be triggered using a timer that’ll start right after the headstone has run through its animation.

Riptale isn’t out yet, but we’re already looking forward. Since there isn’t that much art or design work left at this point, we can start to outline a new project. Concept art and discussions can go a long way when trying to make an idea feel more concrete. If you can start this process early, it’s a very good idea to do so. You want to have a solid understanding of the next game when the programmers start to leap from the previous repository to the new one.

The schedule of Riptale is still very much open. We’re exploring new ways to keep the project going for a little longer. We want to add some more functionality to the game, but whether or not that’s possible is unknown. Whatever the case, the old level files need some finishing touches, and the amount of files is quite daunting.

If you are looking for a place to talk about the project and maybe even pitch in with your own suggestions, take a look at our Steam Community Group. It’s still pretty quiet there, but the conversation needs to start somewhere. Another channel is our subreddit /r/SuperGodHQ. We’re keeping an eye on both of these places.

It has been an interesting week for Super God. Suddenly, we decided to switch our office to the Oulu center. It has definitely shaken us awake a little bit. Now we work on the same floor with many other game companies. It’s a bit of a culture shock. The incubator at Kielo was clean and modern space while our new location is a building that’s probably going to be torn down in the coming years. But it is closer to the action.

In other news, Riptale got Greenlit on Steam! And along with 38 other games, no less. It looks like Valve speeding up the process as they’re getting closer to shutting down Greenlight. We were thinking about releasing our data related to the process, but it appears no one would be able to utilize it in the future.

Getting greenlit, of course, is a happy occasion for us, but it is very much a new process for everyone around our office. There’s a great amount of documentation and digital paperwork we need to start getting through. Who knows what it will be like with our next game.

The Steam Greenlight campaign goes steadily on. No big surprises, nothing amazingly good, nothing dreadfully bad. Just pushing forward. Steadily. We’re currently in rank #22 (out of 2,380 games).

What this experience has taught us is that getting attention without a publisher is really difficult. We have been trying to drive traffic towards our Greenlight page, but the vast majority of people we have contacted just haven’t responded anything. In contrast to that, we have been getting a lot of emails offering us various marketing deals that sound inefficient at best.

The biggest bottle neck by far in the project is the lack of programmers. We are currently adding all the necessary features (menus etc.) and fixing problems with the basic gameplay mechanics. When that is done, the focus must move into adding content into the game. The art is already there. It just needs to be utilized.

Riptale is finally on Steam Greenlight. Is it even possible to write that sentence without the word “finally”?

So far the reception and amount of traffic has been really good. We’ve had almost 1,700 unique visitors in around 30 hours. However, the game is still on the front page of Greenlight. What happens after it drops off?

We expect the traffic to slow down radically when the game is not on the front page anymore. What hopefully will help is our email campaign. We’ve been sending messages to journalists, youtubers, and streamers around the globe with a press preview demo version of Riptale. The important part is to just try to get people on the Greenlight page.

In addition, we can start campaigning inside Steam. There are a lot of communities, groups, and individual users we could contact and try to get to help out the game. We are not worried about the outcome. We’d just prefer the game to be on Steam sooner rather than later.

Nothing more to say at this point, except Go Vote!

So, the Steam Greenlight didn’t happen, yet. What’s up with that?

To be quite honest, it wasn’t anything big. It was just a laundry list of little things. The game wasn’t ready to be handed to a bunch of journalists and streamers. Who knows if it’ll be when we actually do hand it out. What gave it away?

The problem with the project is and has always been testing. Sure, we test the game inside the company quite a bit, but we know how to play it. What happened when we gave it to an outsider? For one, we realized how broken it still was. Things that never happened to any of us started to pop up in an alarmingly rapid fashion.

Another issue was that the combat still wasn’t good enough. Sure, it’s a beta version. But we are banking on that feature. It needs to be tight enough so that when people try the game they will remember it. They need to believe in it. We can say, “Oh, the combat will be better in the release,” but seeing is believing. People are growing wary of promises about unfinished game projects. Our priority at this point is to at least show something good.

The programming department has been working hard to fix bugs and give the combat another layer of polish. We really want to get this game out in the public, but no promises at this point.

The design department recently started to investigate possibilities for a new game concept and dipped their toe into GameMaker Studio 2. It is a huge improvement over GameMaker Studio 1.4 but obviously still in beta and therefore has a plethora of minor annoyances that perhaps are fixed before an official release.

The biggest thing that could be said of the new and improved GameMaker is that it doesn’t constantly snap you out of the flow, anymore. As you’re working, you start to forget that it’s even there. You are making a game, not using GameMaker. It is also mostly very snappy, which is very pleasant.

There’s still a lot of room for improvement. But let’s start listing out things once the product gets out of beta. The big question is if the engine has any performance problems that would crash a game project halfway through.

Speaking of products and betas, we’re trying to get the press release version of Riptale out this week. If you are a games journalist and wish us to contact you, drop us a note through our website.

Is this blog post late? Apologies. The week has been somewhat hectic.

The press version of Riptale is starting to take form and we are trying to locate the people who might have an interest in covering it. There are so many outlets in form of streamers and YouTubers that finding the people who enjoy similar type of games is a bit of an adventure. Also, one must consider the size of the outlet. A YouTuber with a hundred thousand subscribers might not even reply to our queries while ones with a few hundred subscribers don’t really have the reach that makes it worth our while contacting them.

What about the press version, then? Things keep changing and so the release gets pushed back. That’s just the nature of the business. Currently, there are deficiencies in our programming department which makes implementing features painfully slow. But it’s getting there. Adding a useful tutorial was somewhat of an eye-opener. It really makes you think about how your game works because you’re expecting the player to go through the tutorial in a very specific manner. Everything must be foolproof and deliberate or otherwise the players might not understand how the game is supposed to work, or even worse, not be able to finish the tutorial.

Whatever the case, we need to get the game in Steam Greenlight. And through! That’s where you all come in.

Christmas came and Christmas went. Not surprisingly, not a lot of work got done. On the other hand, all of us had a lot of fun.

On a more serious note, we’re trying to get our Steam Greenlight campaign going during January. We also need to switch offices. Exciting times!

Graphics for Riptale are almost complete. The only things we’re adding at this point are minigames and enemies. The problem is that the programmers have way too much on their plate. The artists can quite easily keep adding sprites in the game, but implementing them in a way that’s usable in the end product is another story.

Adding enemies to the game is an iterative process, anyway. The artists draw out a plethora of sprites. The game is then tested excessively. If there are weaknesses in the design, certain enemy additions can help to correct them. On the other hand, many of the enemies end up not being used at all.

One thing that still needs to be added is graphics regarding the story of the game. It will be slides, plain and simple. The still take surprisingly long to produce. Maybe we’ll end up cutting the story a bit. Win-win?

(NOTE: Next post will be up January 3rd. Have a Merry Christmas.)