Making Games Run Smoothly With Delta Time

One method of animating, moving, and timing things in games is to programmatically change certain values on each frame update. However, if you update with a specific value every frame, for example, moving an object down one pixel every frame, then, with fluctuating frame rates, the speed of this action may seem inconsistent to the player. In that case, the player will experience both a choppy frame rate and a fluctuating game speed.

But if your game already runs smoothly, so why should you worry about it? Well, even if it does run smoothly, there are constant small changes in the frame rate. To compensate for this, you can use delta time. This helps ensure that your game runs more stable on older devices.  More significantly, frame rate often drops noticeably when the device is displaying notifications or when your game is processing something heavy.

In my opinion, all games should use delta time, no matter the size and depth, if you want the game speed to appear consistent.

What is Delta Time?

The word delta means “change,” and thus delta time means “change in time.”

In games, delta time is a compensation value. In practical use, the delta time value is multiplied by values that are affected by time. When the frame rate is lower, affected values increase to compensate for the time gap, or decrease for fast frame rates. If your frame rate is consistently 60 frames per second, then the delta time value is 1.0, effectively enacting no change. If the frame rate drops to 30 fps, then the delta time increases to 2.0, making all values twice the size to compensate for the slower frame rate.

Where to Use Delta Time

• For a moving object which changes position, rotation, or scale.
• Manual countdowns in the frame update, as you may want these countdowns to reflect time instead of how many frames have passed.
• Most values which are changed over time.

The Delta Time Function

The function below calculates the delta time value which you can use in your frame update function. Corona games can run at two different frames-per-second rates: 30 and 60. The function below is set up for 60 fps, but you can adjust it for a 30 fps game by changing (1000/60) to (1000/30).

local runtime = 0

local function getDeltaTime()
   local temp = system.getTimer()  --Get current game time in ms
   local dt = (temp-runtime) / (1000/60)  --60fps or 30fps as base
   runtime = temp  --Store game time
   return dt
end

If you print out the delta time value for each frame, it will look something like this:

0.95916, 1.00638, 0.924, 0.9667, ...

The value will be very close to 1.0 when the game runs at 59-61 frames a second, but it will change more significantly if the frame rate fluctuates more severely.

Implementing Delta Time

Assuming you have the above function in your game code, implementing delta time shouldn’t change your existing code too much. However, just be careful to only multiply it by changing values, not the entire value, as illustrated in the code below.

--A box object
local box = display.newRect( 50, 0, 100, 100 )

--Frame update function
local function frameUpdate()

   --Delta Time value
     local dt = getDeltaTime()

   --Move your box, 5 pixels with delta compensation
     box:translate( 0, 5.0*dt )

   --For rotation...
   --INCORRECT: do not multiply with the entire value!
   --box.rotation = (box.rotation+1) * dt
   --CORRECT: only multiply with the changing value:
     box.rotation = box.rotation + (1*dt)

   --Same goes for scaling...
   --INCORRECT: 1.0 and 0.01 have to be separated, as 1.0 represents the current scale:
   --box:scale( 1.01*dt, 1.01*dt )
   --CORRECT: only affect the changing value
     local scale = 1 + (0.01*dt)
     box:scale( scale, scale )
end

--Frame update listener
Runtime:addEventListener( "enterFrame", frameUpdate )

Testing Delta Time

To confirm that your setup is working properly and that your game has become “framerate independent,” just change the fps value in config.lua to 30 and 60, back and forth over several tests. Your game should appear to run at the exact same speed, except that the 30 fps tests will likely seem a bit “choppy.”

application = {
   content = {
      fps = 60  --Switch between 30 and 60 over several tests
   }
}

That’s it! Your game should now appear to run at the same speed no matter what the frame rate is. This technique can be used for all types of delta-related processes, so feel free to expand its functionality to suit your needs.

