Jump to content

Leadwerks is so cozy

tipforeveryone

413 views

I spent a whole week for learning UE4 with cpp, yep, UE4 is a great engine for sure, but I found out that my mind could not understand the way UE4 works easily. It is too complex and made me tired. Then I returned to my Leadwerks project and felt so familiar. Soooo... sweet, everything is simple as it is

It felt like I have had a long trip to UE city then return to my hometown. I miss Leadwerks indeed.

Last year, I thought I could only use Leadwerks with LUA and never touch its CPP side. But I tried my best, learned Cpp for 8 months. Now I am not a cpp pro but I am confident in using this language. At least I can rewrite my whole project in CPP instead. this 3-years project helped me to understand my potential and interest in gamedev.

I wish Josh be successful in progress of making Turbo, a new hope for much better Leadwerks.

To all people who are using Leadwerks and help me these years, love you.

...

Peace!

  • Like 2


15 Comments


Recommended Comments

I too use cpp and although a bit shaky in understsnding classes I managed to make a couple and all is going well .I like your post.

  • Like 1

Share this comment


Link to comment
On 10/7/2019 at 4:32 PM, Slastraf said:

there are still some bugs here and there that just drain your motivation always a bit

This exactly.  There have been quite a few show-stopping bugs for me too.  A character controller that was buggy that still isn't completely fixed (though Josh tried), navmesh generation by code that is broken on large maps (though navmesh isn't even dynamic so it doesn't support basic things like doors opening), glitchy vegetation, broken vehicles, etc.  I used to start a game with fingers crossed that things will be OK.  Now I mostly just use Leadwerks for its clean C++ commands, renderer and simpler projects.  I don't try to do anything fancy.  If I did this for more than a hobby, as much as I love Leadwerks and have been a fan and active community member since version 2.x, I would use another engine as well.

On 10/7/2019 at 4:32 PM, Slastraf said:

I am not a friend of monthly subscription payment for Turbo

As far as I remember, the subscription model may only be here for the beta.  There was talk about it being a one-time purchase on release but I don't think a final decision was made.

  • Like 2

Share this comment


Link to comment

I like this thread because we speak about motivation to make a game with Leadwerks and I'm feeling I'm loosing this motivation too.

But not because Leadwerks, because the few bugs you are speaking about can be often walk around (make your own character controller, set the tree a far away to avoid or forgive the pop up effect ...)

I would encounter the same problems I discovered with an other engine too;

The difficulty is the main problem for me, because you should have a team of workers because it is so much work to finish a game properly. Or you need years of work and motivation, with job and family, it is quite impossible, is it ?

Secondly - and the biggest thing for me -  I personally can't hope anymore that people will play my game, supposing the game would be funny, finish and playable.

Why this ? Because this game would fall in an infinity of other indie games and as Hobby game maker I have no resources to make an effective advertising.

There is an ocean of games that are inviting players in all sort of different kind of scenes possible, and you need a great idea nobody does, if you want your game not fall anonymous.

Maybe I would reach a number of hundred players, well, is this really 10 years work worth ?

I'm still working on my dream game but only because I like the challenge to make it. That's enough, but the motivation to finish it may lacking because if you are not ubisoft today, you just have almost no chance anyone notice your game.

It is just like art. If you have abilities to draw, it is fine, and then you see on pinterest that other million people have the same ! lol

 

  • Like 3

Share this comment


Link to comment

To play devil's advocate as you have: you don't need a team to make a great and successful game.  A lot of people fall into the trap of wanting to make the next World of Warcraft or Call of Duty or whatever.  You need to either seriously reduce your scope or accept that you won't finish your game (as you seem to have done).  There have been a ton of single-man developers and especially two-person teams that have been wildly successful.  Also, if you have money, you can always hire artists, musicians, coders and others to help.

