The Long Ago Kongregate has been around for a relatively long time. We were around when Flash was cool, and also when it became uncool. We were also around when SSL was considered an optional luxury that added significant overhead and latency to network requests. Thus, we built our site with the assumption that HTTP was a fine protocol to use most everywhere, and SSL should just be used "as needed" -- for authentication, purchasing, and other sensitive data. That assumption held up for over a decade, but in recent years there has been a large movement toward using SSL everywhere, with search engines and browser vendors alike starting to punish sites for serving up un-encrypted content. Visiting Kongregate using HTTP on modern browsers was starting to become a scary and confusing experience for our players, so we decided it was time to bite the bullet and switch to using HTTPS wherever possible. The Basic Challenge Converting to SSL can be a daunting task for even simple sites without much user-generated content. Here is a short list of

Let me tell you a tale about an initiative to reduce Flash dependencies on what used to be a "Flash gaming" site. This is the story about a large-scale project with the best possible outcome being that users don't notice any changes, and the worst possible outcome of everything breaking horribly. This, my friends, is the story of Kongregate's Death to Flashy initiative. In the Beginning When we first started building Kongregate, we didn't have to worry much about whether or not users had Flash installed. It was very much ubiquitous, and since you couldn't play most of the games on the site without it we could build features based on the assumption that Flash was available. We built our chat client in Flash, we created APIs for both ActionScript 2 and 3, games implemented them, and all was good. For a very long time, the vast majority of the games on Kongregate were made with Flash, even most of our externally hosted "iframe" games. Some of these external games eventually needed a way to interact

Many Unity developers have taken the plunge and started exporting WebGL versions of their games. Unfortunately, many of them also run into issues that can lead to performance degradation and instability. This is a particularly tricky problem on older machines that have less resources available. This article will outline several techniques for resolving some common WebGL performance issues we’ve seen with games published on Kongregate, and hopefully get you off to a good start when it comes to delivering a great plugin-free experience with your WebGL game. Measure Twice, Optimize Once One of the most common mistakes developers make when trying to optimize content is making assumptions about what is taking up lots of time or space. With Unity and WebGL this happens often when deciding how much heap space to allocate for the WebGL application in the player settings. Without doing research on the subject, it can be easy to assume that increasing the memory available to the application will lead to better performance. In reality you generally want to allocate the smallest amount of memory possible, which

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

The quick and painful death of the Unity Web Player has left many browser game developers scrambling to update and publish their content using Unity’s new HTML5 WebGL target. Now that Unity 5.3 is quite stable, we are recommending developers publish both Web Player and WebGL builds when hosting their games on Kongregate. Even though Unity 5.4 will remove support for the Web Player, it currently gives users the best possible experience in older browsers. This blog post will provide some best practices and tips on how to avoid common pitfalls when publishing your Unity game to Kongregate. Preparation The following steps will help you prepare your project for WebGL deployment on Kongregate: We highly recommend upgrading to the latest version of Unity (at least 5.3) Read the official Unity WebGL documentation Read the WebGL Networking section of the Unity documentation Ensure your game properly functions as a Web Player build (test in FireFox/Safari) The main takeaway from the documentation is that some of the things that "just work" in your Web Player