Jump to content

Entries in this blog

Leadwerks 5 Beta Rollout

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.

Josh

Josh

Plugins in Leadwerks Game Engine 5

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: Event ProcessEvent(Event) 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: function Script:ProcessEvent(event) return event end 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: function Script:ProcessEvent(event) if event.id == EVENT_WINDOWCLOSE and event.source == editor.mainwindow then return nil else return event end end 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: function Script:ProcessEvent(event) if event.id == EVENT_MENUEVENT then if event.source == editor.mainwindow then if event.extra == MENU_FILEOPEN then event.id = EVENT_WINDOWCLOSE end end end return event end 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: function Script:Start() --Create our interface self.window = CreateWindow("Material Designer",0,0,800,600,editor.mainwindow,WINDOW_CENTER + WINDOW_TITLEBAR + WINDOW_RESIZABLE) end function Script:ProcessEvent(event) if event.id == EVENT_FILEOPEN --Check for material files being opened if ExtractExt(event.extra)=="mat" --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 self.window:Show() self.window:Activate() else Print("Error: Failed to load design file.") end --Discard the event return nil end end end return event end 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.

Josh

Josh

Website refresh and Leadwerks 5

Back around February I started working on a website update that included the following: Responsive design everywhere. SSL 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. Multithreaded Architecture 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. Shared Pointers 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. 64-bit The engine and editor will be released as a 64-bit build only. Game Templates More game templates will be provided.  Fortunately we can add these now and updates for Leadwerks 5 will be minimal. Open-Source Components 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. Platforms 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. Enterprise Edition A standalone version that does not use Steam will be sold in bundles to companies that require this. Pricing 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.

Josh

Josh

Leadwerks 3.1 Pre-orders Now Available, Indie Edition coming to Steam January 6th

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.)   Exemptions 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.

Josh

Josh

What Makes a Good Brand Name?

