Jump to content

Some Changes...



Leadwerks 3 / 4 was aimed at beginners who were completely new to game development. Since we were the first game engine on Steam, this made a lot of sense at the time, and the decision resulted in a successful outcome. However, in the next engine we are taking a different approach. (This is a direct result of Steam Direct.)

Enterprise is a new market I am pursuing, and we have a lot of interest from aerospace and defense VR developers. The fact that I am American also helps here. There are special features these customers need that aren't necessarily needed by game developers, but I think you will like some of the possibilities this unlocks.

For game developers, I have been moving back to an approach more like Leadwerks 2 where we focus on extreme high-end PC game technology, so that comes down to graphical quality and performance. I think most people here will be pretty happy with that direction. We're going to sell on Steam, Humble Store, Amazon, Microsoft store, Mac App Store, and direct from our website. Less importance will be attached to Steam, as they are just one more storefront we sell through. We're not going to use Steam Workshop.

For pricing of the non-enterprise version, I am thinking $59.99 / $99.99 standard / pro with a monthly subscription option at $4.99 / $9.99. This is actually cheaper than the pricing of Leadwerks, but I think keeping things under $100 is better for the consumer market.

The paid beta subscription is going to end before the end of the year, and it will be replaced with an open beta. The reason I did this was because I wanted a very small group of people testing the early betas (really more of an alpha), and I wanted to test out our subscriptions system. During that time we found and fixed a couple of small issues, so this was a good idea. A big thanks to all who participated and bought me many espressos. ;) 

Finally, we are not going to call Leadwerks 5 "Turbo Game Engine". The name just isn't sticking for me, and I don't think we can get rid of the :"retro" connotations it has. My new technology has developed quite a lot since then, and speed is not the only advantage it brings to the table. I do have a new name in mind, but I am not ready to announce it yet. Until then, I will refer to the new engine as "Leadwerks 5 beta".

  • Like 6


Recommended Comments

This all seems very logical to me. "Leadwerks 5" would struggle to get the beginner audience as other engines have this well covered. Some provide asset flip products while others offer free assets every month. Very hard for Leadwerks to compete in this market space. Especially as they are free although they take a % of anything you make. 

I can see as the owner of Leadwerks why you would be excited with the interest of aerospace and the military in your product. Guaranteed income is a comfort that allows you time to perfect and focus on the future. Hope you don't forget  your original users.

The loss of the Steam workshop is not a big deal as long as you continue the Leadwerks Market place. I think its a good idea to have a place were users can share assets to help each other out and to provided a modest income for those gifted enough to produce something that other users are interested in.

Pricing is very fair. I don't get why you would pay $10/month when you can own Leadwerks for $100. Inside a year you are better off with the pay upfront option. Or does the subscription always have the latest version  and the pay upfront have to pay for updates?

I was never really sold on the idea of calling the new engine Turbo. A google search for Turbo Engine will get lost in thousands of references to automotive products. Looking forward to the next name. 

  • Like 1

Share this comment

Link to comment

@Thirsty Panther Thank you for the comments. Regarding game content, what I have seen is that DLCs sell extremely well but it is very hard to get people to buy things through a new store. It even seems like people are more loyal to stores online than they are to the actual brick and mortar store they will shop at! So in the future I will probably focus on official DLC-type model packs and just try to improve the quality and amount of content offered of those, since they actually do sell well.

I plan to release paid updates every 12-18 months. I don't plan on ever going back and building a new foundation for our technology, and from here on out I want continuous forward progression, not any rewrites.

I definitely want to keep giving game developers what they want, because you guys give all the useful feedback. Without that, I can't build good software.

  • Like 2

Share this comment

Link to comment
12 minutes ago, 💎Yue💎 said:

The translator doesn't help much, a new name for the engine?

It won't be called Turbo. Something else.

  • Like 1

Share this comment

Link to comment

Looking forward to the new name, I'm sure it'll be as big as everything you do. 

Regarding the new approach, looking forward to seeing you at work, the world spins very fast and this technology changes very fast. In the end everything will always be beneficial for both you and the users.

Share this comment

Link to comment
On 11/2/2019 at 4:22 AM, Josh said:

I don't plan on ever going back and building a new foundation for our technology, and from here on out I want continuous forward progression, not any rewrites.

Just to tease you, pretty sure you said something very close to this when you were working on 3.  Something like how it'll be the last engine you'll ever need to write.  But I don't think Vulkan even existed back then.  Who knows what new technology will be out there in another 7 years.  I like all the decisions and thoughts posted, btw.

  • Haha 1
  • Confused 1

Share this comment

Link to comment

You can name it Leadwerks V.  "V" can stand as a number but also as a Vulkan. Or just Leadwerks engine? Furher updates can be incremented by year, Leadwerks V2021, etc.

Share this comment

Link to comment
20 hours ago, rogy said:

Or just Leadwerks engine? Furher updates can be incremented by year, Leadwerks V2021, etc.

