Kongregate Developers

Unity, HTML5, CORS, and You

Due to the fact that Unity is removing support for the Web Player in their 5.4 release, many developers are ramping up on publishing their content using the HTML5 target to ensure forward compatibility. If you do not have any experience with creating Unity HTML5 content, you can view our blog post about the subject to get a brief overview and some tips on uploading your game to Kongregate.

One common issue that tends to trip developers up is the fact that HTTP requests (using the Unity WWW class, for example) may suddenly stop working once they are executed inside the browser context. This can be incredibly frustrating, as there may not be any indication of what is going wrong unless you are closely watching the JavaScript console or network activity tab.

What is CORS, and why should I care?

CORS stands for “Cross-Origin Resource Sharing,” and you can read details about it here. Basically, when configured properly, CORS allows you to securely access resources (such as fonts and API endpoints) across domains using AJAX or other methods.

The reason this is important for your game is that Unity implements the WWW class using run-of-the-mill AJAX HTTP requests behind the scenes for HTML5 content. This means that if your game needs to access resources on a domain other than the one it is hosted on, the browser will refuse to process the request unless CORS is configured properly. This is a common problem, as game files are generally served from a CDN, while API requests are handled by an application server.

You can generally tell if you are encountering a CORS-related issue by watching the JavaScript error console in your browser and looking for messages such as No 'Access-Control-Allow-Origin' header is present on the requested resource or Cross-Origin Request Blocked.

Well, this sucks. I just want my game to work

Luckily, for the vast majority of cases CORS is quite easy to set up. It generally just requires a few small tweaks to your server code or framework. To determine how to set up CORS for your back-end, you can visit an absolutely fantastic website called enable-cors that has detailed instructions for almost every conceivable configuration.

For most cases, just following the basic instructions on enable-cors.org will be enough to get you up and running. This generally involves setting up an Access-Control-Allow-Origin header to allow your game to access the proper endpoints. However, if you have a more complicated client/server setup, there are some potentially tricky issues that we’d like to cover in more detail.

Losing your head(ers)

We recently helped a game developer diagnose a problem with the HTML5 version of their game where at first glance CORS appeared to be configured properly. Watching the network tab in the browser, we could see the Access-Control-Allow-Origin: * header coming through, and the request appeared to complete successfully. However, the game was not properly processing the request, and there were no errors in the browser console.

In order to diagnose the problem, we first wanted to verify our hunch that this was a CORS-related issue. The Web Player version of the game worked fine, and starting Chrome with the --disable-web-security flag (which disables CORS checks) made the issue with the HTML5 version go away, so it seemed we had found our smoking gun. The problem was, the browser appeared to be happily accepting and processing the request, so what could be wrong?

Looking more closely at the Network tab in the Chrome console, we noticed that the responses from the server contained a custom header, similar to the following:

Access-Control-Allow-Origin: game12345.konggames.com
Content-Length: 2168
Content-Type: application/json
X-App-Signature: 0a2fff3c557e7560647ee43a61511d3eb73e23806c6a8fc3951189e82fe86e64

In their C# code, they were checking the validity of the request using the signature using the responseHeaders attribute on the WWW object, for example:

var signature = www.responseHeaders["X-App-Signature"]
if(SomeCustomValidator(www.text, signature)) {
    // Process response
}

After some additional debugging, we noticed that the custom header was missing from the response! This is where the fine-grained access controls that CORS provides can bite you. By default, CORS does not allow all headers to be passed along to the client. In fact, the only headers exposed by default are:

  • Cache-Control
  • Content-Language
  • Content-Type
  • Expires
  • Last-Modified
  • Pragma

Looking at the documentation, we saw that CORS provides an Access-Control-Expose-Headers directive that allows exactly what the developer was trying to accomplish. The issue was easily resolved by configuring their server to add the following CORS header to responses:

Access-Control-Expose-Headers: X-App-Signature