In evaluating possible company names I have come up with the following criteria which I used to choose a name for our new game engine. Spelling and Pronunciation
The name should be unambiguous in spelling. This helps promote word-of-mouth promotion because when someone hears the name for the first time, they can easily find it online. Similarly, the name when read should be unambiguous in pronunciation. This helps the name travel from written to spoken word and back. Can you imagine telling someone else the name of this...establishment...and having them successfully type the name into a web browser?: Shorter is Better
Everything else aside, fewer letters is generally better. Here is a very long company name: And here is perhaps the shortest software company name in history. Which do you think is better? The Name Should "Pop"
A good company or product name will use hard consonants like B, T, K, X, and avoid soft sounding letters like S and F. The way a name sounds can actually influence perception of the brand, aside from the name meaning. The name "Elysium", besides being hard to pronounce and spell, is full of soft consonants that sound weak. "Blade Runner", on the other hand, starts with a hard B sound and it just sounds good. Communicate Meaning
The name should communicate the nature of the product or company. The name "Uber" doesn't mean anything except "better", which is why the company Uber originally launched as UberCab. Once they got to a certain size it was okay to drop the "cab" suffix, but do you remember the first time you heard of them? You probably thought "what the heck is an Uber?" The Leadwerks Brand
So according to our criteria above, the name Leadwerks satisfies the following conditions: The name "pops" and sounds cool. It's not too long. But here's where it falls short: Ambiguity in spelling (Leadworks?) Ambiguity in pronunciation. Leadwerks is pronounced like Led Zeppelin, but many people read it as "Leed-works". The name doesn't mean anything, even if it sounds cool. It's just a made-up word. These are the reasons I started thinking about naming the new engine something different. New Engine, New Name
So with this in mind, I set out to find a new name for the new coming engine. I was stumped until I realized that there are only so many words in the English language, and any good name you come up will invariably have been used previously in some other context, hopefully in another industry or product type. Realizing this gave me more leeway, as I did not have to come up with something completely unique the world has never heard before. Our early benchmarks indicate the new engine is a performance monster, with incredible results I did not even dream were possible. Together with the rapid development pipeline of Leadwerks, I knew I wanted to focus on speed. Finally, there was one name I kept coming back to for weeks on end. I was able to obtain a suitable domain name. I am now filing a trademark for use of this name, which requires that I begin using it commercially, which is why I am now revealing the name for the first time...                             Keep scrolling.                               How does this name stack up?: Unambiguous spelling and pronunciation. It's short. The name "pops". It communicates the defining feature of the product. Now think about our goals for the new engine's name. Will people have any trouble remembering this name? Is there any ambiguity about what the product stands for, and the promise it makes? If two developers are at a Meetup group and one of them says "I made this with Turbo" is there any doubt what the promise of this product is, i.e. massive performance? The name even works on a subconscious level. Anyone having trouble with their game performance (in other slow engines that aren't Turbo) will naturally wonder how fast it could be running in ours. The fact that the name has a positive emotional response for many people and a strong connection to the game industry is a plus. Turbo Game Engine is an unambiguous brand name that takes a stand and makes a clear promise of one thing: speed, which is incredibly important in the days of VR and 240 hz screens.

Josh

Josh

Data Loss Announcement

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: http://leadwerks.com/werkspace/index.php?/topic/3098-screenshot-archive/page__pid__28584#entry28584   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.   -Josh

Admin

Admin

4.5 Beta Now Available

A beta build of version 4.5 is now available on the beta branch on Steam.  This updates the engine to the latest Newton 3.14.  Versions 4.5 and 5 beta are now compiling side-by-side with the same source code.  Because of major engine changes in version 5, some bugs may need to be resolved before the final release.  Some preliminary information on updating C++ projects can be found in this thread. Version 4.5 is planned to include official support for VR (both Vive and Oculus) and a new improved vehicle system.

Admin

Admin

Leadwerks 3 begins closed beta test

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.

Admin

Admin

Rewerking the Asset Class -or- Back that Asset Up

Since you guys are my boss, in a way, I wanted to report to you what I spent the last few days doing.   Early on in the development of Leadwerks 3, I had to figure out a way to handle the management of assets that are shared across many objects. Materials, textures, shaders, and a few other things can be used by many different objects, but they consume resources, so its important for the engine to clean them up when they are no longer needed.   I decided to implement an "Asset" and "AssetReference" class. The AssetReference object contains the actual data, and the Asset object is just a handle to the AssetReference. ("AssetBase" probably would have been a more appropriate name). Each AssetReference can have multiple instances (Assets). When a new Asset is created, the AssetReference's instance count is incremented. When an Asset is deleted, its AssetReference's instance counter is decremented. When the AssetReference instance counter reaches zero, the AssetReference object itself is deleted.   Each different kind of Asset had a class that extended each of these classes. For example, there was the Texture and TextureReference classes. The real OpenGL texture handle was stored in the TextureReference class.   Normal usage would involve deleting extra instances of the object, as follows: Material* material = Material::Create(); Texture* texture = Texture::Load("myimage.tex"); material->SetTexture(texture);// This will create a new instance of the texture delete texture;   This isn't a bad setup, but it creates a lot of extra classes. Remember, each of the AssetReference classes actually get extended for the graphics module, so we have the following classes: Asset Texture AssetReference TextureReference OpenGL2TextureReference OpenGLES2TextureReference   The "Texture" class is the only class the programmer (you) needs to see or deal with, though.   Anyways, this struck me as a bad design. Several months ago I decided I would redo this before the final release. I got rid of all the weird "Reference" classes and instead used reference counting built into the base Object class, from which these are all derived.   The usage for you, the end user, isn't drastically different:   Material* material = Material::Create(); Texture* texture = Texture::Load("myimage.tex"); material->SetTexture(texture); texture->Release();// Decrements the reference counter and deletes the object when it reaches zero   In the Material's destructor, it will actually decrement each of its texture objects, so they will automatically get cleaned up if they are no longer needed. In the example below, the texture will be deleted from memory at the end of the code: Material* material = Material::Create(); Texture* texture = Texture::Load("myimage.tex"); material->SetTexture(texture); texture->Release(); material->Release();// texture's ref count will be decremented to zero and it will be deleted   If you want to make an extra "instance" (not really) of the Asset, just increment the reference counter:   Material* material = Material::Create(); Texture* texture = Texture::Load("myimage.tex"); texture->IncRefCount();// increments ref count from 1 to 2 Texture* tex2 = texture; texture->Release();// decrements ref count from 2 to 1   This makes the code smaller, gets rid of a lot of classes, and I think it will be easier to explain to game studios when I am trying to sell them a source code license.   Naturally any time you make systemic changes to the engine there will be some bugs here and there, but I have the engine and editor running, and mistakes are easy to find when I debug the static library.   I also learned that operation overloading doesn't work with pointers, which i did not know, but had never had a need to try before. Originally, I was going to use operation overloads for the inc/dec ref count commands: Texture* tex = Texture::Create();//refcount=1 tex++;//refcount=2 tex--;//refcount=1 tex--;// texture would get deleted here   But that just messes with the pointer! So don't do things like that.

Josh

Josh

Five Programming Changes You'll See in Leadwerks 5

Leadwerks 4.x will see a few more releases, each remaining backwards compatible with previous versions.  Leadwerks 5.0 is the point where we will introduce changes that break compatibility with previous versions.  The changes will support a faster design that relies more on multi-threading, updates to take advantage of C++11 features, and better support for non-English speaking users worldwide.  Changes are limited to code; all asset files including models, maps, shaders, textures, and materials will continue to be backwards-compatible. Let's take a look at some of the new stuff. Shared Pointers
C++11 shared pointers eliminate the need for manual reference counting.  Using the auto keyword will make it easier to update Leadwerks 4 code when version 5 arrives.  You can read more about the use of shared pointers in Leadwerks 5 here. Unicode Support
To support the entire world's languages, Leadwerks 5 will make use of Unicode everywhere.  All std::string variables will be replaced by std::wstring.  Lua will be updated to the latest version 5.3.  This is not compatible with LuaJIT, but the main developer has left the LuaJIT project and it is time to move on.  Script execution time is not a bottleneck, Leadwerks 5 gains a much longer window of time for your game code to run, and I don't recommend people build complex VR games in Lua.  So I think it is time to update. Elimination of Bound Globals
To assist with multithreaded programming, I am leaning towards a stateless design with all commands like World::GetCurrent() removed.  An entity needs to be explicitly told which world it belongs to upon creation, or it must be created as a child of another entity: auto entity = Pivot::Create(world); I am considering encapsulating all global variables into a GameEngine object: class GameEngine { public: std::map<std::string, std::weak_ptr<Asset> > loadedassets; shared_ptr<GraphicsEngine> graphicsengine; shared_ptr<PhysicsEngine> physicsengine; shared_ptr<NetworkEngine> networkengine; shared_ptr<SoundEngine> soundengine; shared_ptr<ScriptEngine> scriptengine;//replaces Interpreter class }; A world would need the GameEngine object supplied upon creation: auto gameengine = GameEngine::Create(); auto world = World::Create(gameengine); When the GameEngine object goes out of scope, the entire game gets cleaned up and everything is deleted, leaving nothing in memory. New SurfaceBuilder Class
To improve efficiency in Leadwerks 5, surfaces will no longer be stored in system memory, and surfaces cannot be modified once they are created.  If you need a modifiable surface, you can create a SurfaceBuilder object. auto builder = SurfaceBuilder::Create(gameengine); builder->AddVertex(0,0,0); builder->AddVertex(0,0,1); builder->AddVertex(0,1,1); builder->AddTriangle(0,1,2); auto surface = model->AddSurface(builder); When a model is first loaded, before it is sent to the rendering thread for drawing, you can access the builder object that is loaded for each surface: auto model = Model::Load("Models\box.mdl", Asset::Unique); for (int i=0; i<model->CountSurfaces(); ++i) { auto surface = model->GetSurface(i); shared_ptr<SurfaceBuilder> builder = surface->GetBuilder(); if (builder != nullptr) { for (int v=0; v < surface->builder->CountVertices(); ++v) { Vec3 v = builder->GetVertexPosition(v); } } } 98% of the time there is no reason to keep vertex and triangle data in system memory.  For special cases, the SurfaceBuilder class does the job, and includes functions that were previously found in the Surface class like UpdateNormals().  This will prevent surfaces from being modified by the user when they are in use in the rendering thread. A TextureBuilder class will be used internally when loading textures and will operate in a similar manner.  Pixel data will be retained in system memory until the first render.  These classes have the effect of keeping all OpenGL (or other graphics API) code contained inside the rendering thread, which leads to our next new feature... Asynchronous Loading
Because surfaces and textures defer all GPU calls to the rendering thread, there is no reason we can't safely load these assets on another thread.  The LoadASync function will simply return true or false depending on whether the file was able to be opened: bool result = Model::LoadASync("Models\box.mdl"); The result of the load will be given in an event: while (gameengine->eventqueue->Peek()) { auto event = gameengine->eventqueue->Wait(); if (event.id == Event::AsyncLoadResult) { if (event.extra->GetClass() == Object::ModelClass) { auto model = static_cast<Model>(event.source.get()); } } } Thank goodness for shared pointers, or this would be very difficult to keep track of! Asynchronous loading of maps is a little more complicated, but with proper encapsulation I think we can do it.  The script interpreter will get a mutex that is locked whenever a Lua script executes so scripts can be run from separate threads: gameengine->scriptengine->execmutex->Lock(); //Do Lua stuff gameengine->scriptengine->execmutex->Unlock(); This allows you to easily do things like make an animated loading screen.  The code for this would look something like below: Map::LoadASync("Maps/start.map", world); while (true) { while (EventQueue::Peek()) { auto event = EventQueue::Wait(); if (event.id == Event::AsyncLoadResult) { break; } } loadsprite->Turn(0,0,1); world->Render();// Context::Sync() might be done automatically here, not sure yet... } All of this will look pretty familiar to you, but with the features of C++11 and the new design of Leadwerks 5 it opens up a lot of exciting possibilities.

Josh

Josh

Leadwerks Levels Up

Leadwerks has been accepted into the Sacramento State University Center for Entrepreneurship. The mission of the Center for Entrepreneurship in the College of Business Administration (CBA) is to develop and nurture innovative business ideas and to capitalize potential entrepreneurial opportunities, both from CSUS and local entrepreneurship communities.   The Center will provide entrepreneurs with the skills and resources needed to launch a venture and to identify and cultivate solutions to entrepreneurial problems, the network structure to bring the plan to fruition, and the technical training to grow the enterprises.   This means Leadwerks now has a physical office right here in California and a vital link to the local technology and business communities as we complete the last leg of Leadwerks3D, our upcoming game development software for iPhone, iPad, Android, Windows, and Mac.

Admin

Admin

Leadwerks 3 Update Available

This update brings the addition of lightmapping across curved surfaces with smooth groups. The image below is a set of lightmapped CSG brushes, not mesh lighting. You can read a detailed account of our implementation of this feature here.     The project manager now includes an "Update" button, so you can easily update your project any time we modify files in the template folders. Although we tested with no problems, it is recommended you back up your project before using this feature. The editor will make a copy of any overwritten files, as an added precaution.     You've now got full control over all the features and settings in the Leadwerks editor, through the new Options dialog. This gives you control over various program behaviors and settings. You can toggle grid snapping, control the snap angle, and lots of other stuff.     We have made one change to the script system. Our multiple script design worked reasonably well during the development of Darkness Awaits. The flowgraph interactions were clean, but when it came to AI and player interaction, things got messy. For example, when the player pushes a button we perform a raycast or proximity test to get the entity hit. Then we have to go through all the scripts attached to the entity, looking for a relevant script attached to it: --Check if GoblinAI component is present if entity.script.GoblinAI~=nil then   --Call the TakeDamage() function entity.script.GoblinAI:TakeDamage(10)   end   That works okay in our example, but when we consider other enemies we want to add, suddenly it gets ugly. We have a few choices. Add an if statement for every new AI script, checking to see if it is present.
 
Separate the health value out into its own script.
 
Loop through all attached scripts looking for a TakeDamage() function.
  It should be obvious why option #1 is a bad idea. This would make our code highly interdependent. Encapsulation is one of our goals in game scripting, so we can achieve drag and drop functionality (or as close to that as is reasonably achievable without limiting ourselves).   The second option would solve our immediate problem, but this approach means that every single script variable two scripts access has to be a separate script. The thought of this just shuts my creativity down. I already think it's tedious to have to attach an AI and AnimationManager script to an entity, and can't imagine working with even more pieces.   The third option is the most reasonable, but it greatly impedes our coding freedom. It means every time two entities interact, you would have to do something like this: --Check if GoblinAI component is present if entity.components~=nil then   for local k,v in entity.components do   if type(v.TakeDamage)=="function" do   --Call the TakeDamage() function v:TakeDamage(10) end end end   If you actually wanted to return a value, you would just have to get the first value and exit the loop: local enemyhealth=0   --Check if components table is present if entity.components~=nil then   --Iterate through all attached components for local k,v in entity.components do   if type(v.GetHealth)=="function" do   --Call the GetHealth() function enemyhealth = v:GetHealth() break end end end   This is a major problem, because it means there is no firm "health" value for an entity. Sure, we could consider it a "HealthManager.health" value but therein lies the issue. Instead of having plug-and-play scripts everyone can share, we have to devise a system of expected script names and variables. This breaks compartmentalization, which is what we were going for in the first place. Both Chris and I realized this approach was fundamentally wrong.   After careful consideration, and based on our experience working on Darkness Awaits, we have restructured the system to work as follows, with a 1:1 entity:script relationship: --Check if script is present if entity.script~=nil then   if type(entity.script.TakeDamage)=="function" do   --Call the TakeDamage() function entity.script.TakeDamage(10) end end   You can set an entity's script with the new function: Entity::SetScript(const std::string& path)   You can also set and get entity script values right from C++: virtual void SetString(const std::string& name, const std::string& s); virtual void SetObject(const std::string& name, Object* o); virtual void SetFloat(const std::string& name, const float f);   And it's easy to call a script function from your C++ code: virtual bool CallFunction(const std::string& name, Object* extra=NULL);   The properties dialog is changed slightly, with a consistent script tab that always stays visible. Here you can set the script, and properties will appear below, instead of being spread across a bunch of different tabs:   Maps with entities using only one script (which has been almost everything we see) are unaffected. Objects with multiple scripts need to have their code combined into one, or split across multiple entities. I am very reluctant to make changes to the way our system works. Our API has been very stable since day one of release, and I know it's important for people to have a solid foundation to build on. However, I also knew we made a design mistake, and it was better to correct it sooner rather than later.   Probably the best aspect of the script system in Leadwerks 3 has been the flowgraph connections between scripted objects. That's been a big winner:     As we use the editor more and hear about the community's experience, it allows us to refine our tools more. One of the more subtle but we made is in the properties editor. One of the annoyances I experienced was when setting a property like mass or position when an entire hierarchy of entities was selected. Obviously I didn't want to set the mass for every single bone in a character, but how to tell the editor that? I went through all the properties, and for ones that the user is unlikely to want set, I made the following rule: If the entity has a selected parent anywhere in the hierarchy, it gets ignored when properties are retrieved and applied. (Other things like color will still work uniformily.) Just try it, and you'll see. It speeds up editing dramatically.   In a similar vein, we finally solved the problem of "too many selection widgets", We only display the top-most control widget for each group of selected objects. Again, it's easier for you to just try it and see than for me to explain in detail. If we did our job right, you might not even notice because the editor will just do what you want without any thought.   You've also got control over the color scheme, and can use it to customize the look and feel of the 3D viewports and code editor.     On Windows we fixed an annoyance that triggered menu shortcuts when the user tried to copy and paste in text fields. This tended to happen in the properties editor. We're working to resolve the same issue in the Cocoa UI for Mac.   I'm a big fan of the 3ds max Max Script system, so in the output panel we've added a real-time Lua console:   You can type Lua commands in and interact with Leadwerks in real-time. Just for fun, try pasting in this line of code and see what happens: for i=0,10 do a = Model:Box(); a:SetColor(math.random(0,1),math.random(0,1),math.random(0,1)); a:SetPosition(i*2,0,0); end   You can't create objects the editor will recognize (yet), but it's fun to play with and should give you an idea of where we're going with the editor.   This is an important update that includes new features and enhancements that improve usability and workflow. Thank you for your feedback. It's great to see all the activity that is taking place as people learn Leadwerks 3.

Josh

Josh

Version 4.4 beta updated

An update for version 4.4 beta is now available. The Newton Dynamics library has been updated to the current version. Vehicles are temporarily unavailable, but everything else should work. The Newton DLLs have been moved into external DLLs, which allows the author of Newton to debug his own physics code in Leadwerks from Visual Studio.   You can get the update by opting into the beta branch on Steam.

Admin

Admin

Introducing Leadwerks Marketplace

Steam Workshop was a compelling idea to allow game asset authors to sell their items for use with Leadwerks Game Engine. However, the system has turned out to have some fundamental problems, despite my best efforts to work around it. Free items are not curated, causing the store to fill with low quality content. Some people have reported trouble downloading items. The publishing process is pretty tedious. The check-out process requires adding funds to Steam Wallet, and is just not very streamlined. At the same time, three new technologies have emerged that make it possible to deliver a better customer and seller experience through our website. Amazon S3 offers cheap and reliable storage of massive amounts of data. Paypal credit card tokens allow us to safely store a token on our server that can't be used anywhere else, instead of a credit card number. This eliminates the danger of a potential website hack revealing your information. Invision Power Board has integrated both these technologies into our commerce system. it would not have been possible to build a web store a few years ago because the cost of server space would have been prohibitive, and storing hundreds of gigs of data would have made my website backup process unsustainable. So at the time, the unlimited storage of Steam and their payment processing system was very appealing. That is no longer the case. To solve the problems of Steam Workshop, and give you easy access to a large library of ready-to-use game assets, I am happy to introduce Leadwerks Marketplace. The main page shows featured assets, new content, and the most popular items, with big thumbnails everywhere.   When you view an item, screenshots, videos, and detailed technical specifications are shown: How does Leadwerks Marketplace improve things?: Easy download of zip files that are ready to use with Leadwerks. You can use File > Import menu item to extract them to the current project, or just unzip them yourself. All content is curated. Items are checked for compatibility and quality. Clear technical specifications for every file, so you know exactly what you are getting. Cheap and reliable storage forever with Amazon S3. Any DLCs or Workshop Store items you purchased can be downloaded from Leadwerks Marketplace by linking your Steam account to your profile. Easy publishing of your items with our web-based uploader. We're launching with over 50 gigabytes of game assets, and more will be added continuously. To kick off the launch we're offering some items at major discounts during the Summer Game Tournament. Here are a few assets to check out: Get "The Zone" for just $4.99: Or download our Mercenary character for free! Just create your free Leadwerks account to gain access. Other items will be featured on sale during the Summer Game Tournament: After purchasing an item, you can download it immediately. All your purchased items will be shown in the Purchases area, which you can access from the user menu in the top-right of this the website header: Here all your purchased items will be available to download, forever: If you are interested in selling your game assets to over 20,000 developers, you can upload your items now. Sellers receive a 70% royalty for each sale, with a minimum payout of just $20. See the content guidelines for details and contact me if you need any help. If you have a lot of good content, we can even convert your assets for you and make them game-ready for Leadwerks, so there's really no risk to you. Browse game assets now.  

Admin

Admin

Virtual Texture Terrain

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.

Josh

Josh

Leadwerks Engine 2.43 Released

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.

Admin

Admin

Building Multiplayer Games with Leadwerks

A new easy-to-use networking system is coming soon to Leadwerks Game Engine.  Built on the Enet library, Leadwerks networking provides a fast and easy way to quickly set up multiplayer games.  Each computer in the game is either a server or a client.  The server hosts the game and clients can join and leave the game at will.  On the other hand, when the server leaves the game, the game is over! Creating a Client You can soon create a client with one command in Leadwerks: client = Client:Create() To connect to a server, you need to know the IP address of that computer: client:Connect("63.451.789.3") To get information from the other computer, we simply update the client and retrieve a message: local message = client:Update() if message.id == Message.Connected then print("Connected to server") elseif message.id == Message.Disconnected then print("Disconnected from server") elseif message.id == Message.Chat then print("New chat message: "..message.stream:ReadString()); end You can even send messages, consisting of a simple message ID, a string, or a stream. client:Send(Message.Chat,"Hello, how are you today?") There are two optional flags you can use to control the way your messages are sent.  If you specify Message.Ordered, your packets will arrive in the order they were sent (they won't necessarily otherwise).  You can use this for updating the position of an object, so that the most recent information is always used.  The Message.Reliable flag should be used for important messages that you don't want to miss.  UDP packets are not guaranteed to ever arrive at their destination, but messages sent with this flag are.  Just don't use it for everything, since it is slower! When we're ready to leave the game, we can do that just as easily: client:Disconnect() A dedicated server does not have anyone playing the game.  The whole computer is used only for processing physics and sending and receiving information.  You can create a dedicated server, but it's better to let your players host their own games.  That way there's always a game to join, and you don't have to buy an extra computer and keep it running all the time. Creating a Server Your game should be able to run both as a client and as a server, so any player can host or join a game.  Creating the game server is just as easy. local server = Server:Create(port) Once the server is created, you can look up your IP address and ask a friend to join your game.  They would then type the IP address into their game and join. The server can send and receive messages, too.  Because the server can be connected to multiple clients, it must specify which client to send the message to.  Fortunately, the Message structure contains the Peer we received a message from.  A peer just means "someone else's computer".  If your computer is the client, the server you connect to is a peer.  If your computer is the server, all the other clients are peers: local message = client:Update() if message.id == Message.Connected then player2 = message.peer end You can use the peer object to send a message back to that computer: server:Send(peer, Message.Chat, "I am doing just great! Thanks for asking.") If you want to boot a player out of your game, that's easy too: server:Disconnect(peer) The broadcast command can be used to send the same message out to all clients: server:Broadcast(Message.Chat, "I hope you are all having a great time in my cool chat program!") Public Games You can make your game public, allowing anyone else in the world who has the game to play with you.  You specify a name for your game, a description of your server, and call this command to send a message to the Leadwerks server: server:Publish("SuperChat","My SuperChat Server of Fun") All client machines, anywhere in the world, can retrieve a list of public games and choose one to join: for n=0,client:CountServers("SuperChat")-1 do local remotegame = client:GetServer(n) print(remotegame.address) print(remotegame.description) end This is a lot easier than trying to type in one person's IP address.  For added control, you can even host a games database on your own server, and redirect your game to get information from there.

Josh

Josh

Leadwerks Software to Provide VR Services to NASA

TLDR: I made a long-term bet on VR and it's paying off. I haven't been able to talk much about the details until now. Here's what happened: Leadwerks 3.0 was released during GDC 2013. I gave a talk on graphics optimization and also had a booth at the expo. Something else significant happened that week.  After the expo closed I walked over to the Oculus booth and they let me try out the first Rift prototype. This was a pivotal time both for us and for the entire game industry. Mobile was on the downswing but there were new technologies emerging that I wanted to take advantage of. Our Kickstarter campaign for Linux support was very successful, reaching over 200% of its goal. This coincided with a successful Greenlight campaign to bring Leadwerks Game Engine to Steam in the newly-launched software section. The following month Valve announced the development of SteamOS, a Linux-based operating system for the Steam Machine game consoles. Because of our work in Linux and our placement in Steam, I was fortunate enough to be in close contact with much of the staff at Valve Software. The Early Days of VR It was during one of my visits to Valve HQ that I was able to try out a prototype of the technology that would go on to become the HTC Vive. In September of 2014 I bought an Oculus Rift DK2 and first started working with VR in Leadwerks. So VR has been something I have worked on in the background for a long time, but I was looking for the right opportunity to really put it to work. In 2016 I felt it was time for a technology refresh, so I wrote a blog about the general direction I wanted to take Leadwerks in. A lot of it centered around VR and performance. I didn't really know exactly how things would work out, but I knew I wanted to do a lot of work with VR. A month later I received a message on this forum that went something like this (as I recall): I thought "Okay, some stupid teenager, where is my ban button?", but when I started getting emails with nasa.gov return addresses I took notice. Now, Leadwerks Software has a long history of use in the defense and simulation industries, with orders for software from Northrop Grumman, Lockheed Martin, the British Royal Navy, and probably some others I don't know about. So NASA making an inquiry about software isn't too strange. What was strange was that they were very interested in meeting in person. Mr. Josh Goes to Washington I took my first trip to Goddard Space Center in January 2017 where I got a tour of the facility. I saw robots, giant satellites, rockets, and some crazy laser rooms that looked like a Half-Life level. It was my eleven year old self's dream come true. I was also shown some of the virtual reality work they are using Leadwerks Game Engine for. Basically, they were taking high-poly engineering models from CAD software and putting them into a real-time visualization in VR. There are some good reasons for this. VR gives you a stereoscopic view of objects that is far superior to a flat 2D screen. This makes a huge difference when you are viewing complex mechanical objects and planning robotic movements. You just can't see things on a flat screen the same way you can see them in VR. It's like the difference between looking at a photograph of an object versus holding it in your hands.
What is even going on here??? CAD models are procedural, meaning they have a precise mathematical formula that describes their shape. In order to render them in real-time, they have to be converted to polygonal models, but these objects can be tens of millions of polygons, with details down to threading on individual screws, and they were trying to view them in VR at 90 frames per second! Now with virtual reality, if there is a discrepancy between what your visual system and your vestibular system perceives, you will get sick to your stomach. That's why it's critical to maintain a steady 90 Hz frame rate. The engineers at NASA told me they first tried to use Unity3D but it was too slow, which is why they came to me. Leadwerks was giving them better performance, but it still was not fast enough for what they wanted to do next. I thought "these guys are crazy, it cannot be done". Then I remembered something else people said could never be done. So I started to think "if it were possible, how would I do it?" They had also expressed interest in an inverse kinematics simulation, so I put together this robotic arm control demo in a few days, just to show what could be easily be done with our physics system.   Turbo Game Engine is Born With the extreme performance demands of VR and my experience writing optimized rendering systems, I saw an opportunity to focus our development on something people can't live without: speed. I started building a new renderer designed specifically around the way modern PC hardware works. At first I expected to see performance increases of 2-3x. Instead what we are seeing are 10-40x performance increases under heavy loads. Once I saw this I was very encouraged, so I decided to name the new engine "Turbo Game Engine" (the point is absolutely unmissable) and bought the domain name turboengine.com. During this time I stayed in contact with people at NASA and kept them up to date on the capabilities of the new technology. At this point there was still nothing concrete to show for my efforts. NASA purchased some licenses for the Enterprise edition of Leadwerks Game Engine, but the demos I made were free of charge and I was paying my own travel expenses. The cost of plane tickets and hotels adds up quickly, and there was no guarantee any of this would work out. I did not want to talk about what I was doing on this site because it would be embarrassing if I made a lot of big plans and nothing came of it. But I saw a need for the technology I created and I figured something would work out, so I kept working away at it. Call to Duty Today I am pleased to announce I have signed a contract to put our virtual reality expertise to work for NASA. As we speak, I am preparing to travel to Washington D.C. to begin the project. In the future I plan to provide services for aerospace, defense, manufacturing, and serious games, using our new technology to deliver VR simulations with performance and realism beyond anything that has been possible until now. My software company and relationship with my customers (you) is unaffected. Development of the new engine will continue, with a strong emphasis on hyper-realism and performance. I think this is a direction everyone here will be happy with. I am going to continue to invest in the development of groundbreaking new features that will help in the aerospace and defense industries (now you understand why I have been talking about 64-bit worlds) and I think a great many people will be happy to come along for the ride in this direction. Leadwerks is still a game company, but our core focus is on enabling and creating hyper-realistic VR simulations. Thank you for your support and all the suggestions and ideas you have provided over the years that have helped me create great software for you. Things are about to get very interesting. I can't wait to see what you all create with the new technology we are building.

Josh

Josh

Leadwerks Game Engine 4.5 Released, Enables Easy VR Development

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. Other Improvements 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.

Admin

Admin

Leadwerks for Linux

Last week we launched our Steam Greenlight campaign to get Leadwerks into the hands of the Steam community. This week, we're rolling out the second stage of our plan with a Kickstarter campaign to bring Leadwerks to Linux. This will let you build and play games, without ever leaving Linux. The result of this campaign will be Leadwerks 3.1 with a high-end AAA renderer running on Linux, Mac, and Windows, with an estimated release date before Christmas.   Valve has given Linux users a taste of PC gaming, so now it's up to us to reach the Linux community with our message. If you dig this, please help spread the word that someone is trying to put game development on Linux: http://www.kickstarter.com/projects/1937035674/leadwerks-build-linux-games-on-linux     Leadwerks for Linux Linux is a solid and secure operating system that’s perfect for gaming, but at this time Windows remains the lead platform for PC games. We want to change that by putting the game development process right on Linux, with Leadwerks for Linux. This will allow you to build and play games without ever leaving the Linux operating system.   Leadwerks is a visual tool for building any kind of 3D game, including dungeon crawlers, first-person shooters, and side-scrollers.. We want to put game development on Linux with Leadwerks for Linux. Our campaign has three goals:   Linux Game Development. On Linux. It’s not enough just to export games to Linux. We want to put the game development process on Linux, so you can build and play games, without ever leaving the Linux operating system. We have a complete visual editor that handles all aspects of the game development process, and we’re porting it to run natively on Linux. We’re using GTK for the user interface, so our editor will look and feel like a native Linux application.   We're targeting Ubuntu 12.04 to start with, and will support other distros as we make progress. You'll also be able to compile games for Windows and Mac...if you feel like sharing.     Expand the Linux Library of Games Our second goal is to facilitate expansion of the Linux library of games, and encourage the production of Linux-exclusive titles. The Linux community is pretty intelligent, and they have a lot of good programmers. We think by putting the appropriate tools in their hands, it will enable them to make great Linux games.   Hoodwink by E-One Studio   AAA Graphics on Linux Leadwerks is known for having great graphics. We want to push Linux graphics beyond anything that’s ever been done. Linux is the perfect platform for triple-A graphics, because it has OpenGL performance faster than Windows or Mac. We’re taking advantage of this performance with deferred lighting, hardware tessellation, and up to 32x multisample antialiasing.   The Zone by Dave Lee   Steam Integration When Valve announced Steam was coming to Linux, that was a clear sign to us that Linux is ready for PC gaming. We’re working to integrate Leadwerks with Steam and take advantage of new features Steam offers for developers.     Steam Workshop We’re hooking into the Steam Workshop to deliver game assets. This includes models, textures, scripts, and maps, so you can get everything you need to make games. When you find an object in the Steam Workshop you want to use in your game, just hit the “Subscribe” button and it will show up right away, ready to use in Leadwerks. We’re also adding support for Valve’s asset formats, so you can access lots of great content from the rest of the Steam Workshop, and add it to your game.   Export for Steam We’re working with the Steam SDK to make it easier to submit Linux games to Greenlight. Just press a button, and your game files will be packaged up, ready to send to Steam.[/color]   Features Leadwerks is a powerful yet easy to use game engine with thousands of users worldwide. Here are just a few of the main reasons we think Linux users will love Leadwerks.   C++ Programming Programming with Leadwerks is a breeze. Underneath our visual editor lies a powerful yet easy to use programming API that can be accessed in C++, Lua, and other languages. With documentation and examples for every single command, you’ve got everything you need to make any kind of game.   Visual Scripting For scripting, we use the Lua script language, just like in Crysis, World of Warcraft, and hundreds of other games. We’ve got a built-in script editor, so you don’t have to switch back and forth between Leadwerks and an external editor. It’s even got a built-in debugger so you can step through your script and see everything that’s going on in the game. The flowgraph editor is used to connect scripted objects and make gameplay happen. This lets map designers set up sequences of events and complex gameplay, with no programming required.   Constructive Solid Geometry Finally, we use a level editor based on constructive solid geometry. This lets everyone make game levels, without having to be an expert. If you’re familiar with Valve’s Hammer Editor, you’ll feel right at home in Leadwerks.   Combat Helo by Tricubic Studios   We plan to deliver a visual editor that handles every aspect of the game development process, a powerful yet easy to use programming API, with triple-A graphics, all running natively in Linux. By working with Steam and the Linux community, our goal is to make Linux the number one platform for PC gaming. Thank you for helping us take Linux gaming to the next level.   Big Five Game Hunter by Unidev   Risks and challenges We expect to encounter some graphics driver bugs. This is always the case when you are pushing advanced graphics. Fortunately, we have good relationships with the major graphics hardware vendors, and have been able to get driver bugs fixed on other platforms in the past. Valve Software has done some of the heavy lifting for us here, by prompting the graphics hardware vendors to get their drivers in good shape.   Our GUI has a GTK implementation for Linux, but we expect to encounter some problems that have to be overcome. Our GTK Scintilla implementation (for the code editor) has not been written, and it's a complex library.   Since the Linux file system is case-sensitive, we expect to have to modify some code to work properly on Linux.   We're implementing a new method for terrain layers using virtual texturing. We do not anticipate any problems here, but it is one of the few features we haven't fully prototyped.   Although building Leadwerks for Linux will undoubtedly present some difficult problems, our team has a lot of experience with multi-platform development and I'm confident we can deal with all issues we encounter.

Josh

Josh

Leadwerks Standard Edition Brings C++ Game Development to Steam

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.

Admin

Admin

Leadwerks Summer Games Tournament 2016

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!

Admin

Admin

Leadwerks Winter Games Tournament Kicks Off

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!

Admin

Admin

Leadwerks Winter Games Tournament 2016

At last, it is time for the 2016 Leadwerks Winter Games Tournament! This is going to be a big one, for a few reasons. We're very likely to reach 100 games in Leadwerks Game Launcher, which means it will be ready to move out of early access mode and be an official release on Steam.
As an experiment, you're getting two extra weeks to polish your games, with an extended deadline lasting until January 15th.
    WHEN: The tournament begins Monday, December 5, and ends Sunday, January 15th at 11:59 P.M.   HOW TO PARTICIPATE: Publish your wintery-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 Christmas props 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 the new Leadwerks USB stick, which is perfect for storing projects, code and artwork! The items will be printed with the Leadwerks logo for a distinctive look.     If this is your fourth 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 fifth 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 sixth 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 Everyone who participates also gets this bonus prize: an 11x17" poster mailed to your door! These posters will be printed only once, only for this event. This is your only time ever to get one, so make it count!

Admin

Admin

Game Tournaments, Schwag, and American Apparel

I have proven beyond a shadow of a doubt that I am very bad at shipping posters.  The Winter Game Tournament was completed in January and I have yet to deliver your prizes.  If you have a job opening for someone to ship prizes, or to ship anything at all, I am probably the worst candidate you could ever hope to find to fill said position.  Seriously. Part of the problem (although it's still not an excuse) has been that it is actually incredibly difficult to have custom USB keychains made.  These took a long time because my description of black monochrome printing with the text vertical aligned was too apparently too complicated. The first proof I got used a beautiful white-on-silver-so-light-it's-practically-white color scheme. The second attempt's failure was slightly more subtle.  Slightly.  Is it just me, or does the logo obviously beg to be centered by the vertical center of the text, instead of the image dimensions?  Is this really that hard?: At this point I was all like: So I drew them a picture of something that to me seemed extremely obvious.  Finally, I got the corrected proof of our glorious USB keychain and have authorized a limited production of this one-of-a-kind item.  I will give props to the graphics designer for choosing the dark gray (subtle blue?) print color, which is much better than #000000: All I wanted was a little taste in design. So here's what I am going to do.  Each entrant in the Winter Games Tournament will receive one limited-edition poster, with one limited-edition Leadwerks USB keychain inside the poster tube, plus one Leadwerks sticker (which I have a ton of).  Because of the delay and the fact that I suck at shipping prizes, I am bumping up the 4GB USB drive to a whopping 16GB.  That's four times the jigglebytes, and enough to back up the entire Leadwerks.com website on. In other news, the acquisition of American Apparel by Gilden Activewear has actually affected our supply chain for the fabulous Leadwerks line of clothing.  The official Leadwerks hoodie in our signature gray color is currently only available in sizes small and extra small. I contacted SpreadShirt.com about the matter and received the following explanation: The first and most pertinent question is why is the little mermaid working in customer service for SpreadShirt? The second question is when will the official Leadwerks hoodie become available again?  The garment can be gotten in other colors, but I do not feel that any of these less appealing colors adequately represent the brand of our game engine.  This is most distressing and I will continue to look for a solution. The 2017 Summer Game Tournament will proceed once I have shipped the prizes out from the previous tournament.  However, as I have proven that I am not a reliable shipper of prizes, the tournament is going back to our original prizeless model.  A roundup of entries from all game developers will be posted at the end and fun will be had by all.

Josh

Josh

×