Jump to content

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

Josh

14,213 views

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.

 

blogentry-1-0-61581200-1387224019_thumb.jpg

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.



50 Comments


Recommended Comments



Am I misreading this or do new customers get 3.1 for $99 less than existing customers (who already paid $199 to purchase just 3.0)? And what about water, networking and other features? If we need to pay $99 for each of those features every year then this engine will get very expensive. Or will those be added to 3.1 next year?

Share this comment


Link to comment

Our business model is to maintain a low price and charge for upgrades on a roughly annual basis. This ensures that development is inline with what the customer base wants; the upgrade rate gives me a metric that tells me how well development is meeting everyone's needs.

 

Products that take the "free upgrades for life" approach always fail because they are 100% reliant on new customers, and eventually that slows down. There are lots of software applications I own that eventually died out because they never charged for updates, when I would have been happy to pay to get more out of them.

Share this comment


Link to comment

+1 on the no mobile upgrade cost when it comes out!

 

If we need to pay $99 for each of those features every year then this engine will get very expensive.

 

We got 3 very nice features in this upgrade so I'd be shocked if each feature you listed itself will be an upgrade on it's own. As much as some people hate on 3.0 it was a good upgrade. We got pathfinding, csg, mobile support, run on wider range of hardware, and a more solid engine with the transition to C++ as it's core.

 

Honestly even if we did pay $99 for each of those features, which I don't think we will, it'll still be cheaper than some other engines. $99 /yr is cheaper than most of my other hobbies, and those don't really offer me the chance to make any money from them :)

Share this comment


Link to comment

I guess you forgot to add the not-already-customers of Leadwerks 3.0 who pledged $200+ to the section for the receivers of the 3.1 upgrade.

Share this comment


Link to comment

If one were currently developing a game for PC using a version of Leadwerks 2, would it be a good idea to switch to 3.1 now, since 3.0 was mostly for smartphone games?

Share this comment


Link to comment

I guess you forgot to add the not-already-customers of Leadwerks 3.0 who pledged $200+ to the section for the receivers of the 3.1 upgrade.

Kickstarter backers are receiving version 3.1 as was promised in the campaign. Is that what you meant?

 

If one were currently developing a game for PC using a version of Leadwerks 2, would it be a good idea to switch to 3.1 now, since 3.0 was mostly for smartphone games?

The new features in 3.1 are focused on PC development, and the renderer is more similar to the one from Leadwerks 2, so I think you will be comfortable on that.

Share this comment


Link to comment

I have no problems paying some money for yearly upgrades. Not 99$, but 199$ for yearly upgrades which bring a resonable amount of new features are 100% justifiable and will keep leadwerks a live.

Share this comment


Link to comment

Bought it. Linux support was an important reason

I hope 3.2 will have some easy to use integrated GUI .......

Share this comment


Link to comment

Kickstarter backers are receiving version 3.1 as was promised in the campaign. Is that what you meant?

Yes, thx.

Share this comment


Link to comment

I have absolutely no problem with upgrade fees in general. My confusion is with why all the costs of the upgrade go to existing customers. Why not charge less to existing customers and add some of the cost to new buyers? 3.1 costing the same as 3.0 for new purchases seems odd.

 

Or, imagine if this trend continues. Even as an existing customer, in 2 years, you'd be better off buying 3.3 from scratch instead of buying 3 upgrades. It would save you money. Seem a bit strange?

Share this comment


Link to comment

@gamecreator But then you wouldn't ever use the product because you'd always be waiting to save money. It's like cable or dish. They always give big savings to new customers to try and get them to convert. If you want the product/service, at some point you bite the bullet and make the purchase knowing that they may have bigger savings later for newer customers.

Share this comment


Link to comment

Personally, I think anywhere from $50-70 would be fair while $99 is pushing the cost/benefit analysis over the long haul. Upgrade fees themselves are not a problem. Rather, the business model should be that features are added at such a rate as to attract and retain a large user base at that lower rate. What's the attrition rate at $99/year?

 

Products die because users are not retained and there is no growth. The upgrade fee is only a part of the equation. I would suggest that this model of planning for yearly paid updates will work against an aggressive campaign to fortify the user base. The clockwork approach leaves me with a sense of something missing or that I'm being trapped.

 

That said, it remains to be seen whether the Linux port will create additional synergies and growth. If 'yes', what should the upgrade fee be under those circumstances? Optimistic planning might have resulted in an upgrade fee of $50-70. Have faith.