You can see how this might affect you even if you’re not using custom headers. You may be looking for Content-Length, Status, or some other basic header that you expect to be present, and end up pulling your hair out trying to figure out why you can’t access it.

TL;DR

CORS is a very powerful tool that is trivial to enable for most applications. However, if your game has requirements beyond the most basic configuration (such as using custom headers), you may need to spend some time reading the spec and looking over options to determine why your data is not showing up as expected. Also, Chrome’s --disable-web-security flag can be a helpful tool for verifying that an issue is related to CORS, so don’t be afraid to use it if you suspect something funny is going on.

Good luck, and keep up the great work creating those plugin-free HTML5 games!

Author

Ben Vinson

While studying for his B.S. in Computer Science from the University of Colorado, Ben was a major contributor to the book Software Engineering for Game Developers.

After graduating, Ben started work as a game developer at Electronic Arts. He was also the creator of the Leeroy Jenkins video, which is probably his greatest achievement to date.

Design Tips for In-Game Character Proportions

Are you building a next hit and need some help getting your characters feeling right? Many developers often run into the issue of figuring out the proportions of the individual characters they create, and the relationship between the characters and the surrounding environment elements. Below is an approach you can take.

Obviously, if your game doesn't have characters, this post may not be for you (but hey, feel free so stick around, since this may help your next project). The same method can be applied to anthropomorphic and inanimate objects.

Step One: Let's find your tile size

Finding the tile size is often a separate task done early in game development. It can be measured in the world units (inches, meters, etc.) or in pixels.

If your game currently does not have a tiled grid, you can still create a quick greybox mock and use a tile size relationship for initial object alignment. In my examples I will be using an isometric grid, but the projection type doesn’t matter here.

Questions to ask:

  1. What is the smallest object a player will interact with? Is it a small chest on the ground, a building, or a planet?
  2. What is the screen size, ratio and resolution?
  3. What is the scale of the game (theme and mechanic)? Are characters key to your game? Is the game about bugs or are you managing a city? How many objects does a player need to observe/interact with while playing the game?

“A” will work better for a claustrophobic horror game (you can try to be even closer), “B” would be better for an RPG or RTS, “C” is asking you to be a military commander or a mayor, and “D” is too small for any interaction; at this tile size selecting an individual tile is impossible (unless your audience is aliens with tiny fingers). There is an infinite number of scale steps between “A” and “D” and beyond. What would work for you depends on the type of game you want to make.

Now that you found a tile size you think works best, let’s move on to characters.

Step Two: Let’s count heads

How many heads fit in your character?

(Image by: Andrew Loomis)

Just a bit of a reference here: realistic and adult humans range from 7 to 8 head to body height. If your characters get into 8 heads and above, you are going into Greek God/Superhero territory.

But this isn't a discussion about style or height. Supertall characters can still be 3 heads tall and any style can be adopted to various head-to-body proportions.

(Image by: Garon Rossignol)

The main point to take away here is the size relationship between the character's head and the rest of the body. For example, if you design a character that is 8 heads tall, what you are saying is that the body is 7 times more prominent than the head. Most of the communication and detail will happen in the body and the head/face will play a somewhat secondary role. This is not to say that the head will not be important; as humans, we are primarily drawn to faces and hands (and a few other protruding body parts). But the 8-head-tall silhouette puts facial detail and expressions at a disadvantage.

“A” - Face and body are clearly visible.
“B1” - Body occupies more canvas when your characters are 8 heads tall. Facial detail is hard to read.
“B2” - If your game requires emotions from characters with realistic proportions, you will need to use close-ups.


Most animated cartoons are in the 2-6 heads category. Although 8-head-tall characters can be playful and exaggerated, most of the time they would fall under a serious and realistic category. Anywhere above 8 heads tall can also be playful, but again the body will take a lot of attention from the head/face.