This system makes sense on several levels.  For one, if it truly is the last engine Josh will ever write, this will cement that further, while 5 implies that there will be a 6.  Next, the yearly paid updates will also jive well with the yearly labeling.  That said, I'm far more concerned about the new features than the label.

  • Like 1

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.

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
      What's new
      EAX audio effects for supported hardware. Source class renamed to "Speaker". Plane joint for 2D physics, so now you can make Angry Birds with Vulkan graphics. Fixed DPI issues with fullscreen mode. Added impact noise to barrels, fixed Lua collision function not being called. Script functions now start with "Entity:" instead of "Script:", i.e. Entity:Update() instead of Script:Update(). Additionally, four examples can be run showing various functionality. Double-click on the .bat files to launch a different demo:
      First-person shooter game. 2D physics demonstration. Advanced 2D drawing with text, rotation, and scaling. Multi-camera setup.
    • By 💎Yue💎 in The shock absorbers 0
      It's interesting that when you become an expert on something, you're not sparing any effort to see how something works, but rather you're focusing on creating something. And so everything becomes easier.
      At this point of learning there is a glimpse of a low idea of creating a game, but the secret of all this is to keep it simple and to be very clear that a game is a game, and not an exact simulation of the real world. For example anyone who has a low idea of the red planet, will understand no matter the colors of the scene that is a terrain of Mars, even if it is not very real what is transmitted, a game, that's just it.
      At this point I already have an astronaut character who runs from one place to another on a very large 4096 x 4046 terrain that would surely take a long walk. My previous prototype projects involve a vehicle, but I didn't get the best implementation prospect in that time and I always found performance problems in my machine, something that isn't happening with the character controller for a third person player. 
      As always, I think I'm a scavenger looking for game resources, that's where this community exposes links to websites with interesting hd textures, and one or another model searched on the net, but what I've greatly improved is learning to write code, I have a better workflow, writing Lua code focused on the paradigm of object programming.

      Something interesting is the system of putting rocks, all very nice from the point of implementing them. And it works very well with the character controller if you put collision in cube form.
      I've been thinking about implementing a car system, I think it would be necessary in such a large terrain, but I think it's not the time, my previous experience, involves deterioration in performance and something I think is the physics of the car with respect to the terrain and rocks that in the previous project involve deterioration in the fps. Although if you implement a car would have an option would be to remove the rocks, but I prefer not to have a car and if you have rocks. 
    • By reepblue in reepblue's Blog 6
      Loading sounds in Leadwerks has always been straight forward. A sound file is loaded from the disk, and with the Source class emits the sound in 3D space. The sound entity also has a play function, but it's only really good for UI sounds. There is also Entity::EmitSound() which will play the sound at the entity's location. (You can also throw in a Source, but it'll auto release the object when it's done.)
      While this is OK for small games, larger games in which sounds may change might mean you have to open your class, and adjust the sounds accordingly. What if you use the sound in multiple places and you're happy with the volume and pitch settings from an earlier implementation? You could just redefine the source in a different actor, but why should you?
      A solution I came up with comes from SoundScripts from the Source Engine. With that engine, you had to define each sound as a SoundScript entry. This allowed you to define a sound once, and it allowed for other sound settings such as multiple sounds per entry. I thought this over, and with JSON, we can easily create a similar system for Leadwerks 4 and the new engine.
      I first started with a dummy script so I can figure out how I wanted the end result to be.
      { "soundData": { "Error": { "file": "Sound/error.wav", "volume": 1.0, "pitch": 1.0, "range": 0.25 }, "RandomSound": { "files": { "file1": "Sound/Test/tone1.wav", "file2": "Sound/Test/tone2.wav", "file3": "Sound/Test/tone3.wav" }, "volume": 1.0, "pitch": 1.0, "range": 0.25 } } } In this script, we have two sound entries. We have an error sound (Which is suppose to be the fall back sound for an invalid sound entry) and we have a sound entry that holds multiple files. We want a simple, straight forward. entry like "Error" to work, while also supporting something "RandomSound" which can be used for something like footstep sounds.
      The script is streamed and stored into multiple structs in a std::map at the application start. We use the key for the name, and the value is the struct.
      typedef struct { std::string files[128]; char filecount; float volume; float pitch; float range; bool loopmode; } sounddata_t; std::map<std::string, sounddata_t> scriptedsounds; Also notice that we don't store any pointers, just information. To do the next bit, I decided to derive off of the engine's Source class and call it "Speaker". The Speaker class allows us to load sounds via the script entry, and support multiple sounds.
      You create one like this, and you have all the functionalities with the Source as before, but a few differences.
      // Speaker: auto speaker = CreateSpeaker("RandomSound"); When you use Play() with the speaker class and if the sound entry has a "files" table array, it'll pick a sound at random. You can also use PlayIndex() to play the sound entry in the array. I also added a SetSourceEntity() function which will create a pivot, parent to the target entity. From there, the Play function will always play from the pivot's position. This is a good alternative to Entity::EmitSound(), as you don't need to Copy/Instance the Source before calling the function as that function releases the Source as mentioned earlier. Just play the speaker, and you'll be fine! You can also change the sound entry at anytime by calling SetSoundEntry(const std::string pSoundEntryName); The creation of the Speaker class will start the JSON phrasing. If it has already been done, it will not do it again.
      Having sounds being loaded and stored like this opens up a lot of possibles. One thing I plan on implementing is a volume modifier which will adjust the volume based on the games volume setting.Right now, it uses the defined volume setting. It's also a part of another system I have in the works.
  • Create New...