Last week, Apple announced iOS7 Beta at WWDC. A lot of cool stuff was shown. The interesting thing is that a lot of the “flat” UI that was demonstrated was exactly the kind of thing we saw some of you already creating using Corona’s graphics system.

For example, this app was in the works before iOS 7 was even announced!

Apple’s NDA prevents me from talking too much about iOS7, but what I can say is that we will fully support iOS7. In fact, last week, starting in daily build 1141, you can try your app out on iOS 7 Beta. On the right, you just select “7.0 beta” from the iOS device build dialog in the Corona Simulator, and presto, you’ve got an app built against the iOS 7 Beta SDK that you can test on your own device.

I really recommend you do try out your apps on iOS 7. If the past is any indication, we expect iOS 7 to introduce regression bugs that affect all iOS developers, not just Corona developers. The sooner you know about them, the less you’ll be surprised when iOS 7 is finally released!

(Our lawyers will bug me about this, so let me just remind you that if you are using iOS 7 Beta, you must honor Apple’s developer membership rules.)

We also have upgraded Corona’s Facebook support on Android, so it’s on par with iOS. Now, you can run Facebook’s Scrumptious sample on Android just like you can on iOS.

We’re also working on adding Facebook monetization features like Mobile App Install Ads that can help drive more installations of your app and increase discovery, all things that will help you make more money with your app! This should be coming in a daily build later this week.

There were a bunch of other interesting checkins that you’ll notice in the daily build notes related to gaming, but the one I want to highlight is related to business apps or any app that’s dealing with lots of text.

In the next daily build, we are going to be giving more text alignment capabilities. You’ll be able to set left, center, right alignment on multiline text objects, the ones created by ‘display.newText()’. There will be more docs forthcoming on our daily build API docs. I’ll update here when they’re ready.

This week we hung out with Kimberly Voll, Brian Burton, Ed Maurina, Gerald Bailey, Mark Eberhardt, Matthew Chapman, Rob Englebright, Jesse Warden, and Eric Kinkead to discuss Gender Stereotypes in Gaming. Kimberly is organizing a hackathon July 12-14th at the Centre for Digital Media in Vancouver, BC. The goal of the event is to broaden perspectives about the role of females characters in games and to bring awareness to the issue. If you are interested in participating or sponsoring the event, contact Kimberly for details.

Corona Labs T-Shirt Winner

Congratulations to Alex Wagner for winning this week’s Corona Labs’ t-shirt. For your chance to win, follow Corona Geek on Twitter and Facebook, and complete the Corona Geek giveaway form.

Thank you for watching, we’ll see you on next week’s Corona Geek hangout!

Remember To Subscribe

• Download the Corona Geek podcast on iTunes
• Listen to Corona Geek on Stitcher
• Subscribe to Corona Geek on YouTube

Oni is a famished little creature who needs your help to find a tasty meal. The gameplay is simple: your goal is to feed Oni by moving him directly under nuggets of food that drop from the sky. However, there’s a catch. The food Oni ingests has to match the color of the tree that hovers at the top of the screen. Occasionally, you’ll get to chow down on a tasty multi-colored leaf, which gives you extra points in the game and if two matching snacks fall side by side, you can stand in-between them for double points. Be wary of feeding Oni incorrectly colored food, as this will poison him and cost him a heart.

For a charming, casual game check out Hungry Oni for free on iTunes (for iPhone/iPod or iPad) and Google Play.

In July, Corona Labs is sponsoring iamagamer, a jam organized by Kimberly that’s based on creating strong, female lead characters in games. Register for iamagamer and support Kimberly’s mission of challenging the industry’s views on strong, female protagonists.

“You can’t have a female character in games, simple as that.”

While not surprising, Gamasutra’s article on the industry’s reluctance to produce games centred around female characters was shocking in its frankness. Evoking a visceral reaction, the article forces us to stare down a monster: an explicit manifestation of a very ugly side of our world. The risk of looking away? Tacit acceptance.

