Jump to content

Evolution

Josh

689 views

This is a good time to write about some very broad changes I expect to come about over the next year in our community as our new engine "Turbo" arrives. Turbo Game Engine, as the name suggests, offers really fast performance using a groundbreaking Vulkan-based renderer, which is relevant to everyone but particularly beneficial for VR developers who struggle to keep their framerates up using conventional game engines. I want to help get you onboard with some of the ideas that I myself am processing.

Less emphasis on how-to tutorials, more emphasis on API documentation

The new engine assumes you are either an artist or a programmer, and if you are a programmer you already know basic C++ or Lua. More attention will be paid to precisely documenting how commands behave. There will be a more strict division between supported and unsupported features. There will be less "guessing" what the user is trying to do, and more formal documentation saying "if you do X then Y will occur". For example, every entity creation function requires the world object be explicitly supplied in the creation command, instead of hiding this away in a global state. There will not be tutorials explaining what a variable is or teaching basic programming concepts.

More responsiveness to user requests, especially for programming features

Leadwerks 4 features have been in a semi-frozen state for a while now. Although many new features have been added, I have not wanted to create breaking changes, and have been reluctant to introduce things that might create new bugs, because I knew an entire new infrastructure for future development was on the way. With the new engine I will be more receptive to suggestions that make the engine better. One example would be an animation events system that lets users set a point in an animation where an event is called. These changes need to be implemented within the design philosophy of the new engine. For example, I would use an Actor class method to call the event function rather than a raw pointer. Emphasis should be placed on what is practical and useful for competent programmers and artists, and how everything fits into the overall design.

Less attempts at hand-holding for new developers

The new engine will not attempt to teach children to make their own MMORPG. Our marketing materials will not even suggest this is possible. The new engine will deliver performance faster than any other game engine in the world, period. Consequently, I think the community will gain a lot more advanced users, and though some of them will not even interact on the forum I do think you will see more organic creativity and quality. In its own way, the new engine actually is quite a lot easier to work with, but the sales pitch is not going to emphasize that, it will just be something people discover as they use it. I love seeing all the weird and cool creations that comes from people who are completely new to game development, but those people were new to game development and did well with Leadwerks had a lot of natural talent. Instead of trying to come up with a magic combination of features and tutorials to turn novices into John Carmack, we are going to rely on the product benefits to draw them and expect them to get up to speed quickly. Discussions should be about what is best for intermediate / experts, not trying to figure out what beginners want. Ease of use is subjective and I feel we have hit the point of diminishing returns chasing after this. If beginners want to jump in and learn that is great, but it is not our reason for existing.

Stronger focus on the core essentials

At the time of this writing, there are only eight entity types in the beta of the new engine. We can't win based on number of features, but we can do the core essentials much better than anyone else. Our new Vulkan renderer offers performance that developers (especially VR) can't live without. Models, lights, and rendering are the core features I want to focus on, and these can be expanded by the end user to create their own. For example, a custom particle system with support for all kinds of behaviors could easily be created with the model class and a few custom shaders, without breaking the performance that makes this engine valuable. Our new technology is very well thought out and will give us a stable base for a long time. I am planning on a plugin / extensions system because its best for this to be integrated in the core design, but you should not expect this to be very useful for a couple of years. Plugin systems require huge network effects to offer anything valuable. We can only reach that type of scale by offering something else unique that no one can match us on. Fortunately, we have something. It's right in the name.

More formal support for good standards

Vulkan has turned out to be a very good move. I don’t think anyone realizes how big a deal GLTF support is yet: you can download thousands of models from Sketchfab and other sources and load them right now with no adjustments. I may join the Khronos consortium and I have some ideas for additional useful GLTF extensions. I'm using JSON for a lot of files and it's great. DDS will be our main texture file format. There are more good standards today than there were ten years ago, and I will adopt the ones that fit our goals.

Different type of new user appearing

With Leadwerks, the average new user appears on the forum and says “hey, I want to make a game but I don’t really know how, please tell me what I need to know.” With the new engine I think it will be more like “hey, I’m more or less an expert already, I know exactly what I want to make, please tell me what I need to know.” I expect them to have less tolerance for bugs, undefined behavior, or undocumented features, and at the same time I think it will be easier to have frank discussions about exactly what developers need.

