Development Blog

This list more or less ticks off most of the boxes that I can think of that are immediately needed.

 

This list is exciting and can't wait to start to see this progress.

We are looking at NoesisGUI because of the lack of GUI with LE. It's probably the most frustrating thing about LE honestly. Having to pay for a GUI that costs basically the same as the engine itself. GUI's are actually very complicated things to get right (to make sure things scale and position correctly and supporting enough controls, while being easy to work with).

 

I first made my own very basic one with LE commands but it was only for 1 resolution/ratio and no real controls but exactly what was needed but it turned out very hacky (as expected for a quick thing).

 

I then went on a search for web technologies that could be used since there are so many libraries out there to give so many different kinds of functionality for the web. However, all options sucked and were hacky. I still think the ideal world of UI is through html/css/javascript and functionality that can easily hook javascript to C++ or Lua. html/css/javascript is very powerful in representing UI and there are already so many libraries out there as I said before. Sadly it comes with a lot of baggage as people try to force your game into a webpage vs just displaying the webpage over your game and/or some solutions require an entire browser to be added to your game. Ideally there would be a thin html/css/javascript layer in a C++ library built into an engine.

 

 

Now we are looking at NoesisGUI. The goods being that it uses a common language to describe the layout "wpf" and it comes with all of wpf's controls and easy ability to nest controls together (since wpf is basically xml). You can also use MS's freely available editor Blend or VS to visually make your UI. The bad is that it's pretty complex if you don't know wpf and wpf takes some time to get to know. Especially when you are doing a game UI which is far more complex than a normal business app (inventory drag/drop and such). One great thing is that a lot of ppl in the world know WPF so if you wanted to hire a professional to help it's very doable. This would also be a huge benefit for html/css/javascript UI libraries. Most game engines are propriety in their UI's which means the amount of people that you could have help or hire drops significantly or learning it does very little for you in other areas of technology.

 

What I've found is that this is a space that is really lacking in the game industry. If I were rich and didn't have to work I honestly would be working on making an html/css/javascript UI library for desktop games that easily integrates into OpenGL and interaction easily maps from javascript to C++/Lua, without all the huge overhead that it currently has (which is mostly security features which aren't needed in game UI's for desktop apps. html/css/javascript probably has the most people available who know it in the world compared to other options and there are so many free libraries existing for it. Not to mention MS is also embracing it for their UI's for metro apps (they haven't gone away from wpf but they really aren't doing much with it either but the writing is on the walls if you ask me). This is why html/css/javascript is ideal. It's not going anywhere anytime soon. I'm pretty sure it's the biggest (most users) and longest lasting library to represent UI with and there is no sign of that slowing down.

Josh, will the 2D platformer template include slope movement?

What is special about that?

 

Do you mean just keeping it stuck to the ground when it is moving quickly down a slope?

Yes based on his other posts, i would assume that is what he is referring to. I believe him and others have reported a skipping effect when moving down a slope.

Leadwerks 3 doesn't get skipping, from my tests. When you start out moving, he does lunge into the air at first. That can be improved a little bit, but when you are running down a slope it is perfectly smooth.

 

You can try this script:

http://www.leadwerks.com/werkspace/topic/12651-2d-platformer-player-script-example/#entry90922

WIth the 2D platformer I'm really curious how you get around keeping a character controller on the axis when it is hit with forces i.e projectiles explosions. I never nailed it when I tried.

Any idea what the start date for the summer tournament will be?

Game templates are great and the soldier for the next DLC makes sense.

Looking forward to decals, I know these can be done as such already but an out of the box way woill bo good.

GUI commands or an offical add on are essential. Looked at Noesis but it would take me a lot of time to get that working (not enought xp or time).

FlowGui is good though not updated recently as Aggrors busy.

All you have to do is get the player position, set Z to 0.0, then set the player position with those values.

All you have to do is get the player position, set Z to 0.0, then set the player position with those values.

Yes, i remeber testing with physic barrels and doing that only the barrels moved away, the player was still in Z=0.

On the other side you will need some raycast checks or use collision function detection to stop moving the character when he touches some static physic box or he can go throught it using PhysicsSetPosition().

You don't need to do that. I'll make a tutorial on this.

Rick: This may not be to your liking but it looks like the Albalynx source has been opened (https://bitbucket.org/wolfhound512/albalynxproto?). I don`t mind it for my Allegro stuff because I essentially reuse the same code in every project. Also, ImGUI (https://github.com/ocornut/imgui) may be be suitable for utility projects.

I actually found a nice one that seems to be better organized. These open source ones are all a mess from what I've seen. I'm just tired of hacking things together and want a company that I can get support from.

 

https://coherent-labs.com/buy-coherent-ui/

 

I contacted them to see if we could get an indie version like they do for unreal and unity. I really want the html/css/javascript stack since I think it's the best way to go for UI for the reasons I listed above.

Just a suggestion for the soldier pack, if it becomes a reality:

 

A civilian script, where it will keep away from other AI and the player when an event is triggered.

Out of curiosity (and something you didn't specifically mention, which is why I ask), do you have any plans for general (or specific) optimizations? Any places you can readily see where the rendering pipeline might be made more efficient? I think I recall you mentioning something about FBO's, but can't remember specifically...

 

Nice work on the new tutorials and such--anything to help people ease into Le quicker can't be a bad thing

It might be possible to improve FBO switching, but I think this would only improve the editor's performance, and only on Linux.