Questions to ask:

  1. How important are facial expressions to your game?
  2. How important is the realistic movement?
  3. How silly/serious is your game? Realistic proportions suggest serious/realistic gameplay.
  4. What is the camera angle and does it change during the game?

  5. If your game has a top-down view, the head will overlap significant parts of the body. For a 2-head-tall character you may need to reconsider and add more body.
  6. What is the average head and body width?
  7. Wider heads have a bigger surface area and will attract more attention and overlap more body parts if the camera is facing down. If your art style demands wider heads, go 1-2 heads up and add more body.

    The reverse is also true about the body width.

    Do you have a wide character that needs to show more emotions and appear cuter? Increase the head size.

Important rule to remember: Small-bodied characters allow themselves to be significantly bigger on the screen, communicate more emotions and allow more artistic freedom and distortion. This allows more objects and information of various scale to fit in the same screen space.

(Copyright: Microsoft)

Facial expressions are not important in Age of Empires. Individual units make little difference.

(Copyright: Beeline Interactive)

Facial expressions and characters have more importance in Smurfs’ Village and even more in Minions Paradise. The characters (and their heads) are bigger on the screen.

(Copyright: EA)

Step 3: Relative scale and the Golden Ratio

So you got your characters and tile size. How big should you make other objects and buildings relative to characters? This is a great time to test if the selected art style and proportions fit the requirements of the game.

In general, if you picked realistic proportions for characters you should stick to realistic building and object sizes.

(Copyright: Firaxis Games)

(Copyright: Firaxis Games)
You can allow more distortions if you are aiming for a more mature audience and iconographic (table top) game like Civilization.

Let's run through a common scenario:

  • Player can interact with buildings.
  • Player can interact with characters.
  • Characters are 3 heads tall.

There is no rule here, but instead of picking numbers out of our hat we can have a really intriguing starting point -- the Golden Ratio, or 1 to 1.618. First recorded by Euclid, it is often found in the most pleasing proportions. You can find the Golden Ratio is ancient architecture, famous paintings, plants, faces and body parts.

A few examples of the Golden Ratio in nature.

1 to 1.618 make great upper and lower heights as starting points for your characters and buildings.

Obviously, if your characters are smaller than your buildings they can enter them. You can use the Golden Ratio to design your buildings and architectural elements.

Should your game require tall buildings, you may want to consider using the Golden Ratio for additional floors.

Use “A” if your character needs to move between floors. Use “B” and “C” when no movement is required.

Don't forget about the doorways.
Make sure doorways are big enough to fit your characters.

This is only one way of tackling the issue of scale, but I hope you found it helpful.

Happy game-making!

Author

Yuriy Sivers

Yuriy is a Senior Artist at Kongregate. His background includes game design, concept art, illustration and animation.

7 Tips to 7-Day Game Jams

Making games in a week isn’t easy. As someone who has built around 30 different games in less than a week, I've encountered a lot of counter-intuitive hurdles to working in this timebox.

The good news is that a week is perhaps the best amount of time to gauge a design. It offers enough time to execute the primary details of the game, while giving some space to pivot and polish as necessary. While every team is different (or solo developer for that matter), a couple of days just isn’t enough at times to really execute a design, and often a month leads to over-polish or over-design. A week keeps everything in check. And a weeklong jam will teach you a lot about your own game development; game jams really accentuate your abilities as a developer in interesting ways.

All said and done, here are seven tips for building a game in seven days:

1. Count your hours. Bank 20% for safe-keeping.

Executing in a timebox is tough. Being cognizant of time is critical to the success of your jam, and you should plan accordingly.

A weeklong game jam totals 168 hours from start to finish, but you’ll be using a subset of that. With a normal amount of sleep that’s maybe a 110 hours max. Reasonably, it's even less time than that if you count all the important human things you do daily. You’re going to eat, right? You have kids? School? You have loved ones that care about you? Don’t neglect those things (see Tip #6).

