Jump to content

Leadwerks Standard Edition Brings C++ Game Development to Steam

Admin

6,457 views

blog-0972282001396890676.jpgFollowing 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.



16 Comments


Recommended Comments

I don't understand, what's the difference between this version and the standard version here on this site which cost $199. Does the steam standard edition can be used only to create games that works on steam? And does the steam standard version also include Lua like the one here on this site?

Share this comment


Link to comment

They are the same, but I think the Steam one will have the Workshop integrated into it.

Share this comment


Link to comment

Leadwerks on Steam has additional features like screenshot and video publishing, Workshop integration (in progress), and other features that may be added in the future. Games made with the Steam version can still be published anywhere you want, not just to Steam.

Share this comment


Link to comment

I still don't understand, why would anyone buy the one on the site for $199 and they could get it for $99 on steam also why would someone buy the inde version on steam for same price as the standard version on steam if the standard one had more features. Please I need a good explanation because the description does not give enough information about the versions . thanks

Share this comment


Link to comment

I still don't understand, why would anyone buy the one on the site for $199 and they could get it for $99 on steam also why would someone buy the inde version on steam for same price as the standard version on steam if the standard one had more features. Please I need a good explanation because the description does not give enough information about the versions . thanks

Well, technically it's $1 cheaper if you get indie + standard DLC on Steam. But some people prefer a standalone version.

Share this comment


Link to comment

@Oxford: Please read a little more carefully on the store page what the difference is between indie and standard edition. Indie costs 99 and standard cost 199. indie + upgrade to standard costs 198

Share this comment


Link to comment

@Oxford: The indie version is Lua only. The standard version is C++ AND Lua. So the standard on this site is $199. The standard on steam is $199. Indie on steam is $99. Standard DLC for indie is $99. It's all the same price.

Share this comment


Link to comment

Yes I understand now, the standard on steam is just an addon to the inde version on steam to make it like the one in the site. But you say that in steam description that its an addon so people don't just buy the standard one and get shocked that they need the inde one too for it to work.

Share this comment


Link to comment

Yes I understand now, the standard on steam is just an addon to the inde version on steam to make it like the one in the site. But you say that in steam description that its an addon so people don't just buy the standard one and get shocked that they need the inde one too for it to work.

It's not possible to buy the DLC without owning the base product. :)

Share this comment


Link to comment

It is this Steam Standard the version 3.1 of Leadwerks?, Im confused because it said OpenGL 4.0 support but that is Leadwerks 3.1?.

 

If thats the case how can I get this version without steam?. Or I have to continue using version 3.0 until 3.1 is ready on here?. also when 3.1, I pre ordered on March 2014.

Share this comment


Link to comment

It's not possible to buy the DLC without owning the base product. smile.png

 

As a buyer of the "pre-order", which includes both Indie and Standard edition, wonder why this last one is not already included in my Steam account (as DLC). To have both versions in Steam does not think it necessary to shell out another $ 100 for a version that is already included in my previous purchase. Correct me if I'm wrong, Josh.

