Name change announcement – Tremors is now Mega Magnitude

I decided to change the name of the game from Tremors to Mega Magnitude.
The name change happened because several people commented that they thought my game was about a movie with the same title, even though it has nothing to do with it.

I liked the name Tremors but for the sake of clarity I decided to change it and I think it’s for the better.
With a new name I also created a new website for the game and this new blog that will cover all of my games past, present and future.

Mega Magnitude (ex Tremors) will come out for OUYA in June and a bit later for PC.

I will soon redirect this site to point at the new address and after a couple of weeks I’ll let this domain expire.

This blog is also moving over, see you on Vatigo Games

Tremors – beta update

Work on Tremors continues… changes include:

  • improved player sprite to make it more visible
  • more light added to the scene
  • new progress indicator at the top right
  • dangerous cloud of dust coming from the above :)
  • previous longest distance line (record line)
  • various effects not visible in the screenshot (I’ll make a gif for the next update)
  • and more…

Tremors beta screenshot

I hope you like this update and of course – more cool stuff is coming soon.

For more info check my Twitter profile: @igovat

UI stuff

Everybody likes to code the fun bits like game mechanics, but the so called boring parts of development have to be done as well.

Since I’m working alone on this, that’s pretty much what I’ve been doing this past week, so here’s a screenshot of the game over screen as it looks right now (exciting!)

Game Over (work in progress)

Game Over (work in progress)

You can’t see it from the still image, but it’s all nicely animated too.

Anyway, it’s not completely done yet, I’ll change some things like fonts and maybe even the background, but all the functionality is there.

Here’s a mockup of the store where you’ll be able to buy upgrades to help you survive.

Mockup of the store screen

Mockup of the store screen

In case you were wondering, I make the mockups in Inkscape, a free and open source vector graphics editor. Go give it a try!

Feature creep life cycle

Feature creep is the number one enemy when it comes to finishing a game (or any project for that matter), and most of us developers need to learn how to deal with it.

It’s always the same story, at the beginning, you get an idea for a game, and it’s a cool idea, so you decide you’ll start making it.

During that process, which takes anywhere between a week to a couple of years, you kind of get bored with your original idea. It’s just not fresh in your mind anymore… and that’s when new ideas start coming up with their promises.

- “Add me, the game will be so much better”, they say. And you believe them, why would they lie? But you’re still not convinced.

- “Come on, it’ll only take you a week to implement me, tops. I bet you could do it in 3 days time ’cause you’re awesome like that.”

A bit of sucking up never hurt anybody they think, but the fact is, they’ll do anything just to try and get into your game.

You stop for a moment. “Maybe you’re right”, you think. “OK, but only you OneLittleFeature and that’s it!”.

But it’s not over, the ideas multiply and start bugging you again. You ignore them.

Then OneLittleFeature, now implemented, speaks up: “We both know I’m cool, but we also know that I would be much cooler if my bigger sister ALittleBiggerFeature could join me.”

- “No way!”,  you say, “I only allowed you in and while you did make the game better, it’s enough”.

- “OK, no need to get so worked up about it, I just wanted to help… excuse me for thinking you wanted to create The Best Game Ever instead of the Mediocre Forgettable Experience 2″

Needless to say, Mediocre Forgettable Experience 1 is implied to be the last game you made.

Soon, the doubt starts to grow inside your mind – “What if OneLittleFeature is right? What if ALittleBiggerFeature will really make my game 200% better?”.

“No, my original idea was already great”, you say to yourself, but OneLittleFeature and other new ideas will keep trying to persuade you that your game is shit unless you implement them. It takes a really strong mind to ignore them and one by one, they start to squeeze through that hole of doubt that they’ve made inside your mind…

Features are added, and the project grows bigger and bigger… additional features are now larger than the original game was supposed to be. The gameplay suffers, you can see it deteriorating, but new ideas, as always, are here to fix that…

There comes a time in almost any project when you need to look at what you’re doing and what your plan is. You take a look at your original plan for a “2 month game”. It has become an unrecognizable monster. The transformation is so severe that the game possibly even changed genres.

At this point you begin to see that you’ll never finish it. “Enough is enough!, you pound your fist on the table.

- “I’m cutting you all out!”

Ideas and features scream, they plead, they beg for mercy, they insult you if nothing else works… but you’re determined – this has to stop.

After the big feature massacre you’re tired but ecstatic. You did it! You fought the monster! The game is now tighter and has a clear focus.

It also looks like you can finish what’s left in a reasonable amount of time.

But you must stay vigilant and you have to act fast.

You can already sense some new ideas lurking and waiting for your moment of weakness.