Share this comment


Link to comment

Products that take the "free upgrades for life" approach always fail because they are 100% reliant on new customers, and eventually that slows down. There are lots of software applications I own that eventually died out because they never charged for updates, when I would have been happy to pay to get more out of them.

 

Firstly, not all products on this model die out - one example is PureBasic.

Also, I agree with other comments that it seems upgrade prices are too high compared with the full product.

 

Also, other products that do charge for upgrades, normally charge for full version (e.g. 3.0 -> 4.0) upgrades only, and not point releases (3.0 ->3.x).

 

Finally, if I pledged for the KS and I get 3.1 when due, is there anyway to get that Steam Indie Edition as well either for free (preferably) or for a low atractive price?

Share this comment


Link to comment

I don't see how $99 a year is all that much. Save $8.33 a month and you'll be good each year. :)

 

Josh could be naming these releases by major number if that would make people feel better, but it's about the features added not the release number.

Share this comment


Link to comment

I understand that Josh has underpriced the engine (in his eye) and he's overpricing the updates to compensate - like companies do with consoles and games. It's a rough business model but if he honestly thought 3.0 was worth $1000 originally, I guess he's making compromises too.

Share this comment


Link to comment
Finally, if I pledged for the KS and I get 3.1 when due, is there anyway to get that Steam Indie Edition as well either for free (preferably) or for a low atractive price?

All Kickstarter backers who got a reward with any version of the software will get a free Steam key for the Indie Edition before January 6th. Even if you don't run Windows, hold onto this because the Linux version on Steam will have some special features.

Share this comment


Link to comment