Share this comment


Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 2
      I started to implement quads for tessellation, and at that point the shader system reached the point of being unmanageable. Rendering an object to a shadow map and to a color buffer are two different processes that require two different shaders. Turbo introduces an early Z-pass which can use another shader, and if variance shadow maps are not in use this can be a different shader from the shadow shader. Rendering with tessellation requires another set of shaders, with one different set for each primitive type (isolines, triangles, and quads). And then each one of these needs a masked and opaque option, if alpha discard is enabled.
      All in all, there are currently 48 different shaders a material could use based on what is currently being drawn. This is unmanageable.
      To handle this I am introducing the concept of a "shader family". This is a JSON file that lists all possible permutations of a shader. Instead of setting lots of different shaders in a material, you just set the shader family one:
      shaderFamily: "PBR.json" Or in code:
      material->SetShaderFamily(LoadShaderFamily("PBR.json")); The shader family file is a big JSON structure that contains all the different shader modules for each different rendering configuration: Here are the partial contents of my PBR.json file:
      { "turboShaderFamily" : { "OPAQUE": { "default": { "base": { "vertex": "Shaders/PBR.vert.spv", "fragment": "Shaders/PBR.frag.spv" }, "depthPass": { "vertex": "Shaders/Depthpass.vert.spv" }, "shadow": { "vertex": "Shaders/Shadow.vert.spv" } }, "isolines": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Isolines.tesc.spv", "tessellationEvaluation": "Shaders/Isolines.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Isolines.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Isolines.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Isolines.tesc.spv", "tessellationEvaluation": "DepthPass_Isolines.tese.spv" } }, "triangles": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Triangles.tesc.spv", "tessellationEvaluation": "Shaders/Triangles.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Triangles.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Triangles.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Triangles.tesc.spv", "tessellationEvaluation": "DepthPass_Triangles.tese.spv" } }, "quads": { "base": { "vertex": "Shaders/PBR_Tess.vert.spv", "tessellationControl": "Shaders/Quads.tesc.spv", "tessellationEvaluation": "Shaders/Quads.tese.spv", "fragment": "Shaders/PBR_Tess.frag.spv" }, "shadow": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "Shaders/DepthPass_Quads.tesc.spv", "tessellationEvaluation": "Shaders/DepthPass_Quads.tese.spv" }, "depthPass": { "vertex": "Shaders/DepthPass_Tess.vert.spv", "tessellationControl": "DepthPass_Quads.tesc.spv", "tessellationEvaluation": "DepthPass_Quads.tese.spv" } } } } } A shader family file can indicate a root to inherit values from. The Blinn-Phong shader family pulls settings from the PBR file and just switches some of the fragment shader values.
      { "turboShaderFamily" : { "root": "PBR.json", "OPAQUE": { "default": { "base": { "fragment": "Shaders/Blinn-Phong.frag.spv" } }, "isolines": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } }, "triangles": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } }, "quads": { "base": { "fragment": "Shaders/Blinn-Phong_Tess.frag.spv" } } } } } If you want to implement a custom shader, this is more work because you have to define all your changes for each possible shader variation. But once that is done, you have a new shader that will work with all of these different settings, which in the end is easier. I considered making a more complex inheritance / cascading schema but I think eliminating ambiguity is the most important goal in this and that should override any concern about the verbosity of these files. After all, I only plan on providing a couple of these files and you aren't going to need any more unless you are doing a lot of custom shaders. And if you are, this is the best solution for you anyways.
      Consequently, the baseShader, depthShader, etc. values in the material file definition are going away. Leadwerks .mat files will always use the Blinn-Phong shader family, and there is no way to change this without creating a material file in the new JSON material format.
      The shader class is no longer derived from the Asset class because it doesn't correspond to a single file. Instead, it is just a dumb container. A ShaderModule class derived from the Asset class has been added, and this does correspond with a single .spv file. But you, the user, won't really need to deal with any of this.
      The result of this is that one material will work with tessellation enabled or disabled, quad, triangle, or line meshes, and animated meshes. I also added an optional parameter in the CreatePlane(), CreateBox(), and CreateQuadSphere() commands that will create these primitives out of quads instead of triangles. The main reason for supporting quad meshes is that the tessellation is cleaner when quads are used. (Note that Vulkan still displays quads in wireframe mode as if they are triangles. I think the renderer probably converts them to normal triangles after the tessellation stage.)


      I also was able to implement PN Quads, which is a quad version of the Bezier curve that PN Triangles add to tessellation.



      Basically all the complexity is being packed into the shader family file so that these decisions only have to be made once instead of thousands of times for each different material.
    • By Josh in Josh's Dev Blog 0
      I'm back from I/ITSEC. This conference is basically like the military's version of GDC. VR applications built with Leadwerks took up about half of Northrop Grumman's booth. There were many interesting discussions about new technology and I received a very warm reception. I feel very positive about our new technology going forward.

      I am currently reworking the text field widget script to work with our persistent 2D objects. This is long and boring but needs to be done. Not much else to say right now.
    • By Josh in Josh's Dev Blog 4
      Here are some screenshots showing more complex interface items scaled at different resolutions. First, here is the interface at 100% scaling:

      And here is the same interface at the same screen resolution, with the DPI scaling turned up to 150%:

      The code to control this is sort of complex, and I don't care. GUI resolution independence is a complicated thing, so the goal should be to create a system that does what it is supposed to do reliably, not to make complicated things simpler at the expense of functionality.
      function widget:Draw(x,y,width,height) local scale = self.gui:GetScale() self.primitives[1].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) self.primitives[2].size = iVec2(self.size.x, self.size.y - self.tabsize.y * scale) --Tabs local n local tabpos = 0 for n = 1, #self.items do local tw = self:TabWidth(n) * scale if n * 3 > #self.primitives - 2 then self:AddRect(iVec2(tabpos,0), iVec2(tw, self.tabsize.y * scale), self.bordercolor, false, self.itemcornerradius * scale) self:AddRect(iVec2(tabpos+1,1), iVec2(tw, self.tabsize.y * scale) - iVec2(2 * scale,-1 * scale), self.backgroundcolor, false, self.itemcornerradius * scale) self:AddTextRect(self.items[n].text, iVec2(tabpos,0), iVec2(tw, self.tabsize.y*scale), self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end if self:SelectedItem() == n then self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos, 0) self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) + iVec2(0,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 2].color = self.selectedtabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,-1) self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,0) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 1) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,0) else self.primitives[2 + (n - 1) * 3 + 1].size = iVec2(tw, self.tabsize.y * scale) self.primitives[2 + (n - 1) * 3 + 2].color = self.tabcolor self.primitives[2 + (n - 1) * 3 + 2].size = iVec2(tw, self.tabsize.y * scale) - iVec2(2,2) if n == self.hovereditem then self.primitives[2 + (n - 1) * 3 + 3].color = self.hoveredtextcolor else self.primitives[2 + (n - 1) * 3 + 3].color = self.textcolor end self.primitives[2 + (n - 1) * 3 + 1].position = iVec2(tabpos,2) self.primitives[2 + (n - 1) * 3 + 2].position = iVec2(tabpos + 1, 3) self.primitives[2 + (n - 1) * 3 + 3].position = iVec2(tabpos,2) end self.primitives[2 + (n - 1) * 3 + 3].text = self.items[n].text tabpos = tabpos + tw - 2 end end  
×
×
  • Create New...