Preparing Leadwerks for the Future
Entry posted by Josh ·
6,110 views
In this blog I am going to explain my overarching plan to bring Leadwerks into the future and build our community.
First, regarding technology, I believe VR is the future. VR right now is basically where mobile was in 2006. The big publishers won't touch it and indies have a small but enthusiastic market they can target without fear of competition from EA. I have an HTC Vive and it is AWESOME! After using it, I don't really want to play games on a 2D monitor anymore. I want to be in the game, but there is still a serious lack of decent content out there.
At the same time, I think Vulkan is eventually going to be the graphics API we want to migrate to. Although Apple still isn't supporting it, Vulkan provides the best chance at a real cross-platform graphics API in the future.
We eventually want to move everything over to 64-bit and drop all support for 32-bit Windows (which almost no one has nowadays).
None of these issues are pressing. In reality, a switch over to Vulkan graphics, if done right, would result in no apparent change in the user experience for you guys. This is more about future-proofing and performance gains.
There is one last big thing I can do that could have a huge increase in performance. Right now Leadwerks runs your game code, which calls rendering and physics calls when you choose. A concurrent architecture would have four threads running your game logic, physics, rendering, and AI in separate threads, all the time, constantly. The data exchange between these threads is a complicated matter and would likely involve some restrictions on your code. It would also break backwards compatibility with our existing API examples. So this is probably something to discuss with Leadwerks 5, and may be quite a ways off in the future.
However, it's important that we start developing now with a clear idea of where we want to go. If information changes between now and then I can always change our course in the right direction.
Where we are today:
- OpenGL 4.0
- Windows API / GTK / Cocoa
- 64/32 bit
- Sequential architecture
Where we are going:
- Vulkan 1.0
- Leadwerks GUI on Windows, Mac, Linux
- 64-bit
- Concurrent architecture
What if VR Flops?
It doesn't matter. Developing for VR simply means adding in the OpenVR SDK and focusing on performance gains. This isn't like mobile where there's a completely different API and texture formats. VR will not hold back Leadwerks on the PC. It will help it. VR needs a solid 90 FPS, (although it's perfectly fine to lower your quality settings to achieve that). So developing for VR means focusing on performance gains over flexibility. We have a good idea now of how people use Leadwerks and I think we can make those decisions wisely now.
How to Begin?
I just outlined a plan to replace some of our low-level APIs and a major architectural change. However, I'm not willing to go back and do that until I feel like we have really polished Leadwerks Game Engine and given the users what they need. There's always a temptation to go back to the low-level details, but that just makes you an eternal tinkerer. Leadwerks is good because it's the easiest way to build your own games. That is the whole reason for Leadwerks to exist and we mustn't forget that.
If you read our reviews on Steam, it is pretty clear what the user needs. We are sitting right now with a solid 75% ("positive") approval rating, and a community that is actively churning out games. We are almost all the way there, but Leadwerks needs to take one last step to really connect with what the user needs. In my opinion, Leadwerks Game Engine is only as good as the default templates that come with it. If we can't provide polished game examples that look and feel like a real commercial game, it isn't fair to expect the end user to come up with one. I plan to add the following game templates to Leadwerks:
- Shoot-em-up space side-scroller
- Contra-like side scroller
- Simple racing game against AI opponents (like 4x4 Evo)
- RPG / dungeon crawler
Next, I plan to add built-in offline help documentation and video tutorials. By default, the editor is going to open the new help system automatically when the program starts. Too many people come on the forum asking questions about YouTube videos from years ago and don't go to the official tutorials still.
If we are going to make video tutorials, and I know that at some point we are going to revise the GUI, then it makes sense to revise the GUI first. Otherwise we will end up with a lot of video content that looks obsolete once we switch over to a new GUI. This is why I am working on Leadwerks GUI now. (Leadwerks GUI will also make it easier for us to switch the editor over the BlitzMaxNG, so that it can be compiled in 64-bit mode as pure C++.)
The revised GUI, built-in help system, and additional game templates will raise our approval rating on Steam up to 80%, which is considered "very positive". Once I have a game development system with an 80% positive rating and (by then) 20,000 users on Steam, that gives us quite a bit of leverage. Success breeds success, and I can use those figures to our advantage when negotiating with third parties.
Here are the steps we will take, in order:
- Leadwerks GUI
- Add Mac support
- Built-in offline help with videos
- New game templates
- Achieve 80% approval rating on Steam
Once we hit the 80% mark, that's when I know Leadwerks is really giving the end user what they need. I can then go back into some of the internals and work on our next iteration of technology:
- Move completely over to 64-bit
- Vulkan graphics
- Concurrent multithreaded architecture
This plan gives us a path forward into emerging technologies, in balance with the needs of the end user and the realities of the business. We won't have a major interruption of development and the game tournaments will continue as this is happening.
As always, this plan is subject to change and I may decide to do things differently depending on how circumstances develop.
-
1
-
18
11 Comments
Recommended Comments