To address your second point, yes, there's a good chance that not many people will play your game.  Even completed, far more games fail than succeed.  That's the nature of the business.  It happens to big companies too.  Then there are random little games like Minecraft that one person starts as a hobby, shares on a forum or two, the community goes wild and the game makes millions.  There are a ton of factors that contribute to this but a big one seems to be that you're connecting with your fans early on.  Minecraft and Spelunky (original) were released early as hobbies and communities enjoyed them and it grew from there.  Then there are companies you can hire (somewhat like publishers) that can work on getting your game out there for you (just be careful of shady ones that demand too much - I've seen devs screwed over).  How much of the marketing side have you read up on and tried implementing?

  • Like 1

Share this comment


Link to comment

I don't want to "advocate" anybody if not what I'm feeling ;)

No you may not need a team but then time. It s not easy near family and job.

21 hours ago, gamecreator said:

Minecraft and Spelunky (original) were released early as hobbies and communities enjoyed them and it grew from there. 

Yes that's the best way that may happen, isn't it ?

21 hours ago, gamecreator said:

How much of the marketing side have you read up on and tried implementing?

lol about...nothing. I wanted to tell I'm not the person for this. I just don't feel good by advertising.

furthermore I have no game ready to sell !

I like the challenge of scripting, animating, seeing things becoming harmonious on the screen, and, if I would succeed to make a bigger project, I would be happy other would play this.

But sorry I'm not the person for that, like I'm lacking in this ability to present things like a customer must think "I want to try it".

There are people (sometimes include ubisoft too ;) ) that are so good in this that they can sell sh!t for a so good thing, that customers will be disappointed.

Like a little bit seems to be happened with breakpoint ghost recon.

  • Like 1

Share this comment


Link to comment
2 hours ago, Marcousik said:

I wanted to tell I'm not the person for this. I just don't feel good by advertising

...

I'm not the person for that, like I'm lacking in this ability to present things like a customer must think "I want to try it".

That's fair.  It's not for everyone.  I prefer developing to advertising too.  But the more people you want to play your game, the more you have to get out there and show it off and remind people what you have going on.  If you never share your game, you'll never get others to be interested.  And it's good to see it that way too.  Sure, some people won't care and won't want to play it.  That's normal for every game, indie or AAA.  But others will.  And those are the people you focus on, who want to hear from you, assuming you have interesting progress to show.  Just be honest about what the game is and what the game isn't.

  • Like 1

Share this comment


Link to comment
2 hours ago, gamecreator said:

And those are the people you focus on, who want to hear from you, assuming you have interesting progress to show.  Just be honest about what the game is and what the game isn't.

That's a nice phrase!

One problem remains (of course I know you are not my Psy but thx for reading yes 👍)

I'm stil having problem to believe I could make a game better than an AAA perhaps existing yet.

Looking at Witcher, GTA, Watch dogs, greedfall, Gothic and so much more other "perfect" games I think there is no reason why anybody should play my game !

  • Like 1

Share this comment


Link to comment

Try not to compare your game to those of AAA studios who have dozens of workers and millions of dollars to spend on development and marketing.  Your situation is different.  But just because a game is smaller doesn't mean it can't be popular.  There are a lot of single-man or small-team developers who have had hundreds or thousands of players, some having made millions.  Even a relatively simple game like VVVVVV sold over a million copies.  Sure, you won't make the next GTA or Witcher because you don't have the resources but you can still make a similar, enjoyable game.

  • Like 1

Share this comment


Link to comment

People wanted a new engine so I am making a new engine. It takes years to develop these things. Just switching over to Vulkan took six months to get basic rendering working. Anyone who needs the performance and scale of the new engine is welcome to use it, otherwise I am not going to try to convince them.

I expect that right now is going to be pretty much the lowest point of engagement because we have a new technology that has been a WIP for several years and isn't ready yet. And there is going to be some change in the community because Turbo Engine has a different type of user than Leadwerks has.

  • Like 1

Share this comment


Link to comment
14 hours ago, gamecreator said:

Even a relatively simple game like VVVVVV sold over a million copies.

I think that's more or less the idea I wanted to speak about. 

No matter the engine (if it is stable enough of course - and I think LE 4.6 is) you can make a fun thing that other people can enjoy.