We might make jokes, or dismiss evidence as exception. We may look around at our peers, thinking, “No, not us, we’re not like that.”

And maybe we’re right.

Yet the industry still believes that we won’t buy their games if they have a female protagonist. And worse still, a small, but venomous side of our community exists, choosing vicious attacks over dialogue for people who might step up to point out unfair trends.

Something is horribly, horribly wrong. And it’s time to change.

So this July, I’m hosting a game jam centred exclusively around strong, female lead characters through a group I’ve started called iamgamer. The idea is simple: games for all, by all.

People keep asking why I’m doing this jam, and while there are a million obvious answers, it seems the real question is why the industry is still this way. How have we not overcome this? Why do I need to do this jam? So I started looking inside and what I discovered surprised and scared me: deeper, personal issues that I have not confessed to anyone (even myself) until just now.

My hope is that sharing them will help inspire you to look deep inside, too.

***

Why do I need to do this jam, you ask?

Because I always picture Sheppard from Mass Effect as male—I chose him because it felt more normal. Because every time I play a game, I choose the male option. That’s why I need to do this jam.

Because I feel the need to justify myself as a “real gamer,” hiding that I also play casual games so I’m not labeled “girlie.” (Because I went back and added the word “also” so it was clear I play “real games” too.) That’s why I need to do this jam.

Because I look at a woman and assume she’s an artist, not a programmer, for no good reason. I assume that’s what people think of me, so I don’t tell people I’m an artist. I say I’m a developer. Both are true, but I’m ashamed to say only one makes me feel worthy. That’s why I need do this jam.

Because I grew up in a world that showed me I was different, and I accepted that. I want a world in which every child sees only possibilities free of the constraints of outdated ideals. A world where we don’t worry what people think if we pick a gender (or no gender at all) in a game. That’s why I need to do this jam.

Because when we fail to set positive examples we create a void—invisible, yet conditioning the next generation to accept a broken and unbalanced reality. Individually, we need to shine a critical light on ourselves and the unspoken messages we are sending. It won’t be comfortable and it may mean we are forced to change something inside, the way we talk and joke, the way we view ourselves and others, the way we make games, and that’s hard. That’s why I need to do this jam.

Because I’m not a game developer. I’ve made lots of games, and helped people with many more, yet I’m too scared to publish. Because if you catch me late at night, after a couple drinks, I’ll tell you that I’m not good enough. And then I might quietly whisper, “…because I’m a girl.” That’s why I need to do this jam.

Because for too long I never thought there was anything wrong at all. That’s why I need to do this jam.

Look inside, find something surprising. That’s how change really happens. When we open our eyes together we can change the world.

Registration: www.iamagamer.ca (with special thanks to Corona Labs for their support).

Inneractive is one of Corona Labs’ first Corona Plugin partners, which are available to all Corona SDK developers. For more information, please see Inneractive’s plugin documentation.

Inneractive has been providing Corona SDK developers with a monetization solution for quite a while now. Corona Labs and Inneractive have been partners for a few years with the common goal of enhancing the development and monetization of mobile developers across the globe. We wanted to say hello and tell you a little about what we have been up to at Inneractive as of late.

Here’s our goal: we want to take the fragmented world of mobile app monetization and unify it under one simple and effective umbrella – a mobile supply side platform (SSP). There’s no longer a need to integrate multiple ad networks and track/analyze the results from each. With one SSP, all the major ad networks are unified under one dashboard. Of course, within your dashboard, you have full transparency to see which demand partner is performing best, and have the option to adjust accordingly.

What that means for mobile developers is that no in-app inventory goes to waste – it’s all populated with both the highest quality and highest paying verticals. With the Inneractive SSP, you set your floor price so you never “sell” for too little, (but make sure not to set it too high!).

The Inneractive Mobile SSP offers developers what’s known as a “daisy chain” in the online advertising world. This means that developers can benefit from the ability to directly sale their inventory both by individual impression or in bulk to the highest bidder using a ‘Real Time Bidding’ mechanism.

