Jump to content
Entries in this blog
Leadwerks 3.1 is nearly ready for release! In Leadwerks 3.0, we focused on making a solid cross-platform art pipeline and editor. In 3.1 we're adding graphics that go above and beyond the capabilities of Leadwerks 2.
New Features in 3.1
OpenGL 4.0 deferred renderer with up to 32x hardware MSAA.
Geometry and tessellation shaders.
Support for the Linux operating system, for both the engine AND editor.
Leadwerks 3.1 is now available for pre-ordering in the Leadwerks store. Existing 3.0 customers can pre-order the upgrade to 3.1 for $99. New customers can pre-order Leadwerks 3.1 for $199. Order before January 6 and get the Indie Edition on Steam for free.
The upgrade to an OpenGL 4 deferred renderer is a big step. To make the process smoother and put Leadwerks in your hands sooner, we're rolling Leadwerks 3.1 out in stages.
"Leadwerks: Indie Edition" will be launched on Steam January 6th. This will be on Windows only, with support for Lua scripting. The following groups will receive a free Steam key to add this product to their Steam account:
Leadwerks 3.0 customers who pre-order the upgrade to version 3.1.
New customers who pre-order Leadwerks 3.1.
All Kickstarter backers who backed Leadwerks for Linux for $49 or more. (Even if you don't run Windows, hold onto this as the Linux version on Steam will have special features.)
Leadwerks 3.1 for Linux and Windows will be released together next, with the exact release date to be determined. Leadwerks 3.1 for Mac will follow this, with mobile add-ons for iOS and Android coming last. (There is no purchase necessary to upgrade the mobile add-ons from Leadwerks 3.0 to Leadwerks 3.1.)
Leadwerks 3.1 beta testers will receive the 3.1 upgrade for free.
Leadwerks 3.0 customers who backed the Leadwerks for Linux Kickstarter project for $99 or more will receive the 3.1 upgrade for free.
Leadwerks 3.1 is a very strong product, with great graphics and a fantastic art pipeline. I'd like to thank all the users, both old and new, who offered their input on product design and the direction of the company. I can't wait to see what the community does with Leadwerks 3.1.
The Leadwerks 2 terrain system was expansive and very fast, which allowed rendering of huge landscapes. However, it had some limitations. Texture splatting was done in real-time in the pixel shader. Because of the limitations of hardware texture units, only four texture units per terrain were supported. This limited the ability of the artist to make terrains with a lot of variation. The landscapes were beautiful, but somewhat monotonous.
With the Leadwerks 3 terrain system, I wanted to retain the advantages of terrain in Leadwerks 2, but overcome some of the limitations. There were three different approaches we could use to increase the number of terrain textures.
Increase the number of textures used in the shader.
Allow up to four textures per terrain chunk. These would be determined either programmatically based on which texture layers were in use on that section, or defined by the artist.
Implement a virtual texture system like id Software used in the game "Rage".
Since Leadwerks 3 runs on mobile devices as well as PC and Mac, we couldn't use any more texture units than we had before, so the first option was out. The second option is how Crysis handles terrain layers. If you start painting layers in the Crysis editor, you will see when "old" layers disappear as you paint new ones on. This struck me as a bad approach because it would either involve the engine "guessing" which layers should have priority, or involve a tedious process of user-defined layers for each terrain chunk.
A virtual texturing approach seemed liked the ideal choice. Basically, this would render near sections of the terrain at a high resolution, and far sections of the terrain at low resolutions, with a shader that chose between them. If done correctly, the result should be the same as using one impossibly huge texture (like 1,048,576 x 1,048,576 pixels) at a much lower memory cost. However, there were some serious challenges to be overcome, so much so that I added a disclaimer in our Kickstarter campaign basically saying "this might not work"..
Previous Work id Software pioneered this technique with the game Rage (a previous implementation was in Quake Wars). However, id's "megatexture" technique had some serious downsides. First, the data size requirements of storing completely unique textures for the entire world were prohibitive. "Rage" takes about 20 gigs of hard drive space, with terrains much smaller than the size I wanted to be able to use. The second problem with id's approach is that both games using this technique have some pretty blurry textures in the foreground, although the unique texturing looks beautiful from a distance.
I decided to overcome the data size problem by dynamically generating the megatexture data, rather than storing in on the hard drive. This involves a pre-rendering step where layers are rendered to the terrain virtual textures, and then the virtual textures are applied to the terrain. Since id's art pipeline was basically just conventional texture splatting combined with "stamps" (decals), I didn't see any reason to permanently store that data. I did not have a simple solution to the blurry texture problem, so I just went ahead and started implementing my idea, with the understanding that the texture resolution issue could kill it.
I had two prior examples to work from. One was a blog from a developer at Frictional Games (Amnesia: The Dark Descent and Penumbra). The other was a presentation describing the technique's use in the game Halo Wars. In both of these games, a fixed camera distance could be relied on, which made the job of adjusting texture resolution much easier. Leadwerks, on the other hand, is a general-purpose game engine for making any kind of game. Would it be possible to write an implementation that would provide acceptable texture resolution for everything from flight sims to first-person shooters? I had no idea if it would work, but I went forward anyway.
Implementation Because both Frictional Games and id had split the terrain into "cells" and used a texture for each section, I tried that approach first. Our terrain already gets split up and rendered in identical chunks, but I needed smaller pieces for the near sections. I adjusted the algorithm to render the nearest chunks in smaller pieces. I then allocated a 2048x2048 texture for each inner section, and used a 1024x1024 texture for each outer section:
The memory requirements of this approach can be calculated as follows:
1024 * 1024 * 4 * 12 = 50331648 bytes
2048 * 2048 * 4 * 8 = 134217728
Total = 184549376 bytes = 176 megabytes
176 megs is a lot of texture data. In addition, the texture resolution wasn't even that good at near distances. You can see my attempt with this approach in the image below. The red area is beyond the virtual texture range, and only uses a single low-res baked texture. The draw distance was low, the memory consumption high, and the resolution was too low.
This was a failure, and I thought maybe this technique was just impractical for anything but very controlled cases in certain games. I wasn't ready to give up yet without trying one last approach. Instead of allocating textures for a grid section, I tried creating a radiating series of textures extending away from the camera:
The resulting resolution wasn't great, but the memory consumption was a lot lower, and terrain texturing was now completely decoupled from the terrain geometry. I found by adjusting the distances at which the texture switches, I could get a pretty good resolution in the foreground. I was using only three texture stages, so I increased the number to six and found I could get a good resolution at all distances, using just six 1024x1024 textures. The memory consumption for this was just 24 megabytes, a very reasonable number. Since the texturing is independent from terrain geometry, the user can fine-tune the texture distances to accommodate flight sims, RPGs, or whatever kind of game they are making.
The last step was to add some padding around each virtual texture, so the virtual textures did not have to be complete redrawn each time the camera moves. I used a value of 0.25 the size of the texture range so the various virtual textures only get redrawn once in a while.
Advantages of Virtual Textures First, because the terrain shader only has to perform a few lookups each pixel with almost no math, the new terrain shader runs much faster than the old one. When the bottleneck for most games is the pixel fillrate, this will make Leadwerks 3 games faster. Second, this allows us to use any number of texture layers on a terrain, with virtually no difference in rendering speed. This gives artists the flexibility to paint anything they want on the terrain, without worrying about budgets and constraints. A third advantage is that this allows the addition of "stamps", which are decals rendered directly into the virtual texture. This allows you to add craters, clumps of rocks, and other details directly onto the terrain. The cost of rendering them in is negligible, and the resulting virtual texture runs at the exact same speed, no matter how much detail you pack into it. Below you can see a simple example. The smiley face is baked into the virtual texture, not rendered on top of the terrain:
Conclusion The texture resolution problem I feared might make this approach impossible was solved by using a graduated series of six textures radiating out around the camera. I plan to implement some reasonable default settings, and it's only a minor hassle for the user to adjust the virtual texture draw distances beyond that.
Rendering the virtual textures dynamically eliminates the high space requirements of id's megatexture technique, and also gets rid of the problems of paging texture data dynamically from the hard drive. At the same time, most of the flexibility of the megatexture technique is retained.
Having the ability to paint terrain with any number of texture layers, plus the added stamping feature gives the artist a lot more flexibility than our old technique offered, and it even runs faster than the old terrain. This removes a major source of uncertainty from the development of Leadwerks 3.1 and turned out to be one of my favorite features in the new engine.
Leadwerks Engine 2.43 is now available. This version features improved raycast performance, a new DRAWEACH entity callback, and a few small bug fixes. Registered developers can download the update by running the Leadwerks Updater.
Following completion of their successful Kickstarter campaign to bring Leadwerks’ game development software to Linux, Leadwerks has announced the release of Leadwerks Game Engine for Linux on the Steam distribution platform. This provides Linux users with a powerful tool to easily create their own 3D games.
Over the last year, Leadwerks has focused on desktop Linux as a platform for creating and playing games. For many users, Leadwerks provides the last missing application they need to move entirely over to Ubuntu or another Linux-based OS. With Leadwerks for Linux now available on Steam, developers can build and play games without ever leaving Linux.
Bringing Leadwerks Game Engine for Linux to Steam means that existing games can be more easily deployed to Linux. The Leadwerks Game Player allows users to play games published through the Steam Workshop. In most cases, games developed for Windows can be played on Linux with no changes and no recompiling, due to Leadwerks’ platform-agnostic design.
Linux support also opens the door for Leadwerks developers to publish games to the living room. Last year Valve Software announced the SteamOS, a Linux-based operating system for game consoles. Although SteamOS is still in development, Leadwerks for Linux and SteamOS promise to provide indie game developers with a way to deploy their games to the living room quickly and easily.
Leadwerks Game Engine is a powerful and easy to use development tool for building 3D games. The software has recently grown in popularity due to its ease of use, royalty-free license, and strong support for C++ and Lua programming. Thanks to the quality of modern Linux graphics drivers, Leadwerks is able to deliver high-end 3D visuals on Linux with an advanced deferred renderer using OpenGL 4.0. The Indie Edition of the software can be purchased on Steam for $99.99.
About Leadwerks Software
Leadwerks Software was founded in 2006 to build powerful game development tools that are easy to use. The company launched Leadwerks 3 in April 2013 at the GDC expo. Last summer, the company conducted a successful Kickstarter campaign to bring Leadwerks to the Linux operating system, reaching over 200% of their goal in just six weeks. A concurrent Greenlight campaign for Steam was also successful, making Leadwerks the first 3D game engine approved for distribution on Steam. In June of 2014, the Leadwerks Game Player on Steam opened the door for indie game developers to publish their games to the Steam Workshop, with no waiting period and no approval process. Although it’s been available on Steam for less then a year, Leadwerks users already have a dozen games and concepts on Steam Greenlight.
Following the successful debut of Leadwerks Game Engine: Indie Edition on Steam, Leadwerks Software today announced the launch of Leadwerks Standard Edition. This DLC on Steam adds support for programming in modern C++11 with Microsoft’s Visual Studio 2013.
C++ is the game industry’s leading programming language, due in large part to its superior performance and flexibility. However, the language is sometimes considered to be too complicated for indie developers to take advantage of. Leadwerks solves this problem by focusing on a useful subset of the C++ language, and providing a simple command library that works the same in C++ and Lua. This makes C++ game development fast and easy to control.
Adding C++ support to Leadwerks Game Engine unlocks access to a massive amount of free third-party game libraries, which are typically written for C++. Indie game developers can include new libraries for physics, AI, and virtual reality into their Leadwerks projects without having to wait for the developers to add an official bridge. This lets indie developers take advantage of the newest technologies and provides a degree of control other languages can’t match.
Leadwerks is designed to make game development easy for Steam’s 75 million users. A new renderer built on OpenGL 4.0 provides advanced graphics at an affordable price. Built-in level design tools make map design easy for users who don’t happen to be expert artists. Game code can be written with Lua, an easy-to-learn script language, or modern C++11. Finally, the royalty-free license means game developers can publish commercial games and keep 100% of the profits, with no additional payments due, ever.
The Leadwerks Game Engine: Standard Edition DLC can be purchased on Steam for $99.
About Leadwerks Software
Leadwerks Software was founded in 2006 to build game development tools that are powerful and easy to use. The company launched Leadwerks 3, their first multiplatform product, at GDC 2013. Last summer, the company conducted a successful Kickstarter campaign to being Leadwerks to the Linux operating system, reaching over 200% of their goal in just six weeks. A concurrent Greenlight campaign for Steam was also successful, making Leadwerks the first 3D game engine approved for distribution on Steam.
Leadwerks Software has released an official Blender exporter for the Leadwerks model format. This allows Blender artists to export their models to Leadwerks with automatic materials generation and full animation, without going through the FBX format. The Blender exporter comes as the fulfillment of a stretch goal reached during the Leadwerks for Linux Kickstarter campaign, which achieved over 200% its goal of $20,000.
The Leadwerks exporter for Blender can be downloaded on the Leadwerks forum. A free forum account is required.
About Leadwerks Software
Leadwerks Software was founded in 2006 to build powerful game development tools that are easy to use. The company launched Leadwerks 3, their first multi-platform product, in April 2013 at the GDC expo. Last summer, the company conducted a successful Kickstarter campaign to bring Leadwerks to the Linux operating system, reaching over 200% of their goal in just six weeks. A concurrent Greenlight campaign for Steam was also successful, making Leadwerks the first 3D game engine approved for distribution on Steam.
Following completion of a successful Kickstarter campaign to bring Leadwerks’ game development software to Linux, Leadwerks and Canonical have joined forces to make Leadwerks Game Engine available in the Ubuntu Software Center. This provides Ubuntu users with a powerful tool for rapid game development.
Bringing Leadwerks Game Engine to Ubuntu also means that existing games can be more easily deployed for Ubuntu. The lineup of featured games on the Leadwerks website covers a diverse range of genres including strategy, action, and simulations. Michael Juliano, developer of the space combat simulation game Rogue System, says that he is now planning on Ubuntu support in his upcoming title due to the ease of deployment Leadwerks provides. “One of the reasons we chose Leadwerks was due to its strong support for Linux”, said Michael. “We’re definitely interested in bringing Rogue System to Ubuntu.”
Jono Bacon, community manager for Ubuntu, said that ”Canonical is delighted to be working with Josh at Leadwerks to help further Ubuntu and Linux and in general as a next generation platform not just for consuming games, but building a powerful community of games developers and content creators”. With 25 million users, Ubuntu is widely used by game developers and players alike who enjoy it’s open nature and long term vision of convergence.
Leadwerks Game Engine is a powerful and easy to use development tool for building 3D games. The software has recently grown in popularity due to its rapid development capabilities, royalty-free license, and strong support for C++ and Lua programming. Thanks to the quality of modern Linux graphics drivers from ATI and Nvidia, Leadwerks is able to deliver high-end 3D visuals on Ubuntu. An advanced deferred renderer provides realistic light and shadows on any machine supporting OpenGL 4.
About Leadwerks Software
Leadwerks Software was founded in 2006 to build powerful game development tools that are easy to use. The company launched Leadwerks 3, their first multi-platform product, in April 2013 at the GDC expo. Last summer, the company conducted a successful Kickstarter campaign to bring Leadwerks to the Linux operating system, reaching over 200% of their goal in just six weeks. A concurrent Greenlight campaign for Steam was also successful, making Leadwerks the first 3D game engine approved for distribution on Steam.
Canonical is the company behind Ubuntu and the leading provider of services for Ubuntu deployments in the enterprise. With global teams of developers, support staff and engineering centres, Canonical is uniquely positioned to help partners and customers make the most of Ubuntu. Canonical is a privately held company.
Ubuntu is a free, open-source platform for client, server and cloud computing. It is the most widely used Linux on the top 1000 websites by traffic, the reference platform for OpenStack deployments, the most popular guest OS on public clouds, and ships on PCs from Dell, Lenovo, HP and other brands. Since its launch in 2004, it has become the preferred choice for open desktop and scale-out computing, from Fortune 500 companies to hardware makers, content providers, software developers and consumers.
First, so you don't have to read through all my rambling, the website database is set back to November 2010, and there is no way around it.
I was working with the forum software on Sunday, 4-17, and I was just very pleased with how things were working. I saw there was an update for the bug tracker application, and the change list just mentioned some bug fixes, so I felt okay installing it. The new version removed custom issue fields, which we use extensively for listing hardware, drivers, operating systems, etc.
It's not very easy to revert to previous software versions. I had performed a full website backup earlier that day, so I figured the best way to revert the tracker app would just be to have the IT admin revert the server to the backup I had made. I'd downloaded it to my local hard drive and it was intact, and also still available on the server. I also had an earlier full website backup I made on April 2. I figured this would be a minor inconvenience that would take the forum offline for a few hours.
Here's the interface in CPanel:
I also talked to the IT admin and they assured me that the full website backup does includes MySQL databases. I sent the following message to them Sunday afternoon:
My caution in this email might indicate I had a suspicion something was wrong. Did I somehow know something would go wrong? Should I have? This thought is nagging me right now.
I've been on the phone with tech support for a couple days, but you don't need the whole story. The outcome is the server was erased and repopulated with the contents of the backup archive. All files were intact, but the databases were not saved when the backup was performed. The previous backup I had was from April 2, which would not be a terrible loss. It appears the same occurred then. In fact, since I have been dutifully saving full website backups since November, thinking I was making extra effort to be on the safe side, the databases were never being saved in the archive. So the last copy of the forum database I have is from November 2010. I've been quite diligent with backing the site up, but that doesn't mean anything if the backups aren't working. The host automatically backs up sites under 10 gb every 24-36 hours, but that size excludes us.
Although it was easy to bring the forum software up to date, all forum data since November 2010 is gone forever. The loss of this is staggering. To me, and to others here.
You can get your screenshots here in a single package. They're randomly named, but if you really need something you can find it, and it's divided up by month:
I still have all the attached files from posts, blogs, downloads, etc., but they are randomly named and I don't know how possible it is to go through them.
The thing that really hurts is the lost documentation that was created after November. That's going to take time to recover from. We'll recover, but the loss is still sinking in for me. Jorn worked really hard on that at a reasonable pay rate and I feel really bad about it.
I have records of all registered users. If you registered for your Leadwerks account after November of 2010, your account will be recreated and your password will be set to your registration key you received.
The wiki and old forum are fine.
The new forum skin is fine, but not installed at the moment.
This must never happen again.
First, a better backup protocol is needed. The most important thing is that the backups actually be valid backups. Obviously, I've learned that MySQL databases must be backed up individually and that a full website backup from CPanel is not reliable. Data is saved to a 2 TB external hard drive. Additionally, I am opening a safe deposit box where code and site data are regular deposited. I already thought I was doing everything right, so at this point I feel like I can't be too careful.
Second, I am locking the forum software at the current versions, unless a critical vulnerability is discovered. In 2009, all we had was an installation of PHPBB. The idea for Werkspace was something Annika came up with and gradually sold me on. We listed all the features we wanted and found forum software that would allow it. Customizing the look and feel of the software to fit in with the theme of Leadwerks was a long process, but we finally got a suitable skin made. I am satisfied with the features and functionality of the system, and now we can just leave it be, indefinitely. The data loss does not affect the skin we had developed. The skin will continue to get minor improvements, but those kind of changes are easily performed and rolled back, if need be.
Third, semi-annual tests are needed to make sure data can be restored successfully to a test server. Backups don't help if you wait until you need them to find out they don't work. A test server will be used to install the latest backup on every six months, or before any restoration takes place. Maybe this is overkill, but nothing was supposed to go wrong before, and we found out otherwise.
It seems redundant to say I'm sorry about this occurrence. I know we'll get back to normal, but it hurts pretty bad. The key point is my data backup technique was flawed, so all the backups I've been performing were worthless.
Leadwerks 3.1 has entered the beta testing phase on schedule according to our development plan laid out in the Leadwerks for Linux Kickstarter campaign. Supporters who chose the SUPER BACKER reward have been granted access to try the early builds of Leadwerks for Linux.
We chose to use the excellent Code::Blocks IDE for Linux development. Beta testers can access the full Leadwerks API to program graphics, physics, and gameplay, along with a few new functions like Camera::SetMultisampleMode(), which sets the render antialiasing level.
Although the beta is not a complete finished product, we've already learned a lot about building high-end graphics for Linux. First of all, the Linux OpenGL drivers for ATI and Nvidia hardware are fine. We've encountered no graphics drivers bugs (so far). This may be due to the streamlined nature of OpenGL 4, as it removes a lot of legacy functionality. Whatever the cause, OpenGL drivers for Linux work great, much better than Windows drivers did a few years ago in the dark days between OpenGL 2 and 3.
The biggest remaining challenge is to get the editor running in Linux. We anticipate two difficult parts to this. First, although we have a GUI abstraction layer that uses GTK on Linux, we expect some amount of fiddling to be necessary to make it work right. Second, the case-sensitive nature of the Linux file system will cause issues that need to be dealt with since there are many placed where our editor stores file names in lower-case format. This will require a lot of effort to resolve, but it's not any harder than some of the other issues we have dealt with so far in the development of Leadwerks for Linux. The benefits of having a Linux game editor with a native look and feel will make it worth the extra effort it takes.
Steam Dev Days Leadwerks founder Josh has been invited and will be attending Steam Dev Days in Seattle, Washington. Steam Dev Days is a two-day game developer’s conference where professionals can meet in a relaxed, off the record environment. Developers will share their design and industry expertise, participate in roundtable discussions and attend lectures by industry veterans on topics ranging from game economies to VR, Linux/OpenGL, user-generated content and more. Developers will also have direct access to Valve’s Steam Team, and will be given a chance to test-drive and provide feedback on Steam OS, prototype Steam Machines and Steam Controllers.
Leadwerks Software today announced the release Leadwerks Game Engine 3.2, the newest version of their game development software on Steam. This update brings integration with Workshop, Steam’s system for user-generated content. The Leadwerks Workshop gives developers a head start by launching with more than 50 free packages of content ready to be used to make games.
“Leadwerks was created to give people who love games the freedom to create something of their own”, said Leadwerks CEO Josh. ”With version 3, we basically nailed the workflow. There’s always more features you can add, but we basically have the technology problem solved. Once you get to that point, the next thing that comes up is content. Developers need lots of content to choose from. The Leadwerks Workshop on Steam leverages our community so we can all collaborate more effectively.”
The Leadwerks Workshop has some features similar to existing stores like Turbosquid or the Unity Asset Store. You can browse and install various third-party model and texture packs. However, the Leadwerks Workshop takes collaboration a step further. Derivative works are supported, meaning items in the Workshop can be used to make new items that can be published. For example, it’s possible to take a gun from one author, mount it on a vehicle someone else made, and publish the assembly as a new item. “With traditional content stores, artists are always worried about people ripping off their work,” explains Josh. “This kind of flips the equation. Now you want people to reuse your work, because any derivative items they publish always link back to your original.”
Game content isn’t the only thing that can be distributed through the Leadwerks Workshop. Games themselves can be published to Steam via the Workshop, with no waiting period and no approval process. This allows developers to get their game in front of an audience and build a following, without going through the Greenlight process.
Leadwerks Game Engine 3.2 costs $99.99 on Steam, with a 25% discount during the 2014 Steam summer sale.
About Leadwerks Software Leadwerks Software was founded in 2006 to build powerful game development tools that are easy to use. The company launched Leadwerks 3, their first multi-platform product, in April 2013 at the GDC expo. Last summer, the company conducted a successful Kickstarter campaign to bring Leadwerks to the Linux operating system, reaching over 200% of their goal in just six weeks. A concurrent Greenlight campaign for Steam was also successful, making Leadwerks the first 3D game engine approved for distribution on Steam.
Today we are pleased to announce the release of Leadwerks Game Engine: Enterprise Edition, a standalone version of our popular 3D development software. The Enterprise Edition allows business users to install and use Leadwerks without the need for the Steam client. The new product joins the existing Standard Edition with Lua scripting and the Professional Edition with C++ and Visual Studio support, both sold on Steam.
The Enterprise Edition has already been approved for sale through NASA’s ACES approval program for software, and NASA has joined a lineup of business customers using Leadwerks products that includes Lockheed Martin, Northrop Grumman, and the British Royal Navy.
In the near future the capabilities of our software will continue to expand to support the needs of business customers in the VR and simulation spaces. The development of Leadwerks Game Engine 5 is being directed with a focus on performance, hyperrealism, and improved ease of use.
Leadwerks Game Engine: Enterprise Edition is available to purchase for $499 on our website.
Image courtesy of NASA Satellite Servicing Projects Division.
Today I am excited to announce plans for the release of the first Leadwerks 5 beta version. Leadwerks 5 will roll out sooner rather than later, employing an extended beta period during which versions 4 and 5 will live side-by-side, using the same code base, with preprocessor definitions to compile each version. This allows me to fix small problems without forking the code, while I can implement new changes in version 5. The first features implemented will be the use of smart pointers for all shared objects, and unicode support for all strings.
A subscription model will be available for access to the Leadwerks 5 beta, at a modest price of just $4.99/month for enthusiasts who want access to the most cutting-edge game development technology as it is developed. This will be available through the Leadwerks.com site, and will not use Steam (at least at first). I feel it is important for the company's future to start building a recurring revenue stream, and I want to create something that does not rely on any middleman who may arbitrarily change or discontinue the terms of the service they are providing. The Leadwerks 5 beta will implement breaking changes as it is developed, and is not meant for use in a production environment, so I do not recommend moving any commercial projects from version 4 to 5. Leadwerks 4.x will continue to receive updates and new features until the final version 5 is released.
Leadwerks 5 is designed to be the most advanced game engine in the world, combining improved ease of use with massive performance, and a special emphasis on VR. Thank you for supporting the next generation of game development technology.
Back around February I started working on a website update that included the following:
Responsive design everywhere.
Visual improvement of website.
Updated documentation system.
Tutorials for C++ programming basics.
Update forum software to new major version.
Forum moved to new URL.
All of that is now pretty much done. These changes improve the online Leadwerks experience and are independent from the software itself, so it was a good idea to get them done now.
Since September I've had more time to think about Leadwerks Game Engine 5, and although I am not completely sold on Vulkan, I think it's a good plan.
Leadwerks 5 is all about performance and user experience with VR as a prime target.
Separate threads for navmesh updating, physics, game logic, culling, and rendering. The rendering thread loops at a constant 60 or 90 (for VR) frames per second regardless of what your game is doing. This gives your game logic four times more time to run, while independently maintaining a constant framerate. The design I have in mind will make Leadwerks 5 the fastest game engine, ever, and choosing Leadwerks for VR will be a no-brainer.
Leadwerks Editor 5
A new editor will be written in C++ using Leadwerks GUI, which will give us the same appearance on Windows, Linux, and Mac. Functionality will be pretty close to the existing editor, but with more room to grow and a few improvements. Because it's written in C++ parts of the editor can be exposed to Lua, and an editor API will be provided for making Lua mods and plugins. By default, it will use a dark theme to be easy on the eyes. A standalone script editor may be provided as well.
PBR Material System with Substance Support
The lighting model will use a more advanced lighting equation and substance PBR materials (metalness and roughness) will be loaded natively.
The reference counting system in the Object class will be replaced with C++11 shared pointers. This gives you the performance of C++ with ease of use like a garbage-collected language.
The engine and editor will be released as a 64-bit build only.
More game templates will be provided. Fortunately we can add these now and updates for Leadwerks 5 will be minimal.
Source code to some parts of the engine and editor may be provided on the Leadwerks GitHub account. For example, I may make a standalone open-source script editor or publish some of the engine classes for the community to play with.
Leadwerks 5 will launch on Windows, Linux, and Mac. The improved compatibility of Leadwerks 5 means we could do crazy things like run the editor on an iPad, but I'm going to stick with what I know sells.
A standalone version that does not use Steam will be sold in bundles to companies that require this.
A monthly plan may be introduced at around $5-20 per month. Pricing for a perpetual license for the standard and pro editions would most likely be the same as now ($99-199), with a discount for early adopters / upgrades. The enterprise version would probably be about $1000 per seat with a discount for schools.
If you found this blog interesting, please consider using the social media share buttons below to share it.
I wanted to add some default procedural generation tools in the Leadwerks 3.1 terrain editor. The goal is to let the user input a few parameters to control the appearance of their terrain and auto-generate a landscape that looks good without requiring a lot of touch-up work.
Programmers commonly rely on two methods for terrain heightmap generation, Perlin noise and fractal noise. Perlin noise produces a soft rolling appearance. The problem is that Perlin noise heightmaps look nothing like real-life terrain:
Fractal noise provides a better appearance, but it still looks "stylized" instead of realistic:
To get realistic procedural terrains, a more complex algorithm was needed. After a few days of experimentation, I found the optimal sequence of filters to combine to get realistic results.
We start with a Voronoi diagram. The math here is tricky, but we end up with a grid of geometric primitives that meet at the edges. This gives is large rough features and ridge lines that look approximately like real mountains:
Of course, real mountains do not have perfectly straight edges. A perturbation filter is added to make the edges a little bit "wavy", like an underwater effect. It gets rid of the perfectly straight edges without losing the defining features of the height map:
The next step is to add some low-frequency Perlin noise. This gives the entire landscape some large hills that add variation to the height, instead of just having a field of perfectly shaped mountains. The mixture of this filter can be used to control how hilly or mountainous the terrain appears:
We next blend in some Fractal noise, to roughen the landscape up a bit and add some high frequency details:
Finally, we use thermal and hydraulic erosion to add realistic weathering of our terrain. Thermal erosion works by reducing the harshness of steep cliffs, and letting material fall down and settle. Hydraulic erosion simulates thousands of raindrops falling on the landscape and carrying material away. This gives beautiful rivulets that appear as finger-life projections in the height map: Rather than relying on conventional hydraulic erosion algorithms, I created my own technique designed specifically to bring out the appearance of those features.
Here is an animation of the entire process:
And in the renderer, the results look like the image below. All the parameters can be adjusted to vary the appearance, and then you can go in with the manual tools and sculpt the terrain as desired.
The new landscape has ridges, mountains, and realistic erosion. Compare this to the Perlin and fractal landscapes at the top of this article. It's also interesting that the right combination of roughness and sharp features gives a much better appearance to the texture blending algorithm.
I'm happy to announce the very first alpha release of Leadwerks 5 is now available.
String commands now accept a unicode overload. Add "L" in front of a string to create a wide string in C++.
Now using smart pointers. Simply set a variable to nullptr to delete an object. There is no Release() or AddRef() function.
Global states are gone. There is no "current" world or context. Instead, the object you want is passed into any function that uses it.
We are now using constant integers like WINDOW_TITLEBAR instead of static members like Window::Titlebar.
Now using global functions where appropriate (CreateWorld(), etc.).
Renderer is being designed to be asynchronous so Context::Sync() is gone. 2D drawing is not implemented at this time.
Here's the syntax for a simple program.
using namespace Leadwerks;
int main(int argc, const char *argv)
auto window = CreateWindow(L"My Game", 0, 0, 1024, 768, WINDOW_TITLEBAR);
auto context = CreateContext(window);
auto world = CreateWorld();
auto camera = CreateCamera(world);
camera->SetPosition(0, 0, -3);
auto light = CreateDirectionalLight(world);
light->Turn(45, 35, 0);
auto model = CreateBox(world);
if (window->KeyHit(KEY_ESCAPE) or window->Closed()) return 0;
if (window->KeyHit(KEY_SPACE)) model = nullptr;
You can get access to the Leadwerks 5 Alpha with a subscription of $4.99 a month. You will also be able to post in the Leadwerks 5 forum and give your feedback and ideas. At this time, only C++ is supported, and it will only build in debug mode. It is still very early in development, so this is really only intended for enthusiasts who want to play with the very bleeding edge of technology and support the development of Leadwerks 5.
I'm a big fan of constructive solid geometry because it allows people without advanced modeling skills to design a game level that looks great. In fact, I originally got my start in game development using the Quake and Half-Life modding tools, making game maps.
One of the criticisms of CSG has been that it only allowed creation of faceted objects. (Valve's Hammer Editor has a workaround for this that lets you set smooth groups, but you can't see the results until they are run in the game.) This was preventing me from making some game level features I wanted, like curved arches and rounded corners, so I decided to do something about it.
Leadwerks supports smooth groups for CSG objects. To access the controls, switch to face editing mode and then select the objects tab in the right-hand sidepanel:
It was fairly easy to calculate vertex normals from smooth group information. However, that information still has to be fed to the lightmapper or the lighting will appear faceted across a curved surface:
To solve this, I needed to calculate the interpolated normal across the surface, and use that for the lighting equation for each luxel (lightmap pixel). Initially, I thought I could use a simple weighted average. Vertices near the luxel would have a high influence, and vertices further away would have less influence. However, it quickly became apparent this would not produce anything close to accurate results!
Gouraud Shading The problem I was facing is actually a very common calculation that is done in real-time on the GPU. This was the first time I ever had to calculate it myself. It turns out the problem was first solved before I was born by a clever fellow by the last name of Gouraud, and thus we call it Gouraud Shading or Gouraud Interpolation.
The algorithm works like this: draw a straight line in any direction from the point you want to interpolate. It doesn't matter what angle, as long as it's one straight line. Now find the two triangle edges the line intersects. Each of those edges is connected to two vertices, each with a normal. Use a linear interpolation to weight those two normals, for each point. Finally, use the distance of both these points from your original position to weight their interpolated normals:
More information on this technique can be found here.
Implementation Getting this to work on a CSG lightmapper was difficult for two reasons. First, CSG objects consist of n-sided polygons, not triangles. Although they can be broken down into triangles, I was worried that visual artifacts might arise. Second, lightmaps have a user-defined bleed border, and the luxels of a lightmap extend beyond the edges of the polygon being lit. Gauroud shading requires the point being interpolated actually be inside the triangle. Our luxel positions could be inside any of the triangles that make up a polygon face, or they might not be on the face at all!
I decided to start by only worrying about the luxels that fell inside one or another triangles on the face, and solve the outliers later. Fortunately, the transform and math classes built into Leadwerks 3 made it fairly easy to convert all the points into flat 2D space to solve the problem. As expected, my first attempt identified the luxels that fit inside a particular triangle, but the luxels along the edges could not be processed, and appear dark:
I added an error threshold for the triangle intersection routine, which got rid of the black borders, but turned out to be a bad idea. Some of my values were being interpolated in the wrong direction, as you can see in the following images:
In this image, it's almost working, but the error threshold is causing luxels along the center seam to get lit incorrectly. Additionally, a few luxels in the top right are forming a dark border:
The final piece of this puzzle was to deal with luxels that didn't fit into a particular triangle, This was a pretty puzzling problem, and for a while I thought there might not be a "correct" solution. However, if you think about it intuitively, a luxel that lies just outside a triangle should use the same lighting as a luxel just inside that triangle, right next to it.
For the remaining unsolved luxels, I tested each of their distances to each triangle in the face they belong to. I found a nearest triangle to each, then found the nearest point on that triangle, and calculated the normal from that point's position.
Results This technique produces beautiful smooth lightmapping on curved surfaces:
The algorithm works with curves, arches, sphere, any CSG objects that use smooth groups. So now you can make those castles, arches, and towers you've always wanted to build:
This feature will be available in the next update to Leadwerks 3.
Today we are pleased to announce the release of Leadwerks Game Engine 4.5.
Version 4.5 introduces support for VR headsets including the HTC Vive, Oculus Rift, and all OSVR-based hardware, allowing developers to create both room-scale and seated VR experiences. The Leadwerks virtual reality command set is robust yet incredibly simple allowing you to easily convert your existing 3D games into VR titles. To help get you started the source code for our Asteroids3D game has been updated for VR and is now freely available in the Leadwerks Games Showcase.
Leadwerks Game Engine is uniquely well-suited for VR because of its fast performance, ease of use, and the availability of C++ programming for demanding VR games. Several optimizations for VR have been made including combining the rendering of both eyes into a single culling step. The stability and accuracy of Newton Game Dynamics means we can have in-depth physics interactions in VR.
A new VR game template has been added to provide common VR features including teleportation locomotion and the ability to pick up and interact with objects in the environment.
Visual Studio 2017
We've also upgraded Leadwerks Professional Edition to build with Visual Studio 2017 so you can take advantage of the very latest Visual Studio features. Instructions for upgrading C++ projects from version 4.4 to 4.5 are available here.
Added fog settings in editor and into map file format.
New joint scripts and enhancements.
Updated to Steamworks 1.41
You can pick up Leadwerks Game Engine with a discount during the Steam Winter Sale.
Leadwerks 3 is a new game engine purpose-built for mobile. By building the entire platform on pure native code, Leadwerks aims to bring a new level of performance and flexibility to 3D mobile games.
After two years of development, the team is now beginning a closed beta test. Select members of the community will provide feedback and testing so that final bug fixes and refinements can be made.
You can sign up to our mailing list for up to date information as we finish up development of the new Leadwerks. Visit www.leadwerks.com to learn more.
A preview build of Leadwerks Game Engine 4 is now available on the default branch on Steam, with a new vegetation management system and other features.
We completely rethought how large-scale scene management should work to bring you a one-of-a-kind vegetation system for handling massive amounts of foliage. Instead of storing each instance in memory, our new system uses a distribution algorithm to dynamically calculate all relevant instances each frame for rendering and physics. This allows enormous densely packed scenes with minimal overhead. The results are blazingly fast, efficient, and easy to use. In fact, the new system is so advanced it's featured in the upcoming book Game Engine Gems 3. Other features include autocomplete in the built-in script editor and integration with Steam Leaderboards.
To help you make the most of the new vegetation system, we're also introducing the Nature Model Pack DLC. This includes trees, plants, grass, and rocks, to make a variety of outdoors settings with.
Leadwerks Game Engine 4 is a free update and allows publishing of games for the PC and Steam Machines.
Frictional Games is the developer of puzzle horror games like Penumbra and the new Amnesia: The Dark Descent. We sat down with Frictional Games co-founder Thomas Grip to learn more about their development process.
Josh: I'm a big fan of the Penumbra series. What can we look forward to in Amnesia: The Dark Descent?
Thomas Grip: There is a lot to of new stuff in the game. First of all the game is a more streamlined experience both in terms of general gameplay and interaction. For the gameplay we have made sure that the focus is always on atmosphere and story, and made sure that the player is never stuck at a puzzle for too long and stuff like that. One of the ways we do this is to allow multiple solutions so it always feels intuitive to the player.
In terms of interaction, it is much easier to interact now. In Penumbra it could be a pain to open doors at times because you needed to click on the right spot and so on. In Amnesia all that is fixed and it is now possible to easily slam shut a door in the face of an enemy and things like that.
There is also a new insanity system, a fresh environment, and new story.
Josh: Can you talk about the process of developing an idea and turning it into a full-fledged game? Do you start with a design document or just start writing code? How closely does your final game resemble what you originally imagined?
Thomas Grip: This time we had a very long iteration period where we tested out various ideas. We actually first had a bite-sized horror design inspired by Super Mario. It was intended to have small self-contained levels and to be played in shorter bursts. It did not fall out too well and we tried tons of stuff before settling where the final game is.
In the early iterations we started out with a "fun" mechanic and tried to base a game on that, but as I said, it did not turn out good. Instead we started focusing on the themes and general feel of the game. Then we started building minimal mechanics to support that. To do this we took a lot from Penumbra, as we knew how it worked, and refined it.
Once we had the general feel going 1/3 or so is drawn up on paper and we started making maps based on that, then as maps are made we continue to design the remaining 2/3 on paper taking cues from the maps being built. These written paper designs are often very close to the full game and that is a way for us to be able to plan ahead very accurately. Early on we knew around 90% of the assets that we needed, which is great when outsourcing. Then in the final steps the maps get polished and we play them over and over and try to build up the feel we are after. If something does not work out, we often scrap it instead of rebuilding it.
Josh: Towards the end of the first Penumbra game, you communicated with a major character over an intercom system. The character never actually appeared on screen, but the emotional connection was established using voice acting. This struck me as a good design decision, because you were able to eliminate all the trouble of making an animated character speak in a convincing cut scene, without detracting from the player's experience. Are there any other examples like that where you made design decisions that helped streamline production, so you could focus on the core gameplay?
Thomas Grip: There is a lot of that stuff in Amnesia. For example, there is one character without a lower jaw, which removed the need to do lip-sync. When it comes to visions we only use sound (without models, like in System Shock 2), which in turn also gives the game a more spooky feel. I think having these kinds of constraints also forces you to use your imagination more and not just follow the design of other games. Although it is a bit annoying not being able to do certain stuff, it often turns out positive for us.
Josh: What's next for Frictional Games?
Thomas Grip: Rest! And tech support... And then we have to see how sales and so go! We have an interesting idea we would like to pursue, but it depends a bit on how we do financially.
Check out Amnesia: The Dark Descent for creepy thrills and inspiring game design.
Leadwerks Engine 2.3 has been released. This major update includes a new editor, Lua script integration, forest rendering, roads, and more.
Lua Script Integration: Write object scripts and write your game in any programming language, or you can write your entire game in Lua.
New Editor: Leadwerks Editor is our new tool for creating enormous terrains, placing objects, and creating worlds. You can even edit scripts and see the results instantly.
Forest Rendering: An advanced new rendering algorithm makes it possible to render hundreds of thousands of trees and plants, at playable framerates. Make dense forests that stretch for miles.
Roads: Build spline-based roads and paths in the editor. Roads can branch, stretch, and fade out. You can even go for a drive on your highways and byways in the editor.
Terrain Holes: Remove patches of terrain and go underground with caves and bunkers. This feature brings a new subterranean dimension to your games.
High Dynamic Range (HDR): Brights are brighter, and darkness is darker. High dynamic range allows a greater range of color to be displayed, with automatic iris adjustment to correct for the ambient lighting environment.
Animation Improvements: Characters can have up to 256 bones, with fast hardware skinning performed on the graphics card.
Rendering Framework: It's easy to toggle advanced effects on and off, in any combination, with commands like SetBloom() and SetHDR().
Like many programmers, I used to consider scripting languages to be a "toy": They are nice and easy to use, but ultimately I thought it was just programming for people who don't want to install Visual Studio. I started playing with Lua back in June of 2009, and the potential for this wonderful language quickly became apparent. Our integration of Lua allows script to be written on both a global and per-object basis; You can write your entire program in Lua, like you would with C++ or another language, or you can write a script specifically for one object class, with different predefined functions to be called during the program. There are functions that can be called when an object hits something, when it is created, or once every frame to update the object. Object scripts can be used together with C++ or another programming language. This means that anyone who uses Leadwerks Engine, with any language, can download a scripted object, drop it into their program, and have the same behavior working in their own game. The implications of this are immense.
Suddenly we found that instead of being a collection of a few hundred individual programmers, the community suddenly became a collaborative, collective group. If one developer writes a script for a scary monster and posts it online, another user can download it, drop it into the editor, and see the results, with no code changes. You can even edit the script in Leadwerks Editor, save it, and instantly see the results. For the first time, developers could easily work together and share their creations, and still use whatever programming language they preferred. Lua has changed the whole feel of the community to a more social and cooperative group.
Keeping it Real-time
Our design philosophy for Leadwerks Engine is that everything should run in real-time, and thus be editable in real-time. Lighting and physics are already editable in real-time with instant feedback, but it took some time before I realized we can extend this approach to something else: programming. The new editor has an integrated script editor. To edit an object's script, you simply double-click on its node in the scene tree. You can view all the code that makes the object to whatever it is doing. You can also make changes to the script, save it, and the object's behavior is instantly updated! The lack of a compiling phase allows you to fine-tune behavior to get it just the way you want. Plus, it's a just lot of fun to use. For an in-depth description of our Lua implementation, see here:
The Road to Perfection
Roads look nice, but the reason I really like them is they allow new dimensions of gameplay. When I started off writing the road editor, I had a few requirements. I wanted the roads to be written entirely with Lua object scripts. This was a challenge, and forced me to add several features to the script integration to make it work. I also wanted roads that aligned perfectly to the terrain, like they do in Crysis. First I wrote the mesh generation routine that makes a spline-based road. This is fairly simple, but it is only part of the problem. The biggest challenge was slicing the road up by the terrain grid, so that every vertex on the road lined up along the terrain, and the whole road lay perfectly snug. UV mapping the tessellated road was another major challenge, but a clever solution was found after many attempts. The resulting roads look great and conform perfectly to the terrain. And they're fun to go driving on!
Seeing the Forest for the Trees
The forest rendering algorithm is my favorite new rendering feature. The bulk of this was written in the spring of last year, but there were a few details I didn't complete until recently. I spent hours playing with the Crysis editor and trying to figure out how they heck they were able to render so much foliage. I read article after article, but no one seemed to have a good approach. Most of the forum discussions on graphics development sites seemed to amount to just saying "use billboards". The problem is that rendering 100,000 billboards is still a major challenge. The solution was found by analyzing what format data the GPU will render most efficiently, and then working backwards to find a way to get the vegetation in that format. The solution is elegant, and seamless to the end user. There's no baking or pre-processing. You paint as many trees and plants on the terrain as you want, and it just works. I still have some more ideas to implement, like destructable trees and even better efficiency, but I am quite happy with how it turned out.
The first Leadwerks Winter Games tournament has begun!
How to Enter Submit your playable game to the Leadwerks Games Catalog, before January 15th. You can use any Christmas or non-Christmas related ideas. You can work together in teams or on your own. On the day of January 15th, a review of submitted games will be posted.
Prizes Rather than a competition, this tournament is a "co-opetition". The community is encouraged to help one another make fun playable games. Everyone who participates in the tournament will receive a prize.
If this is your first official game tournament entry, you will receive a Leadwerks sticker in the mail.
If this is your second tournament entry, you will receive a Leadwerks T-shirt in the mail.
If this is your third tournament entry, you will receive a rockin' Leadwerks beanie to keep your head warm. (Image not available yet.)
Getting Started To help kick off the contest, we've released the Christmas Props Pack by Rich DiGiovanni for free in the Leadwerks Workshop. Feel free to use these models to get started with your game idea. You can participate by posting blogs about your game's development, or just post some work-in-progress screenshots. (Also, if you need more models, Rich is available and does great work at a reasonable price.)
If you've got a serious project in development, this is a great opportunity to take a break and make a simple fun game, or you can even make a simplified teaser of your game to drum up a fan base. Here are a few entries from past tournaments.
Most of all have fun, and watch out for reindeer!
Leadwerks Game Engine 4.1 is now available on Steam. This release cranks up the already legendary Leadwerks visuals to new levels of awesome.
Environment Probes The new environment probe entities can be used to add global illumination and reflections to any scene.
Volumetric Lighting Each light in Leadwerks can now display an adjustable volumetric effect using a ray-marching technique to give your game dramatic visuals.
Enhanced Post-Processing Effects Leadwerks 4.1 includes new built-in post-process effects including volumetric light scattering and screen-space ambient occlusion. Older effects like bloom have been updated for improved visuals.
Leadwerks Game Engine is available for purchase on Steam and can be purchased at a discount during the Steam summer sale, for Windows and Linux.
Internally, Leadwerks Editor uses an EventHandler class for every interface in the program. The material editor is a class extended from the EventHandler. So is the little window that has all the controls to calculate normals. So is every viewport.
The event handler class has one important function:
Every EventHandler has access to events as they occur. This is how all program actions are handled in the editor.
The plugin system will work by hooking into the event system. Each plugin will have a Lua script that receive events before the rest of the program sees them:
If the plugin makes no changes to the event then it simply returns the original event. The returned event is then sent to other event handlers.
Here is an example of a plugin that would disable the close window button on the main window. Because the function returns nil the event is discarded before the main window ever evaluates it:
if event.id == EVENT_WINDOWCLOSE and event.source == editor.mainwindow then
Here is an example of a very mean plugin that would make it so that clicking the File > Open menu item in the main window quits the program:
if event.id == EVENT_MENUEVENT then
if event.source == editor.mainwindow then
if event.extra == MENU_FILEOPEN then
event.id = EVENT_WINDOWCLOSE
Okay, now let's see if we can design a plugin for something people would actually want. Let's imagine we have a new visual material design system. The exact details of how it works are not important, it's just a system that overrides the default material editor. The design system would require materials to have a special file associated with them with the extension .DESIGN. If you open the material "brick.mat" we will look for a file in the same folder called "brick.design". If the design file is found we open the material in our special editor. If the design file is missing we will just fall back to the default material editor.
Now let's see how our system can handle this:
--Create our interface
self.window = CreateWindow("Material Designer",0,0,800,600,editor.mainwindow,WINDOW_CENTER + WINDOW_TITLEBAR + WINDOW_RESIZABLE)
if event.id == EVENT_FILEOPEN
--Check for material files being opened
--Look for design file
local designfilename = StripExt(event.extra).".design"
if FileType( designfilename ) == 1 then
--Load the design file
local stream = ReadFile(designfilename)
if stream ~= nil then
--Display our custom material editor
Print("Error: Failed to load design file.")
--Discard the event
As you can see, this approach is extremely powerful. The event IDs and design rarely change, if ever, so this allows a lot of flexibility and at the same time gives us the optimal compatibility as changes are made to the core editor. With this approach to plugins you can literally do anything you want in the editor.
Now that you've had time to get acquainted with Leadwerks, it's time for the Summer 2016 Game Tournament.
WHEN: The tournament will start Monday, July 25, and end Sunday, August 21th at 11:59 P.M. (Pacific Standard Time).
HOW TO PARTICIPATE: Publish your summer-or-other-themed game to Steam Workshop or upload it to the games database before the deadline. You can work as a team or individually. Use blogs to share your work and get feedback as you build your game. If you need models for your game, we've got a summer model pack for you to use for free from Leadwerks Workshop.
Games must have a preview image, title, and contain some minimal amount of gameplay (there has to be some way to win) to be considered entries. It is expected that most entries will be simple, given the time constraints.
PRIZES: Rather than a competition, this tournamant is a "co-opetition". Everyone who participates gets a prize!
If this is your first game tournament entry, you will receive a cool Leadwerks sticker in the mail.
If this is your second game tournament entry, you'll receive a collection of three limited-edition professionally printed postcards featuring beautiful Leadwerks screenshots. Send them to a friend or put them on the wall.
If this is your third game tournament entry, you'll receive a rockin' Leadwerks T-shirt in the mail. Wear it to show how cool you really are.
If this is your fourth game tournament entry, you'll receive the new Leadwerks hoodie! This gorgeous garment makes you look like a Silicon Valley startup geek. This light jacket is perfect for air-conditioned spaces that are just slightly chilly.
If this is your fifth game tournament entry, you will receive a Steam Controller. The Steam Controller lets you play your entire collection of Steam games on your TV—even the ones designed without controller support in mind.
Bonus Prize All participants will receive an 11" x 17" printed poster for the Summer Games 2016 Tournament! This limited-run item will be printed only once, only for this event. This is your only chance to get this poster, ever.
Make games and have fun!