All the challenge is to be creative, finding something fun. Because so much content has been made yet. An re-making games other did better yet gives no motivation.

And so the choice of the engine you want to work with has to be in the same line as your game concept requires. If not you are losing your time.

It's like in making music, I can buy more and more instruments (like features or assets) pretending I could do better with, but in reality if I do not master them or just find a good use of them, it stays nonsense. The point is the tools have to serve the ideas, and not the ideas the tools. That could be the reason why for my part and for now I don't need another engine.

  • Like 2

Share this comment


Link to comment

Well I already find it a little comedic that my comment criticizing LE game engine got removed so I cannot partake in this discussion. Honestly its kind of sad.

  • Confused 1

Share this comment


Link to comment
4 hours ago, Slastraf said:

Well I already find it a little comedic that my comment criticizing LE game engine got removed so I cannot partake in this discussion. Honestly its kind of sad.

Since you say it is not acceptable as a professional tool, why are you here? I just received ten orders for the enterprise version from a little company called Northrop Grumman, but I guess you are the expert.

  • Like 1

Share this comment


Link to comment

Leadwerks is a great tool, the problem is that a tool does nothing, if there is no one to push the talent, work, development. 

Then any bad worker will blame the tools.  I also rest a while and came back with a fresher mint and I share what some say, learning is my hobby and improving my skills is a challenge that somehow allows me to advance to the next level.  

Übersetzt mit www.DeepL.com/Translator

Share this comment


Link to comment

Sure it's a tool but a better tool gets better results.  If you can write 10 lines of code instead of 1000, that's hours of work saved and usually more likely that you'll end up with something nice to show off.

  • Like 1

Share this comment


Link to comment
1 minute ago, gamecreator said:

Sure it's a tool but a better tool gets better results.  If you can write 10 lines of code instead of 1000, that's hours of work saved and usually more likely that you'll end up with something nice to show off.

I agree, and that's why we're not creating video game engines, talent has another for that, all the tools are usually great, but no matter how much I install UDK, CryEngine, Torque, Unity, they don't do anything by themselves. Then comes something that I think, and I can be wrong, make us right on a tool, see its advantages and focus on it, and know how to deal with their mistakes. 

Now, we could be creating games directly from c++ and Vukan in a Visual Studio environment, but for that you need talent, and that's what professional studios and famous games pay for. 

In the end my point of view is simple, I use Leadwerks, because I don't have the talent needed to make a video game engine, or create with other development environments.  Here it's easy, in other parts they throw you an immense api and defend yourself as you can and in the same way you find problems, errors, difficulties, but the question is how to have the ability to solve them.

It's just what I think, and most likely I'm wrong. 

Translated with www.DeepL.com/Translator

  • 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.