In very general terms that is how I want to focus things. I think everyone here will adjust to this more strict and well-defined approach and end up liking it a lot better.

  • Like 6


15 Comments


Recommended Comments

I love everything here a lot! Can't wait to ditch other stupid engines for this one!

Share this comment


Link to comment

I hope that turbo has some sort of tool development framework using the editor gui in c++ so that we can create our custom tools for the type of game we need and our editor tool can help us speed up the development process, I think turbo's speed should not only be limited to performance as sales pitch, it should also be linked to speedup of development processes, and the editor toolkit can be a good indicator towards it. This editor tool development system might be linked to plugin system. I am pretty new to leadwerks just purchased it this past saturday and on one day of use, I think this is the feature I missed in it. Keep in mind that I am coming from an experienced game developer perspective.

Share this comment


Link to comment

While I think we should have less tutorials, example content is a must. I myself learn things by looking at examples, and then modifying those samples to make it do what I want it to do. Samples should both be freely available and on the market place.

We should also have a tutorial on the editor, and where everything is/what it does. But otherwise I agree; no "How to make an FPS shooter" this time. Give them a template and let them be creative. 🙂

Share this comment


Link to comment
2 hours ago, m.yuneeb90 said:

I hope that turbo has some sort of tool development framework using the editor gui in c++ so that we can create our custom tools for the type of game we need and our editor tool can help us speed up the development process, I think turbo's speed should not only be limited to performance as sales pitch, it should also be linked to speedup of development processes, and the editor toolkit can be a good indicator towards it.

I think this is the right idea and your expectations are realistic. A strictly defined API that exposes the editor internal structure to Lua, similar to MaxScript in 3ds max, would be very useful.

  • Like 1

Share this comment


Link to comment

I feel like a lot of what I wrote above is just us acknowledging what we are and not trying to be something different. I want this to be more of an advanced technology company.

  • Like 1

Share this comment


Link to comment