New logo and website design

Hello everyone! You might have noticed that things have changed a bit around here :-)
I took some time over the last few days to create a new logo for Tremors, as the old one was just a crappy temporary placeholder.

You can see one variation of the new logo in the header at the top of the page and another one here:

New Tremors logo

New Tremors logo

I also found a cool and classy new theme for this site (called Suits) that matches closely what I wanted; It’s simple, elegant and it looks great.

Another art related thing I worked on was a banner for the game:

tremors game ouya icon

With the rubble in the front and a survivor behind, I think it presents the game’s mood well and creates a sense of optimism and hope. At the same time, I think the character has a feeling that his escape is only the beginning, as he wonders what happened to the others. Have they been lucky enough to survive?

I am proud of these new assets and I hope you like these changes as well.
More updates are coming soon!

Back to basics

New week, new update on the development of Tremors. I pulled out the old prototype of Tremors and playtested it against the new, reworked levels. For reference, this is what that early prototype looked like:

This is how early Tremors prototype looked like

This is how an early Tremors prototype looked like

Yeah, not exactly pretty, I know, but being pretty is not what prototypes are for. Turns out, prototype level has tighter gameplay than some of the reworked levels! As I was playing it I immediately saw how to make peace between the new and the old, how to take the best of both worlds and make the gameplay airtight once again.
Here’s the before and after comparison (click the image to make it bigger):

One level in Tremors before and after the redesign

One level in Tremors before and after the redesign

Please ignore some graphical improvements, the big change is that floors are now one above the other, all have constant width and fit on the screen without scrolling.
Also, hallway and doors that are the exit of the level (not seen on these screenshots) are now part of the first floor, not a separate floor as before. I’ll experiment with these changes some more but I like the way the game flows with this setup much more.

I’ll finish this post with a teaser GIF for one of the next updates:

Tremors - flames

Burning down the house!

Let there be light – with Box2DLights

This time I have something really cool to show you, I’ve added dynamic lights to the game and it’s a noticeable graphical improvement. Shadows and lights look great and contribute a lot to the overall atmosphere of the game.

Here’s a couple of screenshots of those new lights in action

Tremors game lights and shadows

Tremors game lights and shadows

Tremors game lights and shadows

I hope you like it, I think it looks rather dashing, well at least compared to how it looked before ;)

The best part is that this improvement was actually incredibly easy to implement thanks to Box2Dlights. It is a brilliant and elegant library under the Apache 2.0 license that integrates beautifully with LibGDX projects.

The performance hit is not noticeable on the desktop, I haven’t tested it on the mobile yet, but if necessary, I can include the option to disable some of the more demanding graphical effects in the game.

Speaking of performance, I’ve implemented a progressive loading of the levels so objects that are not in the scene do not waste memory or CPU time. This speeds up the game on low end hardware and it will also allow for more objects in the scene at any given time.

One more screenshot if you hanged on till the end of this post ;)

Tremors game lights and shadows

Tightening the control

One of the most important things when developing a game is character control. It’s something that can truly make or break the player’s experience. Mastering the deliberately clumsy controls is even used by some games as their main mechanic – there’s Surgeon Simulator and QWOP to name a few, and there are many others. These games have purposely difficult controls and player’s attempts to control the character often have hilarious results.

In games where difficult controls aren’t deliberate design choices, poor controls break immersion and frustrate players, ruining their experience and causing them to give up on the game.
That’s why I’m very focused on making the character control feel right, and there’s no magic formula, I just tweak the hell out of the various speed, acceleration and friction variables until I get exactly the kind of movement that I want.

Being forgiving

Sometimes, and I’m sure you bumped into this as well, you’re sure that you pressed the button at the right time, but your beloved hero ended up in the pit full of spikes. If you’re not making a platformer with pixel perfect jumps as a core mechanic, consider being forgiving to your players. I think that whenever possible, you should anticipate and react to user input. What I mean by that is that a game should allow the player to press a button a bit too early or too late and still execute an action that they want. In Tremors I implemented forgiving controls for jumping and rolling. In essence, when character starts falling from a platform, you still have a small time window to press the jump button and the game will react. Similarly, if you press the roll button while you’re still in the air but close to the ground, the character will roll when it touches the ground.

Exaggerated example of forgiving controls

Exaggerated example of forgiving controls

These two tweaks in controls took several minutes to implement and they make a world of difference. Players find the game more responsive and are no longer running into walls because they tried to roll while the character was still a few centimeters in the air. I think it’s a great change because I don’t want the game to be difficult because people didn’t time their button presses perfectly.