Guest
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Blog Entries

    • By Josh in Josh's Dev Blog 2
      Previously I talked about the technical details of hardware tessellation and what it took to make it truly useful. In this article I will talk about some of the implications of this feature and the more advanced ramifications of baking tessellation into Turbo Game Engine as a first-class feature in the 
      Although hardware tessellation has been around for a few years, we don't see it used in games that often. There are two big problems that need to be overcome.
      We need a way to prevent cracks from appearing along edges. We need to display a consistent density of triangles on the screen. Too many polygons is a big problem. I think these issues are the reason you don't really see much use of tessellation in games, even today. However, I think my research this week has created new technology that will allow us to make use of tessellation as an every-day feature in our new Vulkan renderer.
      Per-Vertex Displacement Scale
      Because tessellation displaces vertices, any discrepancy in the distance or direction of the displacement, or any difference in the way neighboring polygons are subdivided, will result in cracks appearing in the mesh.

      To prevent unwanted cracks in mesh geometry I added a per-vertex displacement scale value. I packed this value into the w component of the vertex position, which was not being used. When the displacement strength is set to zero along the edges the cracks disappear:

      Segmented Primitives
      With the ability to control displacement on a per-vertex level, I set about implementing more advanced model primitives. The basic idea is to split up faces so that the edge vertices can have their displacement scale set to zero to eliminate cracks. I started with a segmented plane. This is a patch of triangles with a user-defined size and resolution. The outer-most vertices have a displacement value of 0 and the inner vertices have a displacement of 1. When tessellation is applied to the plane the effect fades out as it reaches the edges of the primitive:

      I then used this formula to create a more advanced box primitive. Along the seam where the edges of each face meet, the displacement smoothly fades out to prevent cracks from appearing.

      The same idea was applied to make segmented cylinders and cones, with displacement disabled along the seams.


      Finally, a new QuadSphere primitive was created using the box formula, and then normalizing each vertex position. This warps the vertices into a round shape, creating a sphere without the texture warping that spherical mapping creates.

      It's amazing how tessellation and displacement can make these simple shapes look amazing. Here is the full list of available commands:
      shared_ptr<Model> CreateBox(shared_ptr<World> world, const float width = 1.0); shared_ptr<Model> CreateBox(shared_ptr<World> world, const float width, const float height, const float depth, const int xsegs = 1, const int ysegs = 1); shared_ptr<Model> CreateSphere(shared_ptr<World> world, const float radius = 0.5, const int segments = 16); shared_ptr<Model> CreateCone(shared_ptr<World> world, const float radius = 0.5, const float height = 1.0, const int segments = 16, const int heightsegs = 1, const int capsegs = 1); shared_ptr<Model> CreateCylinder(shared_ptr<World> world, const float radius = 0.5, const float height=1.0, const int sides = 16, const int heightsegs = 1, const int capsegs = 1); shared_ptr<Model> CreatePlane(shared_ptr<World> world, cnst float width=1, const float height=1, const int xsegs = 1, const int ysegs = 1); shared_ptr<Model> CreateQuadSphere(shared_ptr<World> world, const float radius = 0.5, const int segments = 8); Edge Normals
      I experimented a bit with edges and got some interesting results. If you round the corner by setting the vertex normal to point diagonally, a rounded edge appears.

      If you extend the displacement scale beyond 1.0 you can get a harder extended edge.

      This is something I will experiment with more. I think CSG brush smooth groups could be used to make some really nice level geometry.
      Screen-space Tessellation LOD
      I created an LOD calculation formula that attempts to segment polygons into a target size in screen space. This provides a more uniform distribution of tessellated polygons, regardless of the original geometry. Below are two cylinders created with different segmentation settings, with tessellation disabled:

      And now here are the same meshes with tessellation applied. Although the less-segmented cylinder has more stretched triangles, they both are made up of triangles about the same size.

      Because the calculation works with screen-space coordinates, objects will automatically adjust resolution with distance. Here are two identical cylinders at different distances.

      You can see they have roughly the same distribution of polygons, which is what we want. The same amount of detail will be used to show off displaced edges at any distance.

      We can even set a threshold for the minimum vertex displacement in screen space and use that to eliminate tessellation inside an object and only display extra triangles along the edges.

      This allows you to simply set a target polygon size in screen space without adjusting any per-mesh properties. This method could have prevented the problems Crysis 2 had with polygon density. This also solves the problem that prevented me from using tessellation for terrain. The per-mesh tessellation settings I worked on a couple days ago will be removed since it is not needed.
      Parallax Mapping Fallback
      Finally, I added a simple parallax mapping fallback that gets used when tessellation is disabled. This makes an inexpensive option for low-end machines that still conveys displacement.

      Next I am going to try processing some models that were not designed for tessellation and see if I can use tessellation to add geometric detail to low-poly models without any cracks or artifacts.
    • By Josh in Josh's Dev Blog 0
      For finer control over what 2D elements appear on what camera, I have implemented a system of "Sprite Layers". Here's how it works:
      A sprite layer is created in a world. Sprites are created in a layer. Layers are attached to a camera (in the same world). The reason the sprite layer is linked to the world is because the render tweening operates on a per-world basis, and it works with the sprite system just like the entity system. In fact, the rendering thread uses the same RenderNode class for both.
      I have basic GUI functionality working now. A GUI can be created directly on a window and use the OS drawing commands, or it can be created on a sprite layer and rendered with 3D graphics. The first method is how I plan to make the new editor user interface, while the second is quite flexible. The most common usage will be to create a sprite layer, attach it to the main camera, and add a GUI to appear in-game. However, you can just as easily attach a sprite layer to a camera that has a texture render target, and make the GUI appear in-game on a panel in 3D. Because of these different usages, you must manually insert events like mouse movements into the GUI in order for it to process them:
      while true do local event = GetEvent() if event.id == EVENT_NONE then break end if event.id == EVENT_MOUSE_DOWN or event.id == EVENT_MOUSE_MOVE or event.id == EVENT_MOUSE_UP or event.id == EVENT_KEY_DOWN or event.id == EVENT_KEY_UP then gui:ProcessEvent(event) end end You could also input your own events from the mouse position to create interactive surfaces, like in games like DOOM and Soma. Or you can render the GUI to a texture and interact with it by feeding in input from VR controllers.

      Because the new 2D drawing system uses persistent objects instead of drawing commands the code to display elements has changed quite a lot. Here is my current button script. I implemented a system of abstract GUI "rectangles" the script can create and modify. If the GUI is attached to a sprite layer these get translated into sprites, and if it is attached directly to a window they get translated into system drawing commands. Note that the AddTextRect doesn't even allow you to access the widget text directly because the widget text is stored in a wstring, which supports Unicode characters but is not supported by Lua.
      --Default values widget.pushed=false widget.hovered=false widget.textindent=4 widget.checkboxsize=14 widget.checkboxindent=5 widget.radius=3 widget.textcolor = Vec4(1,1,1,1) widget.bordercolor = Vec4(0,0,0,0) widget.hoverbordercolor = Vec4(51/255,151/255,1) widget.backgroundcolor = Vec4(0.2,0.2,0.2,1) function widget:MouseEnter(x,y) self.hovered = true self:Redraw() end function widget:MouseLeave(x,y) self.hovered = false self:Redraw() end function widget:MouseDown(button,x,y) if button == MOUSE_LEFT then self.pushed=true self:Redraw() end end function widget:MouseUp(button,x,y) if button == MOUSE_LEFT then self.pushed = false if self.hovered then EmitEvent(EVENT_WIDGET_ACTION,self) end self:Redraw() end end function widget:OK() EmitEvent(EVENT_WIDGET_ACTION,self) end function widget:KeyDown(keycode) if keycode == KEY_ENTER then EmitEvent(EVENT_WIDGET_ACTION,self) self:Redraw() end end function widget:Start() --Background self:AddRect(self.position, self.size, self.backgroundcolor, false, self.radius) --Border if self.hovered == true then self:AddRect(self.position, self.size, self.hoverbordercolor, true, self.radius) else self:AddRect(self.position, self.size, self.bordercolor, true, self.radius) end --Text if self.pushed == true then self:AddTextRect(self.position + iVec2(1,1), self.size, self.textcolor, TEXT_CENTER + TEXT_MIDDLE) else self:AddTextRect(self.position, self.size, self.textcolor, TEXT_CENTER + TEXT_MIDDLE) end end function widget:Draw() --Update position and size self.primitives[1].position = self.position self.primitives[1].size = self.size self.primitives[2].position = self.position self.primitives[2].size = self.size self.primitives[3].size = self.size --Update the border color based on the current hover state if self.hovered == true then self.primitives[2].color = self.hoverbordercolor else self.primitives[2].color = self.bordercolor end --Offset the text when button is pressed if self.pushed == true then self.primitives[3].position = self.position + iVec2(1,1) else self.primitives[3].position = self.position end end This is arguably harder to use than the Leadwerks 4 system, but it gives you advanced capabilities and better performance that the previous design did not allow.
    • By reepblue in reepblue's Blog 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.
×
×
  • Create New...