Jump to content

Josh

Staff
  • Posts

    23,307
  • Joined

  • Last visited

Blog Entries posted by Josh

  1. Josh
    I have resumed work on voxel-based global illumination using voxel cone step tracing in Leadwerks Game Engine 5 beta with our Vulkan renderer. I previously put about three months of work into this with some promising results, but it is a very difficult system and I wanted to focus on Vulkan. Some of features we have gained since then like Pixmaps and DXT decompression make the voxel GI system easier to finish.
    I previously considered implementing Nvidia's raytracing techniques for Vulkan but the performance is terrible, even on the highest-end graphics cards. Voxel-based GI looks great and runs fast with basically no performance penalty.
    Below we have a section of the scene voxelized and lit with direct lighting. Loading the Sponza scene from GLTF format made it easy to display all materials and textures correctly.

    I found that the fastest way to manage voxel data was by storing the data in one big STL vector, and storing an STL set of occupied cells. (An STL set is like a map with only keys.) I found the fastest way to perform voxel raycasting was actually just to walk through the voxel data with optimized C++ code. This was much faster than my previous attempts to use octrees, and much simpler too! The above scene took about about 100 milliseconds to calculate direct lighting on a single CPU core, which is three times faster than my previous attempts. This definitely means that CPU-based GI lighting may be possible, which is my preferred approach. It's easier to implement, easy to parallelize, more flexible, more reliable, uses less video memory, transfers less data to the GPU, and doesn't draw any GPU power away from rendering the rest of the scene.
    The challenge will be in minimizing the delay between when an object moves, GI is recalculated, and when the data uploaded to the GPU and appears onscreen. I am guessing a delay somewhere around 200 milliseconds will be acceptable. It should also be considered that only an onscreen object will have a perceived delay if the reflection is slow to appear. An offscreen object will have no perceived delay because you can only see the reflection. Using screen-space reflections on pixels that can use it is one way to mitigate that problem, but if possible I would prefer to use one uniform system instead of mixing two rendering techniques.
    If this does not work then I will upload a DXT compressed texture containing the voxel data to the GPU. There are several stages at which the data can be handed off, so the question is which one works best?

    My design has changed a bit, but this is a pretty graphic.
    Using the pixmap class I will be able to load low-resolution versions of textures into system memory, decompress them to a readable format, and use that data to colorize the voxels according to the textures and UV coordinates of the vertices that are fed into the voxelization process.
  2. Josh

    Articles
    This is an update on my progress of our voxel raytracing system. VXRT is designed to provide all the reflection information that PBR materials use. If a picture is worth a thousand words, then this counts as a 5000 word article.
    Direct lighting:

    Global illumination:

    Specular reflection:

    Skybox component:

    Final combined image:

  3. Josh
    An update is now available on the beta branch which adds water. This can be controlled in the scene properties or in code with the following commands:

    World::SetWaterMode(bool mode) World::SetWaterHeight(float height) World::SetWaterColor(float r, float g, float b, float a) bool World::GetWaterMode() float World::GetWaterHeight() Vec4 World::GetWaterColor()
     
    You must update your project to get new EXEs and shaders. All model shaders have been modified to handle the slice plane used when rendering reflections. A new set of textures have also been added in "Materials\Effects\Water" to handle the surface perturbation.
     
    Caveats / Notes
    When underwater, no post-processing screen wobble or fog is applied like in Leadwerks 2. This is because Leadwerks 3 has a customizable post-process stack, so the end user can control this.
    The water physics are not 100% done and behave oddly.
    There is a bug where switching projects does not reset the water settings to the default.
    At this time there are no water quality settings, though the renderer uses the lowest possible quality in the reflection pass.
    This build has been tested on every hardware / OS configuration except AMD on Linux.

     

  4. Josh
    A new update is available. I believe this will fix any problems you may have previously experienced with the water rendering. If this is not the case, please let me know, preferably with a link to download your project.
     
    Although Intel's new drivers work well, I have noticed that enabling, then disabling, then enabling water in the editor causes a crash. The crash occurs in the driver DLL and is not an OpenGL error. This will be reported to Intel. (It just occurs when a shader reads a depth texture so I am pretty sure this is Intel's fault.)
  5. Josh
    In Leadwerks 4.3 we integrated GameAnalytics.com into our software, both in the editor and in the engine, as a tool developers can use to track their player statistics.  A number of events were set up in the editor to fire when certain actions were performed, in order to gain better insight into how people were using Leadwerks.  Here are the results.
    The most popular primitives
    Unsurprisingly, boxes are by far the most popular primitive created in Leadwerks Editor.  The community has created more than 20,000 boxes since analytics were enabled.  What blows my mind is that cylinders are actually the second-most commonly used primitive, rather than wedges.  Users created 1753 cylinders but only 1358 wedges in the given time period!  Even more shocking is that spheres are more popular than cones, with 985 spheres created versus just 472 cone primitives.
    This causes me to question my assumptions of how people use Leadwerks, and how items in the interface should be prioritized.

    The Workshop Store is used heavily
    Leadwerks users installed more than 5000 items from the Workshop.  It also looks like people install many items, as sometimes the number of installs exceed the number of times the Workshop interface is opened.

    People buy Workshop items directly through the Steam Client
    Although users are buying Workshop items in high quantities, it appears that their primary route is through the Steam store interface, rather than the built-in Workshop browser.  People browse the items in the Steam client and then use the Workshop browser to install their purchased items.  The numbers for Workshop Store purchases are much higher than the number of people clicking the buy button in the editor.
    If you're interested in selling your 3D models or textures through the Leadwerks Workshop Store, it's easy to get started and you can earn money directly from Steam.  Contact us to learn more or stop by the forum.
  6. Josh
    I'm working to add weapon switching to the player script. A weapon in the map consists of two important parts. First, you need a pickup weapon that tells the player they have a certain item. Second, you need the visual weapon that is displayed onscreen, along with the various settings that make that weapon unique.
     
    It's a simple thing to program, but I'm trying to make it as easy as possible for the user to manage, so people can add new weapons and have them work with no tinkering and adjustment required. Usually that means trying a few different approaches and then deciding which is best.
     

     
    I like working on high-level stuff like this. Having a good shotgun blast is very satisfying, and makes my map suddenly feel like a "real" game. (I used the new sprite entity to make the visible pellets.) This kind of stuff is why I got into game development, and I hope to work on more practical and fun things like this over the next year. I want Leadwerks to be an extremely high-level system, but to have the ability to drill down to the next layer when you need to. More pre-made reusable functionality you can use or modify to your heart's content.
     


  7. Josh
    I have a few preview images to show you my progress with the implementation of my design for the website refresh. Enjoy.
     

     

     

     
    Here's a new version of the view image page. It's pretty bold. The image stretches to its max dimensions, and a dark background is shown beyond that.
     

     
    Working with a dark background for the video and gallery pages, and it feels pretty natural. Information pages with lots of text use the light theme, while image-heavy artsy sections use a dark theme so you can focus on the content.
     

     
    This is close to finished:
     

  8. Josh

    Articles
    I want to streamline some of this website. We went through a lot of changes since the release on Steam in 2014 and learned what works and what does not.
    The "Marketplace" is just called the default "Downloads" name now, and that literally is what it is for. It's a place to keep a permanent copy of your files. Paid files are still supported, and any purchased items are still available to download, but I do not have any aspirations of building this up unless it just happens spontaneously. Instead I will focus on DLCs and on just making the file format loading features as easy as possible, so you can just buy something on cgtrader.com and not have any conversion step at all. I have hidden all paid items that did not have any sales, but I will keep them on the server for now.
    Most of your games have been moved back to the downloads area. I was the one who wanted everyone to move to the game launcher on Steam, so I will move them back for you. It would have been a great idea if Steam brought in traffic. There was some success with that, but it was not at a level that it justifies all the complication of going through that system.
    I am finding that the gallery and videos do a much better job of keeping people's attention than having a bunch of custom game pages they have to click around to find something interesting, so I intend to move all the games, videos, and screenshots out of the games database and eventually phase that out. You are welcome to put links in your screenshots and videos, and it will bring traffic to your page.
    One thing that really got me thinking this way was I have noticed some people post screenshots here regularly. I see them posting the same images on some other more general gamedev websites, and they seem to come here because they get more attention and feedback than they do on the bigger sites. I have even seen people post videos here and get more views than they do on YouTube (assuming YouTube views and comments are even real, which they might very well not be).
    In general I am finding that pushing all the content together and serving it up at 25 dopamine hits per page works really well. I want to move the content out of the projects area and phase that out too, for this reason.
    The chat feature I installed last week is a massive success and fills a huge need without sending all our activity away somewhere else.
    I want the website to be more focused because that helps me think. I don't want any more changes. I don't really want to try any new ideas this year because I don't think it's necessary.
    Going forward, we know now what our strategy is. On the consumer side, I just need to listen to you, the users, about what features you need, and deliver an improved overall quality over what we did with Leadwerks Engine. Although you don't have to do VR, focusing on VR gives me a niche of customers who I can help achieve some very interesting games, and it is gives you guys a way to sell in a market that has a lot of demand and isn't saturated. Imagine if there were 100 indie VR games available in the Downloads area right now. That would be quite popular.
    On the business side, I plan to give them something they cannot say no to, which is why I am been spending so long developing this killer new technology.
    In the end, Steam didn't have anything to offer other than another place to sell software, and it made me do some really weird things. There is no advantage to using any of the features built into Steam, except maybe the P2P networking system if you need it.
    I don't think more "innovation" is really needed now. Mostly I just need focus on giving you the features you need with good quality and documentation. Of course, the new engine allows me to do that in a way I could not before.
  9. Josh
    Here are some concepts I came up with for the site redesign.
     

     

     

     
    The bold no-bull**** interface of itch.io inspired this design:
     

     
    I think what will work best is if the designer takes my rough sketches, turns it into a clean design, and implements it with clean code.
     
    I don't think we can change the whole site over at once without me losing control of the creative process and having runaway costs. I want to focus on the pages I have shown here and establish a foundation I can experiment with and iterate on.
  10. Josh
    With the upcoming uncertainty that Steam Direct introduces to Steam sellers, I am putting more effort into our website, because it may be the primary channel through which new users discover Leadwerks in the future. Although the functionality of our site is awesome, the visual design is rather outdated and it's time for an actual designer to take over. I've got a rough idea of what I want the site to look like, but beyond that I am happy to let someone else figure it out.
     



     
    I plan on the design using lots of big images, and we have a large collection of high-res renders made with Leadwerks that will look great.
  11. Josh
    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.
  12. Josh
    Our website has been updated with a new look and responsive design. Here are a few highlights.
     
    Landing page:

     
    Product pages:

     
    Screenshots used in the site from games will display the title and author when you hover the mouse over them.
     
    Responsive layout scaled for phones:

     
    Clearer writing that says exactly what Leadwerks does and who it is for:

     
    Dark gallery and video pages:

     
    Sleek screenshot pages:

     
    I left the Workshop pages as-is for now. The forum software is going to be updated and a new skin will be designed for the new version of the community software.
  13. Josh
    I've successfully pulled every website page out of the Invision Power Board CMS that I can:
    http://www.leadwerks.com
    http://www.leadwerks.com/graphics
    http://www.leadwerks.com/editor
    http://www.leadwerks.com/programming
    http://www.leadwerks.com/features
    http://www.leadwerks.com/steamos
    http://www.leadwerks.com/gamelauncher
    http://www.leadwerks.com/workshop
    http://www.leadwerks.com/gallery
    http://www.leadwerks.com/videos
    http://www.leadwerks.com/games
    http://www.leadwerks.com/company
    http://www.leadwerks.com/contact
    http://www.leadwerks.com/termsofuse
    http://www.leadwerks.com/privacy
    http://www.leadwerks.com/cookies
     
    These pages load independently from any of the community software files, so the website and community can be updated separately.
     
    I've taken the web design as far as I can, which is better than most designers would do, but not as good as I want. The website really needs to sell the software. Now I am looking for a high-quality redesign, which I expect to cost a fair amount of money. I'm primarily looking at design firms in the SF bay area who have experience making AAA game websites.
     
    The community software will be updated to the latest version, which breaks our skin and other customizations. A new skin will be designed that will be similar but not identical to our current look.
     
    At one time, I tried to use IPB for everything, including commerce, a gallery, and downloads, but I don't think a CMS can be very good at all things. We're only using IPB at this point for the forum, blogs, and a few custom databases and pages. Steam is working well for screenshots, videos, and downloads (Workshop), and I use custom PHP scripts to retrieve and display that information.
     
    The beta branch of the editor has the Workshop home page set to the new location and everything should work without a hitch.
     
    The documentation is also being separated out into a different system that is better suited for that purpose, but that will take more time.
  14. Josh
    People are starting to use Lua, which is good. Initially there was some confusing, but in each case it turned out to be a small misunderstanding. I spent a few hours editing the wiki to add Lua syntax to the commands. I'm going to start working on Lua demos and more high-level stuff, in addition to fixing any bugs that exist. I'm not too interested in adding new features right now. This engine has plenty of features. Tons. It's time to use them to make something.
  15. Josh
    What an interesting first week. I compiled a C++ program for Android, made a programming language, learned about iPhone development, and figured out a lot of C++ stuff I did not know.
     
    It's nice to see that a port to Android will work pretty much like I was hoping. I just write an abstract driver for every system, and have specific drivers that extends that class:
    class GraphicsDriver {}
    class GL4GraphicsDriver : public GraphicsDriver {}
     
    Then when you have something like a surface that is dependent on the graphics driver, you do this:
    surface = GetGraphicsDriver().CreateSurface()
     
    And a GL4Surface object is returned. Of course, this is just the internal workings, and you will only have to call CreateSurface(). The GL4Surface is an extension of the Surface class, the same way the GL4 graphics driver extends the base graphics driver class.
     
    I would like to get something running on my HTC Evo, but the details of an Android, XBox, or PS3 version aren't too important right now. What is important is to get the C++ core done, in a way that makes it easy to add support for more platforms in the future. So as planned, you'll get a .lib file for C++, a .dll you can use with any language, and multiple Lua scripts can be attached to any entity.
     
    A roadmap of the development plan can be viewed here. I hope to accomplish most of stages 1 and 2 myself, and then recruit additional coders for the last leg. I don't intend to write the networking code myself, either. I figure it will be easier to develop streamed terrain from the beginning, instead of trying to tack it on two years from now, so I will see what I can do about that. I've never seen an infinite streamed world with the density and complexity I want, but Leadwerks seems to do best when we do really aggressive development:
    http://leadwerks.com/werkspace/index.php?/page/roadmap
     
    What I like best about this process is the code I write now is ForeverCode: It's good for any platform, and it will last for the life of the engine, which will be a very long time. I really can't imagine ever writing a version 4, because version 3 is being designed to be perfect.
     
    At this point I would like to thank Roland Stralberg, Mika Heinonen, and Ed Upton for their feedback and wisdom.
  16. Josh
    The last two weeks were mostly me wrestling with C++. I had promising results with a meta language that translates to C++ and compiles, and also learned how to create makefiles as a result of that. I tried CodeLite and CodeBlocks, in addition to MS Visual Studio. I finally settled on CodeBlocks.
     
    Codeblocks can be configured pretty easily to use GCC, the MS C++ compiler that Visual Studio uses, as well as about a dozen others (very curious to see if LE3 compiled with the Intel compiler is faster!) I prefer GCC with no optimizations for development, because it builds about twice as fast as the MS C++ compiler. Although I find Scintilla to be slow and somewhat poorly written, it's nice to have a cross-platform code editor. I can also configure Codeblocks to stop on the first error (it's actually a GCC compiler setting) and it automatically opens the file and selects the line the first error occurs on (CodeLite does not). Because I realistically expect to make thousands of coding errors during the production of LE3, it makes sense to streamline this highly repetitive task any way possible, and for that reason Codeblocks wins.
     
    The meta language made a promising start, and I may offer it as a product in the future, but it will not be used to develop Leadwerks 3.
     
    I've started on the OpenGL4 renderer. First I create the base renderer class, and established what the commands would actually do. Next I am going to create a window in Windows, set the pixel format, and initialize an OpenGL context. I've done all of these tasks from scratch in BlitzMax, but it's been a long time since I dealt with any of that.
     
    One of the most confusing parts for me was pointers versus references. In C++, pointers act pretty much like an object in Blitz3D: When you declare the variable, it's null, you create a new object and assign the variable to it, you delete the object manually when you are done with it. Now if you declare a variable that is a class, it creates it instantly and it can never be Null; it just exists. When the variable goes out of scope, it gets deleted/destructed automatically. This was pretty confusing until I realized that these objects are just like when you declare a float or integer variable. You don't worry about cleaning it up, because it only exists within the scope of the function it's declared in. You can never set an integer to Null, because it just exists; it doesn't get deleted. In the same way, a Vec3 variable doesn't need to be cleaned up or deleted; it just exists within the scope it is declared in. Therefore, it makes perfect sense for math classes like Vec3, Vec4, Mat4, etc. to always be used as a regular variable, and for complex objects like entities, materials, etc., to always be declared as pointers.
     
    I had another look at the Android SDK, and decided an Android game development would come in the form of a static lib for use with Java (or pure C++ if you prefer and can set it up). I'm cautious about the iPhone, but because Leadwerks is a code-centric development approach, I don't think we will have much trouble staying in compliance with the Apple EULA. I sort of understand Apple's strictness. I love my HTC Evo, but there's so much on it that just doesn't work. The app store is full of horrible crappy games. The App Installer even crashes on startup. iPhone gets Doom 3 by id Software, and Android gets 10 versions of Doom classic compiled by some kid, and none of them work. If Apple can deliver a good and consistent user experience, then I don't really have any problem with the restrictions they give developers.
     
    You can now add your SteamID to your Werkspace profile and display your Steam status. It may help a few people to join up for some fun multiplayer challenges, but I am mostly interested in learning about the multiplayer features Valve has implemented in Steam. Join the Leadwerks Developer Steam Group and be sure to keep a couple games in your wishlist. Thanks to HurrBeDragns for reserving the URL for me!
     
    I want strong multiplayer support in LE3, and I like some of the things Valve has done. In LE3, all entities can be saved to a binary file format. We have learned how troublesome serialization can be, so we won't be using that, but this binary file format can be used for prefabs, and even for syncing entities over the network. I've already had success specifying an entity should be synced over a network. It's really nice to have everything just work automatically. I'm in favor of just letting the server handle all interaction, with no client-side prediction because: 1. client-side prediction is inaccurate and wrong, 2. It was originally designed for 56k modems, and 3. Onlive has proven that player response lag can be minimal even when streaming graphics in real-time. The design I used in the multiplayer tests I conducted a few month ago was certainly good, and the results were responsive enough as long as the players were on the same continent.
     
    The platforms I am most interested in are Windows and MacOS, now that the new iMacs are shipping with decent graphics cards. The GPUs the new iMacs come with range from an ATI Radeon 4670 up to a Radeon 5750. By following the ATI/NVidia rule and dividing the number of ATI stream processors by 5, we can deduce these cards to be the equivalent from about an NVidia GEForce 8600, to a bit better than a GEForce 9800 GTX. This is definitely within the range of Leadwerks hardware requirements, so I look forward to developing for MacOS in the near future. And it's a good excuse for me to get a 27" iMac. I did not like the direction Microsoft went with Windows 7, and the new OS has finally put me in a place where I am willing to try something new. That never would have been this case in the days of Windows XP. Just so you know I am not turning into a total Apple fanboy, it is funny they make a big deal out of having a separate graphics processor...I had a 3DFX card in 1997, and they are only now catching onto the idea of dedicated GPUs!
     
    That's pretty much it for now. Stop on by the Asset Store and grab the Industrial Cargo Model Pack for only $9.95 before the price goes up tomorrow.
  17. Josh

    Articles
    You probably have noticed that our entire community has been migrated from the leadwerks.com domain to our new ultraengine.com domain. In this article I am going to describe recent changes to our website, the process by which these decisions were made, and the expected outcomes. These are not just superficial changes, but rather it is a fundamental restructuring of the way our business works. This is the execution of a plan I have had for several years.
    When we first starting selling on Steam and I saw the revenue it was bringing in, my reaction was to focus entirely on Steam and try to align everything we did to that. The idea was that if I could bring that advantage to you, we would all benefit from the massive gaming traffic that goes through Steam. I replaced many of our community features with Steam-centric equivalents. Our website gallery, videos, and downloads were replaced by the Steam equivalent. To view this content on our website I used the Steam web API to hook into our application ID and retrieve content.
    The screenshots and videos were a success. Leadwerks Editor allows publishing a screenshot directly to Steam, and we have gained a very big collection of screenshots and videos on Steam. However, there are two problems that have caused me rethink this approach:
    First, when it came to monetization, Steam seems to be a one-trick pony. Try as I could, Steam users just don't buy things through Steam Workshop. Our own sales in the web-based Marketplace are outperforming Steam.

    Second, Steam has flooded their marketplace with new titles. This incentivizes competition for digital shelf space. Instead of investing in Steam features for one application ID, it makes more sense to release multiple products on Steam and not tie yourself to one Steam application ID. Valve's position seems to be that you are responsible for driving traffic to your game, but if that is the case why are they still charging 30%? Our situation on Steam is still good, but I am not throwing everything 100% into Steam in the future and I prefer to drive traffic to our store on our own website.

    Based on what I have seen, it makes sense to move our center of activity back to our own website. Recent technological advances have made this easier. Cheap file storage backend systems have eliminated the expenses and technical problems of storing large amounts of user data. RSS feed importers have allowed us to hook into the Steam web API to feed all our Steam screenshots and videos into our own system.
    Videos
    We have a new video section on our site. You can paste a YouTube link through our web interface or upload a video file directly. Any videos you publish on Steam will be automatically fed in as well. You will notice in the tutorials section I am now hosting tutorial videos on our own site. They are also uploaded on YouTube, but I am not relying on YouTube anymore for video hosting.

    In the future I plan to support user-created paid video tutorials, with the same rules as paid items in the Marketplace.
    Gallery
    A new screenshot gallery is up, with images hosted on our own site again. I hope to find a way to migrate all our content on Steam into this system, like we did with videos. I also want to bulk upload all our old screenshots from before Steam.
    The Steam-based gallery and videos can still be viewed on the leadwerks.com website, as well as the Leadwerks documentation.
    Marketplace Games
    The Marketplace we have now is a 2.0 version of our original system before Steam, with a new Games category. Back in the days before Steam it always amazed me that Furious Frank had over 20,000 downloads. This was from the days before itch.io and gamejolt, and there was a big appetite for indie games. The Games database of our website never reached that level, and I think the reason was that we should have focused on the content. If people want to watch videos they will go to the videos section. If people want to download free games they will go to the Games category in the Marketplace. Having a customized page on our website with a lot of information and links all in one place is about as pointless as having a Facebook fan page. There's no reason for it, all it does is slow down the delivery of the actual content. It looks kind of cool, but I think the viewer just wants to get to the content (download the game, watch videos, view screenshots) instead of wading through a lot of custom CSS pages. If you want to drive traffic to your website or to your Steam page, post a video and put links in the description where you want the viewer to go next.
    In addition to uploading free games, you can now sell your games in the Marketplace. I have plans to attract a lot of new traffic to the site in 2021, so maybe your games can get more sales at the same time. The same 70/30 split we use for Marketplace assets applies to games.
    Furious Frank is starting over from zero and I realize he would have been enjoyed by over 100,000 players had I not pushed our traffic towards Steam so hard.
    Email Marketing (and leaving social media behind)
    At a startup event I attended years ago, one of the speakers told me that email was actually their best marketing tool. I was kind of surprised because to me it seemed archaic, but that conversation stuck in my mind. According to conventional wisdom, if you want to get the word out about your product you should crete an Instagram account, upload your images, and then when you invariably get no traffic you should blame yourself because your content sucks. Who is pushing this "conventional wisdom"? It is being pushed by giant tech companies that seek to absorb and monetize all your content, and a network of parasitical "gurus" who want to sell you useless advice and then blame you when it fails. This is not the way online customer acquisition actually works.
    I started looking at traffic on our social media accounts and comparing it to email and web traffic, and the results are shocking. Our email newsletters regularly result in 30x more clicks than anything I write on social media. Not only are they failing to bring in an acceptable level of traffic, Twitter and even Steam are actively preventing us from reaching our customers by censoring our content.
    Email is the only direct line of communication you have with your own customers. All third-party middlemen have the potential to abuse their position. They will flood their marketplace with products, change their algorithms, arbitrarily censor or shadowban content. The only thing that will provide a counterweight to that abuse is a good BATNA. If you don't have that you can expect to be treated badly. (It's really a miracle that email was invented early enough to become a common open standard. This would never happen today. "Blue Sky" is probably a sabotage effort.)
    In that light, the advice I got makes a lot of sense. Once I realized this I stopped posting on Facebook and Twitter and just left a pinned message directing people to the mailing list:

    Our new website also features a mailing list sign-up form featured prominently in the website footer.

    Instead of wasting time shouting into the wind on (anti)social media I am going to instead focus on writing quality articles that will be posted on our site and sent out to the email list.
    Store
    Valve has made it clear that game developers should not rely on Steam alone to drive traffic to their game. Okay, well if I am responsible for bringing in traffic, I am going to direct it to my own store, not to Steam.
    The MBA in me realizes two things:
    Getting a user's email address is good and has a quantifiable value. Getting a user's credit card system stored in our system is even better. (It doesn't actually store credit cards on our server, it stores a token that can only be used with our domain.) These two steps are serious hurdles to overcome for any web store. Now that I am selling Ultra App Kit directly on our own site, I have seen an increase in sales of items in our Marketplace. This is not a coincidence. People buy one thing and then it becomes a habit. A subscription option will be available for future software products. All new software I release is going to require an initial sign-in to your forum account. We have tens of thousands of users on Steam that I have no email addresses for or ability to contact, and that is not going to work going forward. (I will make sure an override is built into the software that can be activated by a dead man switch.)

    This system gives me the ability to offer software products under a subscription model for the first time ever. This is preferable from my point of view, but I understand it's not for everyone and a conventional software license will also be available.
    We also have an automated system to send out Steam keys, so I am now able to sell Steam keys directly in our store. When you order you will receive an email with a link to retrieve your key. Once you enter the key in Steam it is added to your Steam account just as if you bought it on Steam.
    To make payments easier we are now accepting PayPal and cryptocurrency payments, in addition to credit cards.
    (Valve clearly recognizes a problem with visibility on Steam and is desperately trying to convince you to stay engaged in their system so they can take their 30%. I don't mean to say they are bad guys, I am just saying in any partnership both parties will have some divergent interests and must stick up for themselves. The day that mine is the only company selling products on Steam is when I will consider going Steam-exclusive again. What indie developers should be doing right now is selling their own games on their own websites, in addition to third-party stores like Steam.)
    Rolling Out Ultra Engine (Leadwerks 5)
    Breaking off the GUI features of the new engine and releasing it early as the standalone product Ultra App Kit was a great idea because it allows me to implement all these things early, test them out, and ensures a smoother release of the finished 3D engine later this year. The basic theme we see here is that these social and gaming platforms are no longer doing their job effectively and we must build something of our own. Withdrawing our content from them and building up our own website only makes sense if there is a way to drive more traffic here. If Steam is flooded and social media is saturated, how can we attract traffic? Email is good for engaging customers you have already made contact with, but how do you attract new people in large numbers? I have an answer to that, but it really deserves a whole article itself.
    Conclusion
    Here is where we were before:
    Domain name no one could pronounce or spell. It was literally impossible to tell someone to go to our website without explaining the spelling. User content hosted on Steam and YouTube Almost all sales through Steam Ineffective outreach through social media Single product for sale with perpetual free upgrades No ability to collect customer information Here is where we are now:
    Domain name that can easily spread by word of mouth Most user content hosted on our own website Direct sales through our own website and many third-party stores Effective outreach through email (and other means I will talk about later) Ability to sell annual paid updates or subscription model Growing customer database of people I can directly contact I hope I have shown how all these changes were not just random decisions I made, but are part of a "holistic" strategy, for lack of a better word.
  18. Josh
    Well, this is our new community site. I've wanted something like this for a while, and finally found a way to do it. We've got blogs, a gallery, customizable profiles, and yes, a forum. I was unsuccessful in my attempt to migrate the data from PHPBB, so the old forum will be left intact as an archive. I really like this new system. It's not just a forum, it's a social netwerking site!
     
    If you register an account and aren't able to access all the goodies, please be patient while I enter account information. There's a lot of work to do this week, and it will take me a while to get everyone's accounts set up correctly.
     
    Oh yeah, my old blog can be found here:
    http://leadwerks.blogspot.com
     
    There's lots of interesting stuff there, so check it out!
  19. Josh
    I'm pleased to announce the return of the much-beloved header banners. They now scale across the width of the page, similar to the profile images on Twitter and Google+.
     
    To add a banner image of your own, click the ]submit a banner link in the site footer. I recommend JPEG images with a resolution around 1920x300. However, your image dimensions do not have to be exact, as the image will be scaled and trimmed to fit the space.
     
    You can also add an optional URL to link the banner to. If this is entered, the entire banner will become a clickable link that drives traffic to your page.
     
    Once banners are submitted, they will go into a queue for approval. Approved banner images will appear the rotation.
  20. Josh
    This is the final output of Leadwerks 3 on Windows.
     
    When you choose "Windows" in the Publish dialog, a few options appear. Press OK and your game's installer is created.

     
    The installer looks like this. You can replace the installer images with your own if you like:



  21. Josh
    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.
  22. Josh
    Here's what's next for Leadwerks Game Engine.
     
    Game Launcher
    Leadwerks Game Launcher will be released in early preview mode when 50 games are reached. Right now we have 13. Filling the content up is a high priority, and the Summer Game Tournament will bring us closer to that goal.
     
    I am mentioning this first because I want to emphasize that the number of games posted is my measure of how well I'm doing. Every action should be considered in terms of how it helps you guys publish more games.
     
    Usability Improvements
    Since the learning process for Leadwerks is now very well defined, we're able to identify and improve minor hiccups in the workflow. I'm getting a lot of great feedback here. The tutorials have helped y giving us a common reference point we can use to communicate how things should be done, and what can be improved.
     
    Documentation will continue to be improved as we gain more experience. I am holding off on recording any videos until we get the materialize finalized.
     
    Here are some of the things I want to modify or improve:
    New icon set
    Improve 3D control widget
    Use name in script entity field instead of drag+drop
    World:FindEntity() Lua command
    Revert material editor texture list to old style
    Implement web browser in Linux GUI for welcome page and Workshop.
    Add built-in help window for better documentation layout (will still pull data from online pages)
    Improve project manager and new project window, using web interface.
    Research is being performed on improvements to the script editor.

     
    Game Templates
    The 2D and 3D platformer templates are the easiest to make and are good examples for learning. These will likely come next. A racing game template is fun and simple, and may come after that.
     
    DLC
    A soldier pack would add a lot of new options to gameplay. We saw with the zombie pack that many people were able to use these items in a lot of different ways, and it added a lot of depth to gameplay. I think a soldier pack with characters that can fight against or with the player, or against zombies, each other, etc. would be a great addition.
     
    New Features
    I make decisions on new features based on the following question: What will result in more games? The things I think are important are a vegetation system like Leadwerks 2 had (but better), decals, and some built-in GUI commands. It is likely that the vegetation system will be the next big feature.
     
    Built-in Model Store
    We have some setbacks on this, but we're researching another way to make this happen.
     
    That's quite a lot of different stuff.
     
    As always, any of these items are subject to change.
  23. Josh
    I think of the Leadwerks community as a big loosely affiliated collaborative game studio. I see people working together to add value in different ways. Some are dedicated to a single project, and others bounce around and participate in different projects. I like that everyone can just find what they like doing best and provide value in that way.
     
    Voluntary collaboration, without being too restrictive, allows us to achieve economies of scale, while diversifying risk. Basically that means it's more cost-effective to batch some things together, like promotion and content production. At the same time, we remain innovative and keep taking risks with new ideas.
     
    We're going to build Leadwerks into a series of educational materials and services that is capable of taking any person of reasonable intelligence and commitment from total noob to professional game developer. I want to have a well-defined series of lessons that once completed, tell you everything you need to know to program games, design artwork, or manage a team of developers working on a title. Leadwerks can help with promotion and distribution. You'll see a lot more of this idea with the Leadwerks Workshop on Steam.
     
    The steps below plot the progress a Leadwerker goes through as they gain xp:
     
    Education
    Tutorials and documentation

    Collaboration
    Communication tools on Leadwerks.com
    Steam Workshop

    Promotion
    Games page
    Leadwerks feeds and social media accounts

    Distribution
    TBA

     
    I think more can be done in each of the areas above as we continue to grow. Just some thoughts this evening.
  24. Josh
    Leadwerks Engine 2 is single-threaded. The engine performs one task at a time. The engine updates physics, then performs some other tasks, then renders the scene, waiting until each task if finished before moving onto the next one:

     
    I have experience programming threads in BlitzMax, and it works pretty much the same way in C++. Leadwerks3D is taking full advantage of threads and multicore CPUs, splitting off any expensive tasks that can be run on separate threads.
     
    Multithread programming is a little different than linear programming, and you just have to design things carefully. It's okay for two threads to read a variable at the same time, but if they both try to write to the same variable, or one writes while another reads, you will have major problems. This is made harder by the unrestricted nature of Leadwerks, because the end user might call any function at any given time, and I don't want to make arbitrary rules like "You can't modify surfaces during the main game loop".
     
    Mutexes (short for mutually exclusive) are a way around this, as they lock sections of the code to prevent multiple threads from accessing them at the same time, but I try to avoid using them. It's extremely difficult to find all the parts of your code that might need a mutex locked. Also, when you start using mutexes liberally, you lose all the benefits of concurrency, because the threads have to stop and wait for each other. I prefer a design where you gather data for a thread, run the thread without interacting with any other parts of the program, and then get the results a few frames later, or whenever the thread finishes processing.
     
    Multithreading has some big benefits for the new engine.
     
    Physics
    Physics in Leadwerks3D are asynchronous, meaning that while the engine renders the scene and executes your game code, it's already calculating the next frame of physics on a separate thread! The diagram below shows how the physics get split off onto its own thread, then split into many threads by the solver, and the two threads meet again the next frame. (It's actually more complicated than that, the engine just keeps running until 16.667 milliseconds have passed, then it waits for the physics thread to finish, if it hasn't already.)

     
    Let's say our ideal framerate is 60 FPS, which means our target frame time is 16.667 milliseconds (=1000/60). Whereas before a physics processing time on a single thread of 10 milliseconds would eat up 2/3 of your ideal frame time, now you can have physics that take up to 16 milliseconds, and have no performance cost for a program that is otherwise running at 60 FPS. Below you can see 5000 bodies falling at near real-time speeds:

     
    NavMeshes
    Navmesh generation is a slow process. However, it does not need to be instantaneous. This makes navmesh recalculation perfect for multithreading. As you can see in this video, the obstacles can move around and the AI navigation will react dynamically to the environment. I've never seen a game with dynamic environments like this, so we are breaking totally new ground. As CPU core counts rise the engine will be able to use those cores to handle more complex maps and greater numbers of characters. In the meantime, it will perform well on any dual-core mobile device!


     
    Rendering
    Rendering in Leadwerks3D will split culling up among threads to take advantage of multiple CPU cores. This is not yet implemented, but it's a little easier than physics and navmesh threading, since it doesn't run concurrently to the main engine thread.
     
    Below is a diagram showing the complete threading design for the engine:

     
    Multithreading in Leadwerks3D is all done automatically behind the scenes, so you can still program however you want, without fear of interfering with other threads.
  25. Josh
    UML diagrams, object-oriented frameworks, and beautiful modular architecture are great things to develop, but sometimes you just need to make an application that real people can use. For me, that means you start with the behavior you want, and work backwards to make the code that does it. In the past I've considered fancy object-oriented mouse tool classes, but the style of editing I want is intuitive, easy, and fast, using the fewest number of mouse clicks possible to achieve a task. I think that's why so many people loved 3D World Studio, and it's a quality I want to retain in the design of the Leadwerks3D editor.

     
    I now have basic CSG editing working. The code that does this is a little more event-oriented spaghetti than the engine core, but sometimes that is appropriate. I can't wait to start working with a CSG editor again, with new features like smooth groups. Drag and drop materials onto objects is already working, and it feels so intuitive and pleasant to use. This is the stuff I programmatically live for.
×
×
  • Create New...