I don't think the updates are overpriced at all. Look at Unity Pro. It's $1,500! If you look at the feature list between them it's fairly comparable and LE is way cheaper! If you purchased 3.0 and upgrade to 3.1 you'll have paid like $300? It would take 12 more years of $99 upgrades to finally hit Unity Pro's cost. I've been more productive with LE than I was with even the indie version of Unity (that's just my experience obviously).

 

Personally, I just don't think $99/yr upgrades are overpriced when comparing it to some other popular engines.

Share this comment


Link to comment

Rick, Leadwerks competes with more than just one of the most expensive engines on the market. Saying it's cheaper than Unity doesn't say much.

 

But I'm with you in that by far Leadwerks fits me best. I'll pay this upgrade grudgingly and then continue to enjoy using the engine.

Share this comment


Link to comment

Yearly upgrade at a reasonable price is fine by me so long as there is a big/good update. You can also look at the fact that you get small updates throughout the year.

 

how do you know to which Steam user the upgrade needs to be granted?

In your profile there's a place for your Steam ID.

Share this comment


Link to comment

@gamecreator I agree, but from my experience it's one of the closest in terms of a polish editor and great API that doesn't take royalties so that's why I used it.

Share this comment


Link to comment

Again, I'm not opposed to upgrade costs and will likely (maybe) do this one but I would rather see a model of constant development and releases, with no lulls in the middle of the year. No bizarro marketing philosophies or teasers, just plain reliability. The example of Purebasic was offered earlier. Such an approach provides some confidence that the user base will grow. As noted above, this market is not captive meaning that users can simply switch, impacting the entire community. The potential for silence in the middle of the year is the perfect time to lose clients - too much ambiguity. Or, as in the case with Adobe, users often choose every second upgrade cycle. For a small operation that can prove fatal. And, again, the community suffers as a whole.

 

Just my two cents.

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 3
      I wanted to work on something a bit different, and this sure is different. I've got a framework of a new particle system worked out. What's really special about this system is the amount of interactivity the particles will allow.
      Particle-world collisions. Particle-particle collisions (repulsion) Particle-particle cohesion (fluids with surface tension) Instead of just being a visual effect, I want our new particles to be fully interactive with physics so that particles can exert forces on objects. This will allow you to simulate fluids, smoke, and other effects in a realistic manner, not just dumb collision of particles bounding off walls. It should even be possible to simulate hydrophobic and hydrophillic liquids if you mix two together with different cohesion values.
      Basically what I want is something like Nvidia Flow on the CPU and exerting forces on the world. So if you had water falling on a water wheel the wheel would move because of the forces, or a blast of wind could knock objects over without any special force fields or other fake effects.
      I also have a technique worked out that will allow lighting of clouds and other masses of gas, with back-scattering.
      Emitters can be instanced so if you have one really high-quality torch effect, for example, you can instance it and use it as much as you like without any additional computational cost per instance.
      Particle emitters can be controlled with a Lua script or C++ actor. Two new functions are available, UpdateParticle() and EmitParticle(). Here is a script that controls particle behavior over time:
      entity.particleVelocity = Vec3(0,0,1) entity.particleAcceleration = Vec3(0,-1,0) entity.inverseSquareFalloff = true entity.particleRadiusBegin = 0.1 entity.particleRadiusEnd = 0.2 entity.particleColorBegin = Vec4(1,1,1,1) entity.particleColorEnd = Vec4(1,1,1,0) entity.particleMass = 1 entity.particleSpin = 5 function entity:Start() self.particleColorBeginHSL = HSL(self.particleColorBegin.rgb) self.particleColorEndHSL = HSL(self.particleColorEnd.rgb) local emitter = Emitter(self) if emitter == nil then return end local n for n = 1, #emitter.particles do emitter.particles[n].mass = self.particleMass emitter.particles[n].falloff = (n-1) / (#emitter.particles - 1) end end function entity:EmitParticle(index) local emitter = Emitter(self) if emitter == nil then return end emitter.particles[index].position = self:GetPosition(true) emitter.particles[index].velocity = TransformVector(self.particleVelocity,self,nil) emitter.particles[index].radius = self.particleRadiusBegin emitter.particles[index].color = self.particleColorBegin end function entity:UpdateParticle(index) local emitter = Emitter(self) if emitter == nil then return end emitter.particles[index].velocity = emitter.particles[index].velocity + self.particleAcceleration / 60 local falloff = emitter.particles[index].falloff if self.inverseSquareFalloff then falloff = falloff * falloff end emitter.particles[index].color.rgb = RGB(self.particleColorBeginHSL * (1 - falloff) + self.particleColorEndHSL * falloff) emitter.particles[index].color.a = self.particleColorBegin.a * (1 - falloff) + self.particleColorEnd.a * falloff emitter.particles[index].radius = self.particleRadiusBegin * (1 - falloff) + self.particleRadiusEnd * falloff emitter.particles[index].rotation = emitter.particles[index].rotation + self.particleSpin / 60 end A different script could be used to make particles emit from vertices of a model, to make the model appear to be on fire, or other effects. This will allow infinite customization to create any behavior you want.
      Particle physics will be calculated on the physics thread so I expect them to be very fast.
    • By Josh in Josh's Dev Blog 6
      For finer control over what 2D elements appear on what camera, I have implemented a system of "Sprite Layers". Here's how it works:
      A sprite layer is created in a world. Sprites are created in a layer. Layers are attached to a camera (in the same world). The reason the sprite layer is linked to the world is because the render tweening operates on a per-world basis, and it works with the sprite system just like the entity system. In fact, the rendering thread uses the same RenderNode class for both.
      I have basic GUI functionality working now. A GUI can be created directly on a window and use the OS drawing commands, or it can be created on a sprite layer and rendered with 3D graphics. The first method is how I plan to make the new editor user interface, while the second is quite flexible. The most common usage will be to create a sprite layer, attach it to the main camera, and add a GUI to appear in-game. However, you can just as easily attach a sprite layer to a camera that has a texture render target, and make the GUI appear in-game on a panel in 3D. Because of these different usages, you must manually insert events like mouse movements into the GUI in order for it to process them:
      while true do local event = GetEvent() if event.id == EVENT_NONE then break end if event.id == EVENT_MOUSE_DOWN or event.id == EVENT_MOUSE_MOVE or event.id == EVENT_MOUSE_UP or event.id == EVENT_KEY_DOWN or event.id == EVENT_KEY_UP then gui:ProcessEvent(event) end end You could also input your own events from the mouse position to create interactive surfaces, like in games like DOOM and Soma. Or you can render the GUI to a texture and interact with it by feeding in input from VR controllers.

      Because the new 2D drawing system uses persistent objects instead of drawing commands the code to display elements has changed quite a lot. Here is my current button script. I implemented a system of abstract GUI "rectangles" the script can create and modify. If the GUI is attached to a sprite layer these get translated into sprites, and if it is attached directly to a window they get translated into system drawing commands. Note that the AddTextRect doesn't even allow you to access the widget text directly because the widget text is stored in a wstring, which supports Unicode characters but is not supported by Lua.
      --Default values widget.pushed=false widget.hovered=false widget.textindent=4 widget.checkboxsize=14 widget.checkboxindent=5 widget.radius=3 widget.textcolor = Vec4(1,1,1,1) widget.bordercolor = Vec4(0,0,0,0) widget.hoverbordercolor = Vec4(51/255,151/255,1) widget.backgroundcolor = Vec4(0.2,0.2,0.2,1) function widget:MouseEnter(x,y) self.hovered = true self:Redraw() end function widget:MouseLeave(x,y) self.hovered = false self:Redraw() end function widget:MouseDown(button,x,y) if button == MOUSE_LEFT then self.pushed=true self:Redraw() end end function widget:MouseUp(button,x,y) if button == MOUSE_LEFT then self.pushed = false if self.hovered then EmitEvent(EVENT_WIDGET_ACTION,self) end self:Redraw() end end function widget:OK() EmitEvent(EVENT_WIDGET_ACTION,self) end function widget:KeyDown(keycode) if keycode == KEY_ENTER then EmitEvent(EVENT_WIDGET_ACTION,self) self:Redraw() end end function widget:Start() --Background self:AddRect(self.position, self.size, self.backgroundcolor, false, self.radius) --Border if self.hovered == true then self:AddRect(self.position, self.size, self.hoverbordercolor, true, self.radius) else self:AddRect(self.position, self.size, self.bordercolor, true, self.radius) end --Text if self.pushed == true then self:AddTextRect(self.position + iVec2(1,1), self.size, self.textcolor, TEXT_CENTER + TEXT_MIDDLE) else self:AddTextRect(self.position, self.size, self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end end function widget:Draw() --Update position and size self.primitives[1].position = self.position self.primitives[1].size = self.size self.primitives[2].position = self.position self.primitives[2].size = self.size self.primitives[3].size = self.size --Update the border color based on the current hover state if self.hovered == true then self.primitives[2].color = self.hoverbordercolor else self.primitives[2].color = self.bordercolor end --Offset the text when button is pressed if self.pushed == true then self.primitives[3].position = self.position + iVec2(1,1) else self.primitives[3].position = self.position end end This is arguably harder to use than the Leadwerks 4 system, but it gives you advanced capabilities and better performance that the previous design did not allow.
    • By reepblue in reepblue's Blog 1
      Premake is multiplication project maker.Unlike CMake, it simply generates a project file for the given IDE giving you a clean result. You only need the one light weight executable and a lua script for this to work.  I've spent today setting it up with Leadwerks. I haven't tested Linux yet, but it should work.
      My premake5.lua file:
      g_LeadwerksHeaderPath = "./Engine/Include" g_LeadwerksLibPath = "./Engine/Libs" function GlobalSettings() -- Include Directories includedirs { "%{prj.name}", "%{g_LeadwerksHeaderPath}", "%{g_LeadwerksHeaderPath}/Libraries/SDL2-2.0.10/include", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgCore", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgNewton", "%{g_LeadwerksHeaderPath}/Libraries/libvorbis/include", "%{g_LeadwerksHeaderPath}/Libraries/libogg/include", "%{g_LeadwerksHeaderPath}/Libraries/openssl/include", "%{g_LeadwerksHeaderPath}/Libraries/VHACD/src/VHACD_Lib/inc", "%{g_LeadwerksHeaderPath}/Libraries/glslang", "%{g_LeadwerksHeaderPath}/Libraries/freetype-2.4.7/include", "%{g_LeadwerksHeaderPath}/Libraries/OpenAL/include", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dMath", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dgTimeTracker", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dContainers", "%{g_LeadwerksHeaderPath}/Libraries/NewtonDynamics/sdk/dCustomJoints", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/RecastDemo/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DetourCrowd/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DetourTileCache/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/DebugUtils/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/Recast/Include", "%{g_LeadwerksHeaderPath}/Libraries/RecastNavigation/Detour/Include", "%{g_LeadwerksHeaderPath}/Libraries/tolua++-1.0.93/include", "%{g_LeadwerksHeaderPath}/Libraries/lua-5.1.4", "%{g_LeadwerksHeaderPath}/Libraries/glew-1.6.0/include/GL", "%{g_LeadwerksHeaderPath}/Libraries/glew-1.6.0/include", "%{g_LeadwerksHeaderPath}/Libraries/enet-1.3.1/include", "%{g_LeadwerksHeaderPath}/Libraries/zlib-1.2.5", "%{g_LeadwerksHeaderPath}/Libraries/freetype-2.4.3/include" } -- Global Defines: defines { "__STEAM__", "_CUSTOM_JOINTS_STATIC_LIB", "FT2_BUILD_LIBRARY", "LEADWERKS_3_1", "DG_DISABLE_ASSERT", "OPENGL", "_NEWTON_STATIC_LIB", "_STATICLIB" } -- Windows Exclusive: filter "system:windows" systemversion "latest" pchsource "%{prj.name}/stdafx.cpp" links { "libcryptoMT.lib", "libsslMT.lib", "Rpcrt4.lib", "crypt32.lib", "libcurl.lib", "msimg32.lib", "lua51.lib", "steam_api.lib", "ws2_32.lib", "Glu32.lib", "libovrd.lib", "OpenGL32.lib", "winmm.lib", "Psapi.lib", "OpenAL32.lib", "SDL2.lib", "Leadwerks.lib" } libdirs { "%{g_LeadwerksLibPath}/Windows/x86", "%{g_LeadwerksLibPath}/Windows/x86/%{cfg.buildcfg}" } defines { "PSAPI_VERSION=1", "PTW32_STATIC_LIB", "PTW32_BUILD", "_NEWTON_USE_LIB", "_LIB", "DG_USE_NORMAL_PRIORITY_THREAD", "GLEW_STATIC", "WINDOWS", "WIN32", "OS_WINDOWS", "PLATFORM_WINDOWS", "_WIN_32_VER" } buildoptions { "/D \"SLB_LIBRARY\"", } flags { "NoMinimalRebuild" } linkoptions { "/NODEFAULTLIB:MSVCRT.lib", "/NODEFAULTLIB:MSVCRTD.lib" } -- Linux Exclusive: filter "system:linux" systemversion "latest" linkoptions { "-ldl", "-lopenal", "-lGL", "-lGLU", "-lX11", "-lXext", "-lXrender", "-lXft", "-lpthread", "-lcurl", --"-lSDL2", "%{g_LeadwerksLibPath}/Linux/libluajit.a", "%{gameDir}/libopenvr_api.so" } defines { "ZLIB", "PLATFORM_LINUX", "unix", "_POSIX_VER", "_POSIX_VER_64", "DG_THREAD_EMULATION", "DG_USE_THREAD_EMULATION", "GL_GLEXT_PROTOTYPES", "LUA_USE_LINUX", "_GLIBCXX_USE_CXX11_ABI", "_CUSTOM_JOINTS_STATIC_LIB" } linkoptions { "%{g_LeadwerksLibPath}/Linux/%{cfg.buildcfg}/Leadwerks.a" } -- Debug Build: filter "configurations:Debug" runtime "Debug" symbols "on" targetsuffix ".debug" defines { "DEBUG", "_DEBUG" } if os.target() == "windows" then links { "newton_d.lib", "dContainers_d.lib", "dCustomJoints_d.lib" } end -- Release Build: filter "configurations:Release" runtime "Release" optimize "on" if os.target() == "windows" then buildoptions { "/MP" } links { "newton.lib", "dContainers.lib", "dCustomJoints.lib" } end end function GenerateLuaApp() workspace "PremakeTest" architecture "x86" --architecture "x86_64" startproject "LuaApp" configurations { "Debug", "Release" } -- Test application project "LuaApp" kind "ConsoleApp" language "C++" location "%{prj.name}" staticruntime "on" -- Project Directory: projectDir = "%{prj.name}/" -- Game Directory: gameDir = _WORKING_DIR .. "/../Projects/%{prj.name}" -- OBJ Directory objdir (projectDir .. "%{cfg.buildcfg}_%{prj.name}") targetdir (gameDir) files { "%{prj.name}/**.h", "%{prj.name}/**.cpp" } pchheader "stdafx.h" -- Custom Defines defines { "__TEST_ME_", } GlobalSettings() end newaction { trigger = "luaapp", description = "Builds the stock lua app", execute = GenerateLuaApp() } if _ACTION == "luaapp" then GenerateLuaApp() end Then I just have batch file that builds the project file.
      "devtools/premake5.exe" vs2017 luaapp pause My impressions are more positive on this than CMake as CMake creates a lot of extra files to do real time updating if the CMakeList file is updated. Premake simply just builds the project file and that's it. It really reminds me of VPC stuff I had to deal with in my modding days. Really interested to how codelite projects generate on Linux.
×
×
  • Create New...