Once you figure out how much time you have, allocate the first 80% to actual development time, and leave the last 20% empty. While this seems like a lot of time, it’ll become really important for several reasons:

  1. You will slip. Game development is hellbent on slippage, and even the most disciplined teams will find ways to fall behind.
  2. You will change your design. You’re doing this to experiment with design, and with that you’ll change what you started, and that takes time. For every X and Y we’ll have a Z as well.
  3. Things will go bad. It's rare anything in game development isn’t turbulent. Development is a parade of problems to fix, not smooth sailing.
  4. You’re a human being with competing priorities. There’s always a dog to feed or a library book to return. While you can prepare for some of these things, often the unexpected will happen.
  5. Unaccounted time is in every schedule. You’ll always forget to budget time for a main menu or a mute toggle. By buffering development you’re giving yourself runway to be successful.

Be honest with yourself and how much time you have to dedicate:

2. Prepare as much as you can before the jam even begins.

There’s quite a lot you can do before the jam begins. Here are the biggest ones:

  1. Get your team together. While it can be fun to slap together a team after the jam starts, it’s better to get a good grasp of your team and what each member will be doing, and the time they can commit. If you’re going solo, make sure you’re committed to your jam.
  2. Get your code base and tools together. It's a lot easier if you’re familiar with the tools and frameworks (especially if you’ve built them). Make sure you stick to the rules of the jam or sprint to ensure you’re not bringing anything into play that might be considered foul play.
  3. Read the rules. Then read them again. Jams and sprints often have a bunch of small rules that can be overlooked. It's important you know all of them so all your hard work isn’t inadvertently disqualified. You should know the due dates and process for everything related to the jam. Don’t break the rules!
  4. Clear the calendar. It's incredibly easy to schedule new events over your jam time. If you need the maximum time, let others know you’ll be busy.
  5. Human basics. Ensure you've got all the basics down. Food, water, medication, electricity, internet, and a working computer are all great. Any time you can prevent going to the grocery store during the jam is a huge plus.
  6. Computer basics. Don’t do any crazy software or OS upgrades before the sprint; nothing is worse than starting your jam debugging your machine.
  7. Communication and sharing strategy. Get your communication and file-delivery perfect before the jam starts (see Tip #6).

3. Theme announcement, distillation, scheduling.

The theme announcement can be incredibly stressful, exhilarating, confusing, and exciting. A theme sets the entire tone and design for your game, so it rightfully earns the reaction you give it. Your ability to execute on theme is really important!

After you calm down a bit, begin to think about game ideas that immediately come to mind from the theme. Write them all down, and if any are too long, attempt to break them down even further.

The theme is “stop.” What do you immediately think of?

“Time.” “Cars in an intersection.” “The end.” “A button on a VCR.” “A red hexagon-shaped sign.” “Red light.” “Blocking.” “Not moving.”

By dragging out all the verbs, nouns, and feelings that you derive from the theme, you get a palette of direction to go from. Think about what these words and phrases mean to you. Think about mechanics that tie into these words.

Now it's time to design. Usually by this time some ideas start to flow, so get that brainstorm going with your team on how the game works. Think about art styles that match the mechanics and theme. Think about music and sound and how they complement that art and mechanic. For each element of design, think about how difficult it would be to execute. Some art and music styles are incredibly difficult to execute in sprints, so think about your strengths and weaknesses as you plan. Make good risk in design, don’t box yourself into the impossible.

Got the game? Time to schedule.

Within the first few hours you should know the general direction of the game and how your time is allocated between you and possible team members.

By making a plan, everyone knows when things are due, and it minimizes the chances of blockers or bad overlaps in work. Efficiency is crucial in limited-time events. Your ability to plan well will give you a much higher chance of reaching success.

Example schedule

While this schedule doesn’t work for everyone, this is basically how I would execute on-time for several of my projects.

4. Don’t be afraid to take risk. Learn to embrace failure and pivot.

Things don’t always feel right in game development, especially when you’re working on new concepts. If you have time to pivot and have purpose to pivoting, do it. We often think something is more fun or interesting than it actually is when we plan, and not being dead-set on the outcome is important. But, you should do a few things before doing a hard pivot:

  1. Get buy-in from your team. Obviously communication is really important.
  2. Get buy-in from others. Sometimes execution is just slightly off, or not even at all (you’re always your own biggest critic). Talk to others if something doesn’t feel right. An outsider's perspective is incredibly valuable.
  3. Fork, don’t replace. Try to make a step toward your new direction, but save a backup in case you need to go back.

Even if everything is going perfect, massaging mechanics is some of the most interesting work you’ll do in a game jam. Make sure you aren’t forgetting to tweak and modify your original design. Continue to think about how you could improve your game as it comes to fruition.

5. Facilitate good communication.

Good communication is not just about your internal team, but also the greater jam. Your jam team should know how they’re going to communicate and share content ahead of time. Teams shouldn’t be relying on finding a Dropbox, common email, or GitHub repo while the jam is already in action. Think about where you’re facilitating the bulk of your communication. Slack? Skype? Google Hangout? Ensure everyone has buy-in and is good with the medium of choice.

Sharing your jam in-progress is a great way to give developers and players insight into your design and development progress. Try sharing screenshots, quick builds, and pics of your team hard at work. Even if you don’t see the immediate value of it, other devs thrive in knowing that they’re in the company of a hard week’s work, and so will you. Likewise, you’re building traction with players and getting them excited and supportive.

6. Be a human being. Keep morale positive.

The pressures of completing a 7-day sprint are really high. In nearly every situation it doesn’t make sense to skip sleep for three days or forego eating to get a few extra hours of programming. Beyond being grumpy and terrible to work with, your work will be compromised dramatically. Your priorities should be aligned with your own needs, first and foremost, then to the jam. Plan effectively. A week is a good amount of time to execute.

Jams are supposed to be fun and engaging. While often jams are a competition, by no means should competition get in the way of you being nice or helping another team. Game jams live and thrive on developer comradery. Both inter- and intra-team drama can be frustrating. The unexpected always rears its head during short development sprints. The best mindset is to keep calm and adjust appropriately. Ultimately positive attitude, patience, friendliness, helpfulness, and teamwork will get everyone to the finish line in good spirits.

7. Learn from what was accomplished. Apply to the future.

While jams are a great way to see if mechanics work, the larger takeaway might not even be a finished game. Game jams are a great time to learn about yourself, others, and what you can accomplish in a short period of time. You might have accidentally stumbled upon a mechanic that you’ll use in the next great game, or you might have met a new artist or programmer that perfectly jives with your style. Often we learn what we’re really good or bad at in a pinch (for me I’m terrible at building levels quickly, but I’m really fast at comping and programming UI). Sometimes we make human mistakes, like forgetting to delegate who was supposed to order pizza, or running out of coffee and having to send someone out to the coffee shop. As you do more jams, you get better, and as you begin new games you’ll already be ahead of where you were just a week ago.

Document and write your outcomes. Share them with the jammers, and bring your experience to others just getting started. It helps you digest your game jam experience and helps others process theirs.

Author

John Cooney

John is the director of Launchpad, Kongregate's incubator for emergent game design. He has developed and published over 100+ games, culminating in plays in the hundreds of millions.

Prior to Kongregate, John was the Head of Game Development at Armor Games.

Ads Count, So Count Your Ads

Ads in mobile games are more popular than ever. Ads can come in the form of interstitial banners, non-rewarded video, rewarded video, offerwalls, and other native forms. Some games, often casual, can be solely supported by ad revenue. Even for games with options for in-app purchases (IAP), Kongregate typically finds that in-game ads can account for 10-50% of all revenue.

This “ad”ded revenue is nice but often lives independently of IAP revenue, typically in the dashboard of various ad networks or your mediation solution. Developers should be looking at both the revenue generated from ads and IAPs in order to determine ARPU, as we do at Kongregate. If you are running paid marketing campaigns for your game, this is essential to acquiring as many new users as possible.

Most ad networks will rank your offers against other advertisers' offers based on the CPM cost of your ads (the cost per 1,000 impressions). Even if you are bidding on a cost-per-install (CPI) basis, ad networks will always optimize your campaigns based on the CPMs you generate for them.

Demand for ad inventory outstrips supply. Acquisition marketers constantly compete for ad impressions against other games and big brand advertisers. Some of these advertisers are willing to pay premium CPMs and, because supply is limited, they are “winning” the bulk of the ad auctions. This has created an ecosystem where ad display is not linear based on CPM and is actually a power curve in which a few winners take the bulk of all impressions.

Below is an example of how we at Kongregate find impressions get distributed based on the CPM your ads generate for networks (example based on United States traffic):

The minimum viable CPM in a premium country like the United States is ~$10.00; anything lower and you will likely get minimal impressions and traffic. The higher the CPM you generate, the more impressions and traffic you will ultimately receive. If you are not counting ad revenue in those bids, you are not being as competitive as possible.

In this example for 1,000 users the average revenue per user (ARPU) increases 25% just by including ad revenue in the calculation:

As you can see from the power curve chart above, the difference in impressions (and likely users) between a $10 CPI bid vs $12.50 could net a 100% increase in impressions and traffic. There is always a tipping point where your traffic will increase exponentially relative to the increase in your bid.

The easy way to count your ad revenue is to create an association of ad revenue per user: a "revenue per impression" number. Sounds nice, right? Unfortunately, it’s not that easy. Network ad servers are changing bids based on game, geo, CPI bid, click-through rates, conversion rates, and CPM across hundreds, if not thousands, of bidders vying for impressions in real time. Due to these complexities, few networks are able to create a true "revenue per impression" figure. Until this happens, you will have to do some estimation to create a directionally accurate ARPU to maximize your bids.

First, create a system to count your in-game ad impressions on a per-user basis (as we do for all Kongregate games). This system should track every ad type individually, as the revenue per ad type can vary significantly.

Next, download your ad revenue data and calculate your average revenue per impression. It is typically best to do this both by individual ad type and geo, as the value for each can vary dramatically. Below is an example:

Finally, roll up your ad revenue into your IAP revenue to create a true ARPU. Best to do this on as granular a level as possible, such as by geo and network:

In the example above you can see how the inclusion of ad revenue dramatically changes the value of each marketing source. You can now raise bids where it makes sense to maximize traffic and lower bids that are not profitable.

It is important to keep in mind that bids alone do not dictate traffic volume for paid marketing. Your CPM is also determined by the click-through rates of your ads and the conversion rates of your app store page. I will save that for a later post.

Kongregate believes in-game ads are a way to drive a substantial amount of incremental revenue. Kongregate makes it a best practice to track all ad types and model out ad revenue by source in order to run the most effective marketing acquisition programs possible.

Ads count, so always count your ads.

Author

Jeff Gurian

Jeff does all things Marketing at Kongregate, including User Acquisition, Promotions/Sweepstakes, PR, Email Programs, and Mobile Ad Monetization.

When not at Kongregate, he spends most of his time chasing his kid around. He's really into watching most major sports, and he referees basketball in SF -- mostly middle school, high school, and adult rec leagues.

Kongregate Game Jam!

We’re super excited to announce our first game jam! The game jam will take place from May 27th to June 3rd, giving you a solid week to get your jam finished and uploaded to Kongregate.com! We’ll be announcing the theme and special modifiers at the start of the jam. You can find more information about the game jam on the Kongregate forums.

If you can’t make this game jam, no worries! Kongregate has a group running Game in Ten Days (GiTD), who are always welcoming to new participants. Check out all their jams here and keep an eye out for the next jam through the development forums.

April 28th, 2016 12:13 1 Comments