In addition to all this, with the Inneractive SSP, if you see traffic coming from a specific location, let’s say China for example, the SSP will automatically find the best network in China to reach that audience. It will take no effort on your part.

Inneractive also offers large developer communities, such as that of Corona Labs’, a branded and standalone private ad exchange.

Lastly, Inneractive offers a truly global and cross-platform solution with many verticals of monetization including display, rich media, hyper local targeting, video campaigns, and more. Gone are the days in which the app is targeted; with Inneractive’s technology, the ad targets the user, which means more relevant ads and ultimately better engagement.

We have a lot of exciting things in the pipeline and are excited to bring them to the fantastic Corona community.

10. Mobile first. Corona was written 100% from the ground-up for mobile. It’s lean and mean — none of that legacy cruft.

9. “OMG!” That’s the sort of reaction we get when we show Corona in action. It’s like trying to imagine life before smartphones. There’s no going back.

8. Daily builds. Waiting for a once a year update is an eternity in the mobile industry.

7. Simplicity, Performance, and Flexibility. Why compromise with one or two when you can pick all 3?

6. 2D Graphics. We’ve cracked the code when it comes to building Photoshop-level graphics on top of OpenGL.

5. Documentation. There’s just a ton of it. Books (in print!), tutorials, and videos too.

4. Cross-platform. And when I say cross-platform, I actually mean cross-platform. You know, from the perspective of an engineer, not some marketing monkey. We strive for 95% whereas everyone else grades on a curve.

3. Elegant API’s. Build your apps 10x faster? Yup, design matters.

2. Community. You’ve touched our lives. Hopefully, we’ve touched yours in kind.

And number one is… [queue the drum roll]

1. Google says so. I’m not kidding! Okay, maybe a little, but guess who happens to be the top hit for cross platform mobile development? Here’s the screenshot (via Chrome’s anonymous incognito mode):

It’s Wednesday and time for another frequently asked questions (FAQs) session. Here are some FAQs about upgrading the Corona SDK Simulator.

1. Do I have to uninstall Corona SDK when upgrading to a new version?

No, you don’t to have uninstall on Mac or Windows.

2. Do I have to deauthorize Corona SDK when upgrading to a new version?

No, you don’t have to deauthorize when installing a newer or older version. The only times you need to deauthorize is if you plan to use Corona SDK on another computer and you already have two computers authorized, if you change the email address associated with your Corona SDK license, or if you plan to reinstall the OS on your computer.

When you upgrade (or downgrade) a version of Corona SDK, the newly installed version uses the account settings already stored on your computer (either in the Windows’ registry or Mac’s plist file).

3. When do I need to contact Corona Labs’ support to deauthorize the machines on my account?

There are very few times when you need to contact Corona Labs to deauthorize the machines on your account. If you forgot to deauthorize your machine, please contact us if you have changed the email address associated with your account or if you have reinstalled the operating system on your computer. Remember: to avoid these issues, don’t forget to deauthorize your computer(s) first.

4. Can I have more than one version of Corona SDK installed?

The answer depends on the platform you’re using.

On Mac, you can have many Corona SDK builds installed at the same time. The trick is to rename the CoronaSDK folder in the Applications folder after installing a new version. On my machine, I append the build number to the end of the folder name to keep them separate. For the last public build #1137, I would rename CoronaSDK to CoronaSDK–1137.

For Windows, you can only have one version of Corona SDK installed at a time. You don’t have to uninstall when installing a newer version, but if you need to install an older build, you have to uninstall first.

5. FAQ Tip of the Week

The last public release (1137) added lots of bug fixes and some much needed features (Build 2013.1137 Release Notes). One of the features you may have missed is the ability to retrieve the app name (using system.getInfo). You may wonder what advantage there is to retrieving the app name. Here’s one example.