I think having a basic setup tutorial would be helpful (as getting a window and camera set up with your API isn't exactly standard), but beyond that, the only thing I'd want is for everything in the API to actually be documented and searchable. There are a lot of things within LW4 that are simply not in the documentation, and are things one would run into pretty easily when going beyond basic functionality.

Share this comment


Link to comment

No tutorials is ok providing the api examples are enough to get a beginner started. Gameplay coding comes easy to me, but not setting up code.

Share this comment


Link to comment
7 minutes ago, cassius said:

No tutorials is ok providing the api examples are enough to get a beginner started. Gameplay coding comes easy to me, but not setting up code.

That's exactly how I feel too. Creating a feature in C++ is easy, it's just finding the actual commands to interface with the API you're working with.

Share this comment


Link to comment

I don't feel like money is going to be a big problem in the future, which frees us to do what we really want to do.

  • Like 1

Share this comment


Link to comment
7 hours ago, reepblue said:

While I think we should have less tutorials, example content is a must. I myself learn things by looking at examples, and then modifying those samples to make it do what I want it to do.

I'm the same.  I gave up on the Leadwerks GUI because it's not documented and a question I asked wasn't answered clearly (and it's also more convoluted than I feel it needs to be.  I just want to put down a button and detect if it's clicked on.  This should be like 2 or 3 lines of code).

Share this comment


Link to comment

I think, undoubtedly a good tool must have good documentation. That is to say imagine that you buy a powerful appliance to use in your home and you don't see any explicit documentation about its respective functions.  I think it can ruin the product, it's just what I think. 

Now, the simple example is based on for example a C++, lua, or C# template, something very simple like creating a simple window. And the rest is left to the user's mercy when digging into the documentation structure, or asking questions in the community.  

Translated with www.DeepL.com/Translator

Share this comment


Link to comment
4 hours ago, aiaf said:

Btw the gui system will be available to turbo in a form similar to what we have now ?

Yes, although the idea of letting Lua run inside the rendering loop (for the drawing function) is definitely verboten in the new architecture. Instead it will use persistent 2D primitives that are created and managed by the script. Like instead of having a function that says "draw a rectangle here" the script will create a rectangle object with the characteristics it needs, and that will be sent to the rendering thread.

  • Like 1

Share this comment


Link to comment
1 hour ago, Josh said:

Yes, although the idea of letting Lua run inside the rendering loop (for the drawing function) is definitely verboten in the new architecture. Instead it will use persistent 2D primitives that are created and managed by the script. Like instead of having a function that says "draw a rectangle here" the script will create a rectangle object with the characteristics it needs, and that will be sent to the rendering thread.

Please make UI editor happen

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 reepblue in reepblue's Blog 0
      As you may have known, I've been dabbling with input methods for a while now using SDL2. Since then, I've learned how to do similar functions using the Leadwerks API. The goal was to make a inout system that's easily re-bindable, and allows for controllers to "just work". My first research of a goof system comes from a talk at Steam DevDays 2016 as they discuss how to allow integration with the Steam Controller. 
       
      My thought was: "If I can create my own Action System, I can bind any controller with any API I want". The SDL experiments was a result of this, but they ended up being sloppy when you tried to merge the window polling from SDL into Leadwerks.
      The next goal was to remove SDL2 out of the picture. I've created functions to allow reading and simulations of button presses with the Leadwerks Window class.
      //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- bool InputSystem::KeyHit(const int keycode) { auto window = GetActiveEngineWindow(); if (keycode < 7) return window->MouseHit(keycode); return window->KeyHit(keycode); } //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- bool InputSystem::KeyDown(const int keycode) { auto window = GetActiveEngineWindow(); if (window != NULL) { if (keycode < 7) return window->MouseDown(keycode); return window->KeyDown(keycode); } return false; } //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void InputSystem::SimulateKeyHit(const char keycode) { auto window = GetActiveEngineWindow(); if (window != NULL) { if (keycode < 7) window->mousehitstate[keycode] = true; window->keyhitstate[keycode] = true; } } //----------------------------------------------------------------------------- // Purpose: //----------------------------------------------------------------------------- void InputSystem::SimulateKeyDown(const char keycode) { auto window = GetActiveEngineWindow(); if (window != NULL) { if (keycode < 7) window->mousedownstate[keycode] = true; window->keydownstate[keycode] = true; } } The simulate keys are very important for controllers. for this case, we would trick the window class thinking a key was pressed on the keyboard. The only direct input we would need from the controller is the value analog sticks which I haven't touch as of yet.
       Using JSON, we can load and save our bindings in multiple Action Sets!
      { "keyBindings": { "actionStates": { "Menu": { "selectActive": 1, "selectDown": 40, "selectLeft": 37, "selectRight": 39, "selectUp": 38 }, "Walking": { "crouch": 17, "firePrimary": 1, "fireSecondary": 2, "flashLight": 70, "interact": 69, "jump": 32, "moveBackward": 83, "moveForward": 87, "moveLeft": 65, "moveRight": 68, "reloadWeapon": 82 } } } } You may want a key to do something different when your game is in a certain state. For this example, when the Active Action Set is set to "Menu", Only KEY_UP, KEY_DOWN, KEY_LEFT, KEY_RIGHT, and KEY_LBUTTON will work. You can still hover over your buttons with the mouse, but when it comes time to implement the controller for example, you'd just call GetActionHit(L"selectActive") to select the highlighted/active button. If the state is set to walking, then all those keys for Menu gets ignored in-favor of the walking commands. All keys/buttons are flushed between switching states!
      Here's example code of this working. "Interact" gets ignored when "Menu" is set as the default action and vise-versa.
      while (window->KeyDown(KEY_END) == false and window->Closed() == false) { if (window->KeyHit(KEY_TILDE)) { if (InputSystem::GetActiveActionSet() == L"Menu") { SetActionSet(L"Walking"); } else { SetActionSet(L"Menu"); } } // Under "Menu" if (GetActionHit(L"selectUp")) { DMsg("selectUp!"); } // Under "Walking" if (GetActionHit(L"interact")) { DMsg("interact!"); } } Only things I didn't implement as of yet is actual controller support and saving changes to the json file which might need to be game specific. I also want to wait until the UI is done before I decide how to do this.
      As for controllers, we can use SteamInput, but what if your game isn't on Steam? You can try to implement XInput yourself if you want. I tried to add Controller support with SDL2, but people reported issues. And then, what about VR controllers? What matters right now is that we have room to add these features later on. All I need to do is use the GetActionHit/Down Commands and the rest doesn't matter.
    • By reepblue in reepblue's Blog 5
      There has been some discussion regarding on how to set collision shapes for your models. For 95% of models, you should be building shapes with the Model Viewer as described here. In some cases, the model artist might want a custom shape to be made. In this post, I'll be going over how I import models into Leadwerks, and building custom shapes.
      A few notes first. I use Blender; Blender 2.79b to be exact. I haven't get got the hang of 2.80 and until the new engine's art pipeline is fully online, I don't see a use for it. Leadwerks 4 uses Blinn-Phong rendering so the PBR stuff makes no sense for Leadwerks 4. So for this, I'll be posting screenshots from 2.79b. I should also mentioned that a feature I use in my process isn't present in the Linux build of the editor, which is the collapse tool. (Tools->Collapse). Doing the collapsing via a terminal will cause the models to crash the editor. This seems to be a known bug, as you don't see that feature in the Linux editor.
      Lets say you created a tube model such as this one and you want the player and objects to go into the tube:

      If you tried to make a shape doing the Concave settings, not only it'll be really slow to generate, but the results will not be good. We could make a shape based on the wire frame, but this is a high poly model. What we need to do is make a new mesh, import both models  to the editor, collapse them both, build the shapes for both, and delete the low poly model while making the high poly read the low poly's generated shape.
       
      First to get it out of the way, apply the scale and rotation of the model. This will make Y forward and the scale will be (1,1,1) when you import it into Leadwerks.

       
      Next we need a low poly model.

      This is the same proportions as our high poly. Apply the scale and rotation as the same as the high poly. I also set the max draw time to solid, but this is optional.

      Next, name your High poly and the low poly you're going to be using for the shape appropriately.

      Now lets, export each object as a FBX. For this my high poly is going out as tube.fbx, and my low poly shape is going out as tubeshape.fbx. Here are my export settings:

      If you saved the files in a Leadwerks project while the editor was opened, the editor would have auto convert the files to the .mdl file format. Open the high poly model (tube.fbx) and first collapse it and give it any shape. (Give it a box shape to save time.) you need to assign a shape to the high poly so the mdl file is linked to a phys file. Do the same with the low poly, but you're gonna set the shape as poly mesh.


      Close the model viewer, and then go into the directory where the models are placed. We are now going to delete the box shape of our high poly, and trick it into loading the low poly shape by renaming the shape file of the low poly to be what the previous shape of the high poly was. In other words, we are making tubeshape.phy into tube.phy.
      Before:

      After:

      Notice the time stamp and the size of tubeshape.phy from before being the same as tube.phy in the after screen cap. This should be your end result.

      Notice that the shape isn't sold but now a tube. Objects can go into the tube with no issues. Now, there is another way that uses limb names to generate physics automatically. However, there are a lot of issues I came across using this method such as the shape not being parented to the model when the model moved via physics or a joint. With this way, you have a custom shape, the model is optimized because it doesn't have any children nodes, and everything is clean and tidy!

       
    • By 💎Yue💎 in Dev Log 5
      The prototype is finished, and the mechanics of the game can be given way.  It has established a desert terrain in the form of dunes, this implies that there are no cannons or anything similar, because Leadwerks does not allow a terrain to cast shadows on that same terrain and this looks visually rare.
      So the terrain is like low-slope dunes. On the other hand, I think the texture of the terrain is already the definitive one, with the possibility of changes and suggestions on the part of those involved in this project.
      On the other hand we have taken the model of a habitat of the nasa, which certainly looks very nice. 
      The next steps, are to establish the starting point of the player, this must start near the capsule return to Mars somewhere on the map of 2024 x 2.
      And think about the first thing you should do, repair your suit? Seek a shelter? things like that.  


×
×
  • Create New...