When debugging an app on a device, I like to enable the Runtime popup message feature (setting showRuntimeErrors = true). I want the popup for my debug builds but not when I submit it to the App Store. This involves modifying my project files and having to remember to remove the code when I’m ready to release the app.

My solution is to add some code to the config.lua file to control the state of showRuntimeErrors without having to modify my project files.

application =
{
    showRuntimeErrors = ( string.find( system.getInfo( “appName” ), “debug” ) and true ),
    ...
}

The above code sets the showRuntimeErrors key true or nil depending on the app name. If the app name contains “debug” anywhere in the name, showRuntimeErrors is set to true. If the string is not present in the name, it’s set to nil. So if my app is called BubbleJump, the debug code is enabled if I append “-debug” to the end of the app name in the Corona SDK build window. Seeing BubbleJump-debug is also a good reminder that this is not a production-ready app. I chose “-debug”, but you can choose whatever you like.

You can go one step further by adding the following code at the top of the main.lua file.

local debug = ( string.find( system.getInfo( "appName" ), "debug" ) and true )

You can now use the debug variable to enable debug statements in your code. You can even use it to disable the print statement when debug is false/nil. This allows you to control the debug flag at build time instead of having to modify your project files and run the risk of releasing a version of your app with debug code enabled.

One note of caution about using debug for a variable name. If you do use debug, make sure it’s a local variable and not a global one. Lua does have an internal debug library that you will override if you define debug as a global variable. Doing so will suppress any runtime error output and print output that your code may generate. It may be better to use dbg or _debug instead.

One final note: I mention public release #1137 in this blog post. This release replaces build #1135 and fixes a potential issue with plugins.

That’s it for today’s questions. I hope you enjoyed them and even learned a few things.

When Corona Labs introduced Corona Plugins, I was excited to learn that OpenSSL was one of the first in the initial batch. Using this, my apps can be further enhanced to protect my customers’ privacy. Most of this I learned from George Zhao’s documentation and files on his GitHub page. Now, in this tutorial, I’ll show you how to initialize the appropriate plugin module, then to do some basic encryption and decryption.

Additions to “build.settings”

The first step is to add a couple of lines to the build.settings file to support the OpenSSL plugin:

settings =
{
   plugins =
   {
      ["plugin.openssl"] = { publisherId = "com.coronalabs", },
   },
}

Setting Up

Next, you need to require the plugin in the main project file:

local openssl = require "plugin.openssl"

Next, we’ll create a cipher object. The method can be a variety of encryption methods. For the sake of this tutorial, we’ll use “aes-256-cbc”.

local cipher = openssl.get_cipher ( "aes-256-cbc" )

Encryption

To encrypt a string of text, we’ll use the following line of code:

local encryptedData = cipher:encrypt ( "text", "key" )

The text is a string that you want encrypted, and key is a string containing a passphrase, which can be anything.

If you want the user to be able to select their own passphrase, a simple native text field could be used to get their input. Additionally, you could have that input hashed using the crypto functions.

local crypto = require "crypto"
local key = crypto.digest( crypto.sha256, "plainTextPassPhrase" )

Encoding the Text for Transport

I also like to apply a base64 encode on the encrypted text. This allows for easier storage or data sharing. To encode the text as base64 is really simple. We enable the mime functions then call b64 to encode the text.

local mime = require ( "mime" )
local encryptedData = mime.b64 ( cipher:encrypt ( "text", "key" ) )

Now the encrypted data is stored as a base64 string.

Decryption

If we want to decrypt something, it’s just as easy!

local decryptedData = cipher:decrypt ( "text", "key" )

Just replace text with the encrypted text, and key with the the string that was used to encrypt the text with. If the encrypted text is base64 encoded, it’s easy to undo the encoding — just use mime.unb64.

local mime = require ( "mime" )
local decryptedData = cipher:decrypt ( mime.unb64 ( "text" ), "key" )

Overall Code

Here’s the overall code up to this point:

local openssl = require "plugin.openssl"

local cipher = openssl.get_cipher ( "aes-256-cbc" )
local mime = require ( "mime" )

local encryptedData = mime.b64 ( cipher:encrypt ( "Your Text Here", "Your Key Here" ) )
local decryptedData = cipher:decrypt ( mime.unb64 ( encryptedData ), "Your Key Here" )

print ( "Encrypted Text: " .. encryptedData )
print ( "Decrypted Text: " .. decryptedData )

PHP

If you want to take things further and if your web host has the OpenSSL module installed, you can create a PHP script that can encode/decode text sent to/from your app:

<?php

$source = 'Your Encrypted Text Here';
$pass = 'Your Key here';
$method = 'aes-256-cbc';

$encrypted = base64_encode ( openssl_encrypt ( $source, $method, $pass ) );

?>

This will return a base64-encoded string that can be decoded with OpenSSL — and decryption is just as simple:

$decrypted = openssl_decrypt ( base64_decode ( $encrypted ), $method, $pass );

So the full scope of the php script would be:

<?php

$source = 'Your Encrypted Text Here';
$pass = 'Your Key here';
$method = 'aes-256-cbc';

$encrypted = base64_encode ( openssl_encrypt ( $source, $method, $pass ) );

$decrypted = openssl_decrypt ( base64_decode ( $encrypted ), $method, $pass );

?>

In practical use, if you’re sending encrypted data to the script, you could replace the $source variable with:

$source = $_POST["yourPostVariable"]

Export Compliance

To be perfectly clear, I am not a lawyer. Most likely, you will need to fill out some forms to receive the proper paperwork when submitting apps to the Android stores or submitting to Apple for export compliance review.

More information on this subject can be found in the World Wide Trade Compliance section of iTunes Connect, under Policy and Best Practices in the Google Play Developer Console, or at the Bureau of Industry and Security.

In the meantime, these links may help narrow down your particular situation:

U.S. Export Compliance:

• Android Support
• Bureau of Industry and Security -> Main Page
• Bureau of Industry and Security -> Policies and Regulations -> Encryption
• A blog post from The Lane Files about obtaining an E.R.N.

French Export Compliance:

• http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=LEGITEXT000005789847&dateTexte=#LEGIARTI000006421577
• http://www.ssi.gouv.fr/site_article195.html
• http://www.ssi.gouv.fr/site_article197.html

In Summary…

As you can see, setting up Corona’s OpenSSL plugin is fast and easy. In just a few lines of code, you can be encrypting and decrypting data! For further reference, please review the documentation, and please post your questions and feedback below.

Today, we had some very special guests visit the Corona office: game legends John Romero and Brenda Romero.

It was really inspiring to meet them. Together, they’ve had a profound influence on the industry that still reverberates today.

John designed such seminal games as Wolfenstein 3D, Doom, and Quake. He co-founded id Software which holds a near mythical place in the pantheon of game development, and there helped ignite the whole first-person shooter genre. Brenda is most well-known for her work on the Wizardry series from the 1980s that served as a template for role-playing games that followed.

Here’s the awesome thing: they’re fans of Corona SDK!

It was surreal to hear John talk about the first time he discovered the auto-refresh feature of the Corona Simulator at 3 a.m., or what a “no-brainer” it is to use Corona instead of coding in Objective-C or even in Unity.

Of course, everyone has their wish list.

When he mentioned how Corona’s accessibility and immediacy brought him back to his early days of programming, I couldn’t help reminisce about my own experiences with turtle graphics on the Apple ][.

John and Brenda shared many gems about the current industry. One that stood out for me was how today’s students no longer want to work at large studios; they want to create their own games. More and more, there seems to be a decreasing desire to build 3D games. It just takes too long, and so much of what makes a game successful depends on the design and mechanics itself, not eye candy. So as an indie, you really do benefit from building ten games quickly instead of spending months (or years) on a single game.

Well, that explains why they like Corona so much!