Our community blogs

  1. Josh
    Latest Entry

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


    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.


    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.


    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.

  2. Josh
    Latest Entry

    The forum software has been updated to a major new version.  This completes my effort to give the entire website responsive design, and ensures we continue to receive security updates.  The responsive design part is really for SEO, but it is kind of cool to be able to browse the entire site on your phone without zooming in.

    Documentation has been switched over to the new system here, which is independent from the forum software:

    The entire site is now using SSL on every page, again for SEO purposes.

    There are a few bits that need improvement, but overall it's a solid upgrade and I think you will find the new site to be very helpful.  I've added a new Q & A forum where you can get technical assistance and rate the answers.  Code formatting has been improved a lot, and the notifications system does a really good job of catching replies to your posts.  (If you're receiving a lot of emails you can disable this in your account settings.)

    Finally, you can now set a cover image to show at the top of your profile, which is pretty cool.

    • 2
    • 11
    • 1959

    Recent Entries

    Latest Entry

    Main post available here


    I first presented my PBR work about a year ago, since then I've been tweaking and making improvements.


    Over the past 6 months Leadwerks has had some great updates for graphics junkies like me tongue.png .The HDRi and environment probe features look great and have helped with 2 of the main issues with the last PBR system. Now what you see in the editor is what you get in the game, and HDR means proper tonemapping and a wider range of possible light intensities. Both of which are important for realistic PBR.


    I currently plan on using this for my current project, so expect consistent updates as I battle test it.

    The current build is available on github. Any issues and suggestions to help improve it are welcome.







    Limitations / improvements

    • Requires a gamma-correction post process shader. Not a huge issue, adding a pp is pretty easy but still something to remember.
    • Currently the built in environment probes are stored in a low dynamic range. This leads to clamping and precision errors as HDR values move towards extremes. this limits the usefulness of HDR. This is an engine issue.
    • Probes also use simple mipmapping for different roughness values, PBR often performs a convolution on stored cube-maps to better match reflection blurring due to roughness. A fix may be possible for this, but would require C++.




  3. I am currently looking into some 2d basic/arcade game tutorials which might follow up on the OLED project once all the lua basics tutorials are done.


    Think about games like:

    • Minesweeper
    • Tetris
    • Pong
    • Bejeweld (match 3)
    • Asteroids
    • Snake
    • Arkanoid (breakout)


    Minesweeper is already finished:




    Replicating all these games myself gives a great indication on their complexity, even for arcade games. Grid based games like minesweeper, bejeweled and tetris are the easiest and share a lot of functionality. So doing all of them might now prove usefull. Pong is great in the sense that it introduces vector mathematics. All these game have their own little mechanics. The trick in making the tutorials is also finding the right game order.


    One game that you might find missing in the list above is Pacman. Although certainly doable, the ghosts have their own behaviour which makes them a little trickier for beginnners. All in all it is a good way to really start tinkering about lua once you'r done learning the basics.



    What are your favorite arcade games?

  4. Hi! It has been a while. Here's an update on my networking library EvayrNet which is available for C++ users of Leadwerks:


    While implementing it into the test project in Leadwerks, I saw that the use case had some flaws which made it really hard to debug what's going on. I figured that I should be spending some time on fixing some flaws. After a few weeks I came up with the following upgrades:

    1. Debugging class
    2. Simulation mode
    3. More debugging information available

    Here's some detailed explanation:


    Debugging class

    I was using a lot of "printf" before which made it hard to:

    • Find out where it's being called
    • Disable whenever I don't need it anymore

    This is when I decided to make a debugging class. I replaced the printf with a custom Print function which allows you to do the same as before - except you can disable any kind of printing whenever you want (like during release builds).


    I also realized that capturing data is a pretty cool feature to have, which makes it easier to visualize the data you want to debug. For that I created a SaveText function which accepts a string and a filename as arguments so you can separate data like "Pings per interval", "Bytes sent per second", etc.


    Here is an example what you can do with it:



    Simulation mode

    This is an interesting one that I just had to implement. A connection cannot always perfect, and it can be hard to always expect a good outcome (while you might not notice it because of your tests on localhost). This is why I introduced the manipulation of the following networking stats:

    1. Minimum latency (in ms)
    2. Random latency (in ms)
    3. Packet drop percentage
    4. Packet duplication percentage

    It's also very easy to activate and deactivate. All you have to do is NetworkManager::StartSimulation(...) and StopSimulation(). Here is it in the command line when you activate it:



    More debugging information available

    At last I added more ways to debug the network statistics to really see what is going on. Are you not receiving data anymore? Are you flooding the network? The following information is now ready to be displayed:

    • Newest ping (either to the server or from a specific client)
    • Average ping (this as well^)
    • Incoming amount of packets per second
    • Outgoing amount of packets per second
    • Packets per second lost
    • Incoming data per second (in bytes)
    • Outgoing data per second (in bytes)
    • Current active connections (primarily for the server)

    That's... quite a lot more than before! Previously you could only see if you're connected and if you're the server. I hope this information will make it easier for users to visualize traffic and debug any problems they might be having. And of course, you can mix this up with the debugging class to make cool graphs like above!


    Final words

    I'm still planning on making some extra information, like on specifics to see what kind of message is creating the amount of bytes send/received. This should help debugging even more. Other than that there are still some enhancements I'd like to put in such as encryption. These can be seen here.


    I hope you liked this blog post! Next time I will probably be showing how to implement EvayrNet into your C++ Leadwerks project, so you can toy around with it. wink.png

  5. Forest with different models using the vegetation tool:






  6. blog-0502497001488979347.png

    In an effort to further boost production values and the general quality of the cinematics in Enshrouded World I implemented facial animation for the characters and as the title suggests rather inelegantly.





    Below is one way of going about implementing facial animation but it's most likely not the best.




    - Sift through thousands of frames of mocap facial animation and export the model every five frames.

    - Load and release the vertex data of each of the hundreds of models needed for one cutscene to reduce RAM usage.

    - Set the positions of the vertices in the base face to the positions of the vertices in the next model (This requires interpolation and continues to the next model every 83 milliseconds).



    As you would expect the first step there was very tedious and despite my efforts there are still issues with the framerate whenever the facial animation is being rendered.

  7. I have made a small class for helping with reading and writing parameters between C++ and LUA and also calling LUA functions from C++. I'm sharing this little thing here.




    Using the class is quite simple as shown below


    LUA - part



    C++ - part



    I have included is a test project which looks like this in the editor



    And like this when executed



    Here is the LuaBridge class source




    And the complete test project


    Note: Its says 'Click for next test', should be 'Hit Spacebar for next test'

  8. The last blog I posted was Nov 2013. The blog section seemed stale for for a week or so so thought I'd share a change in design I recently did for our Dead Anyway game to spark conversation and ideas.


    Our player script was just getting too massive and was doing too many different things directly inside of it. Adding features or modifying existing features was scary as hell. All the "helper" variables were adding up and the amount of hunting for what I needed in the script was pissing me off. So I decided to re-look at component architecture. After putting this into practice it's really makes programming more fun and changing things a lot easier and less fearful.


    The first task was to look at this monster player code and break it down into domains. That meant looking at the high level functionality.

    • Play sounds
    • Take input
    • Camera controls
    • Movement controls
    • Inventory
    • FPS arms
    • HUD
    • Handle stats like health, hunger, thirst, etc

    All of this was happening right in 1 script. Not cool. So I first hand to break all this functionality into their own scripts. However all this functionality works off each other. Even though they are separate when to do what and code X needs to know stuff about Y still exists. So if we want to break code out into it's own domain (and scripts) and reduce coupling on each other to avoid making fragile code AND they need to know about each other in various ways how would I do that?


    Enter events. I treat each component as it's own little library that is designed to do it's one specific thing related to the game. So it of course has functions that act on it's data. But how would those functions get called? They would get called when events from other components were raised. So now a component has events to tell the outside world that something happened inside this component and functions to act on this components state. It doesn't care how it's functions get called and it doesn't care who is listening to it's events. It's blind to the outside world.


    An example is the PlayerSound component. It loads sounds in it's init function and then it has functions like WalkForward(), WalkBackward(), StopWalking(), StrafeLeft(), StrafeRight(), Jump(), Eat(), Drink(). These functions simply play the right sounds. The PlayerSound code doesn't care about the input code and when you're in the PlayerSound script you don't either. Your mindset is just all about sound code at that point. You're thinking about what functions do I need for sound, and what possible events should I fire that have to do with sound? The sound script right now is about 100 lines of code (but it will grow in the future). It's nice and contained as it's own component.


    Every component is like this. PlayerInput converts actions to events. It doesn't care who uses those events. It also has functions to map keys to actions. Who is calling those functions? Who cares. It's not my concern when I'm in coding the PlayerInput component. I just know I want to do that functionality at some point.


    So how does this all get wired up you may ask? That's the interesting part. Your player script, instead of being an if nested disaster, simply becomes configuration code of linking component events to component functions (I call them actions). I noticed something interesting happen when I did this. Looking at the player script revealed what it's doing much simpler. It provided a nice high level overview of what the player is doing at a glance. I didn't have to read state variables and loops and branch statements to figure it out. I saw it all revealed to me. I feel like it works better with our brains. We think, when this happens do x, y, z. That's the component architecture with events exactly. That's all you see 1 line at a time. When this happens do this. Very little interpretation is needed.


    Here is an example of what my player script looks like now:


    PlayerLooting.onLooting:Subscribe(PlayerHUD, PlayerHUD.ShowProgressBar)
    PlayerLooting.onLooting:Subscribe(PlayerCamera, PlayerCamera.DisableUpdate)
    PlayerLooting.onLooting:Subscribe(PlayerController, PlayerController.DisableUpdate)
    PlayerLooting.onCancelLooting:Subscribe(PlayerController, PlayerController.EnableUpdate)
    PlayerLooting.onCancelLooting:Subscribe(PlayerCamera, PlayerCamera.EnableUpdate)
    PlayerLooting.onCancelLooting:Subscribe(PlayerHUD, PlayerHUD.HideProgressBar)



    The PlayerLooting component has an event onLooting and onCancelLooting and those other components are subscribing to those events and telling those PlayerLooting events what functions they could call when that event is raised from within the PlayerLooting component.


    You can plainly see the HUD shows the progressbar and the camera and controller controls are disabled. If we cancel looting we hide the progressbar and the controls are enable again.


    Want to add a sound when looting? Just think about how easy that is to think about. No hunting for the right section and state in the old giant player script that is 1000+ lines. You simply:

    1. Add a loot sound variable and load a loot sound inside the PlayerSound script (you know exactly where to do this. if it's a sound it's done in PlayerSound component. easy right?)
    2. Make a function in PlayerSound to play said sound
    3. Make a function in PlayerSound to stop said sound
    4. Link the onLooting event to the PlayerSound play looting function
    5. Link the onCancelLooting event to the PlayerSound stop looting function

    It's much more compartmentalized than the traditional design of putting all that stuff into the player script.



    Here is the event code that I use:


    if EventManager ~= nil then return end
    EventManager = {}
    function EventManager:Create(owner)
    local obj = {}
    obj.handlers = {}
    obj.owner = owner
    for k, v in pairs(EventManager) do
    obj[k] = v
    return obj
    function EventManager:Subscribe(owner, method)
    table.insert(self.handlers, { owner = owner, method = method })
    function EventManager:Raise(args)
    for i = 1, #self.handlers do
    self.handlers[i].method(self.handlers[i].owner, self.owner, args)



    Inside a component to create an event you simply do:


    -- note I just wanted to use Event but Josh exposed that for his UI stuff so I ended up with EventManager instead
    self.onmoveForward = EventManager:Create(self)  
    -- events have a table that is an argument that will get passed to the function subscribed to events
    -- interestingly enough because it's a table, it's passed by reference so inside your action function if
    -- you change a value the component that raised the event can read that to perhaps act accordingly.
    -- I do that in a few instances
    self.onmoveFoward:Raise({ shiftKeyDown = false })


    Then to subscribe to the event in the player script where all the components come together you simply call the Subscribe() function on said event passing in the component object and the component objects function/action to get called when that event is raised:


    PlayerInput.onmoveFoward:Subscribe(PlayerSound, PlayerSound.PlayMoveFowardSound)


    My future for this is to have an editor that reads all component events/actions and visually allows you to hook up events to actions. Then the player script simply reads the output file of said editor to hook things up. Then we'd have a nice visual of how our game works at a high level.


    This was a long one but I'm really excited about making the switch. It was an easy transition to make and it makes adding/changing functionality really simple, and it gives me a high level overview of what's going on with the player which was increasingly getting more complex.


    If you read this far on a weekend then go outside :)

  9. It should be great if you can create a game world which has exact real-life object's dimensions. If you are using Blender to make game props for Leadwerks, these are some simple steps to help you archive the dimension match up.


    Step 1:

    - In Blender, go to Properties panel > Scene tab > Unit group

    - Choose "Meters" from list.

    - Make sure Length = Metric, Angle = Degree, Unit scale = 1


    Step 2:

    - This step is optional but can make you feel better with grid floor

    - In 3D View, Press N to open Properties region > Display group

    - Change Lines = 256, Scale = 0.1




    From now on, you can adjust object's dimensions parameters in Properties region to match real-life dimensions, it will be the dimensions when you import models into Leadwerks.


    Don't for get to Apply Transformation for object model, it is important. Do this before adjust object's dimensions. In blender Use Ctrl + A > Location / Rotation & Scale.




    Step 3: Fbx export

    - Menu File > Export > Fbx

    - Choose Version = FBX 7.4 binary

    - Scale = 0.01




    Step 4: Adjust exported model in Leadwerks Game Editor

    - Double click mdl file in Assets Explorer to open it in model editor.

    - Menu Tools > Collapse. This make sure model local rotation is correct.

    - Menu Files > Save.


    I attached my template .blend file below this post. It included a 1.7m height human model for better reference.

    • 2
    • 7
    • 377

    Recent Entries

    Latest Entry

    Ive decided to plan better and fix milestones so i can actually finish this game, the main problem is lack of time.But i have patience.


    I got a domain and in the process to setup a website and a blog.The plan is to have a small release every 15 days.

    Will see how it goes, it would be nice to work full time on this but not possible at this time, still have to go to work for a living.


    Currently im about to finish a somewhat starcraft like resource gathering mechanic.

    A mine has a 1 transporter that gather resources from asteroids.

    I limited to just 1 resource transporter per mine so that the user has incentive to expand (build mines) for more resources.


    Will come back with a movie.


    For development stuff i want to say Object::GetAddress method is great.

    Besides the debugger, really helped to investigate some strange crashes.





  10. blog-0568459001486305707.jpg

    One More Day - Performance Updates


    So it’s been a while since my last blog update on One More Day but recently I had a look to see if I could do anything with improving the performance of the game. As it turns out there were still some optimisations to be made that have helped boost performance.


    V0.1.6 on the Game Launcher


    Here are the main performance related changes I’ve made which were recently published to the Game Launcher:

    1. I changed some of the furniture models to lower poly versions. Some of these models were about 3000polys and are now replaced with lower poly versions with no real visual difference in-game. So about 10 or so models that were repeated more than once around the level were shaved in poly detail by about a third.
    2. I halved the draw distance on camera range and increased the fog a bit to compensate. I believe this helped more for when you are some distance outside the town but less so when you are in the town.
    3. I removed some rogue geometry in the map (wasn’t much), and also a few objects that weren’t really needed.
    4. I went back over every object to ensure it’s viewing range was as minimal as I could afford without creating too much pop-up. This is something I have always done but still sometimes you end up missing a few things.
    5. I spaced out some detailed areas on the map (ie. the power station got moved out further) to try to reduce the number of objects being shown at any one time.
    6. I made sure physics shapes set in model viewer were as simple as possible and removed collision from some small objects.
    7. I removed some workshop objects that had very big textures.


    All these changes stacked on to the latest version of Leadwerks which also includes performance improvements have given a noticeable performance improvement to the game.


    One thing I had to add in (sparingly) was some grass using the vegetation system as I felt it added nice detail to the level and was worth a small performance hit. That’s what makes optimising the game hard, trying to balance between good visuals, content and good performance. Unfortunately sometimes sacrifices have to be made. But even with the grass added the new version is running better than before. I would like to add volumetric spot lights for light coming in the windows but for now I resist that temptation as they would add up to a significant performance hit. Maybe I will add them as a high graphics option in the future.


    Other Improvements


    As well as performance improvements the game download size is now smaller thanks to the newly added ogg support and also removal of some unused files that were being published. One thing I noticed when publishing a game in Leadwerks is that if you have files with the same filename in two different folders both files will be packaged even if only one of them is used. So there were some unneeded texture files etc. being packaged from unused workshop content. Going forward I will have to keep an eye out for duplicate filenames.


    More performance in the works


    The following changes are in my current dev build which hasn’t been released yet but are showing even more performance increases:


    1. Converted the CSG houses and bungalows to models. Simplifying and reducing object/entity count. This should allow me to add more houses to the map with less of a performance impact.
    2. Further reduced the camera range and increased the fog to compensate. This allows me to reduce the view range on many bigger outdoor objects and buildings from Max to Far whilst minimizing popup and also reduce the vegetation view range. This will result in a much more foggy look to the game (see screenshot) which will create a slightly different atmosphere than previous versions and with less viewing distance it might make approaching zombies a bit more dangerous.
    3. I identified SSAO was making quite a performance impact so I have disabled this for now and might re-introduce it as a high graphics option when I get around to creating an options menu. For outdoor map SSAO is probably not as important or worth the hit but it is nice to have when inside the buildings.


    After all these performance improvements and v1.7 is released I am optimistic that most people should get at least a 30fps game experience with OMD. Fingers crossed!

  11. After going radio silent for a week I return with some really, really good news.


    First and foremost, the last level of the first episode is finished, I'm currently testing it out and seeing if I can break it before I upload a beta build to steam. After a couple days of it being there, if there aren't any issues, I will be launching the game on february 10th. Yes, you can quote me on that.



    I have to tell you though, making this level was not easy at all, I had so many ideas that never saw the light of day, but I hope that the way I created things work out for the better and I hope to use those scrapped ideas in the future someway.


    So here's a bit of information for the last level for those of you who've been wanting to play it:


    There's a way to kill the demon.

    There's a way to escape without killing him.

    The last level has 5 different variations depending on what you do.



    It goes without saying that there are multiple endings for what happens when you finish the last level as well, but I'll leave that for you to find out.





    That's it for now! I've probably already said too much so I hope you'll like what's in store for you.

  12. It's finally done!


    You can find it here on the workshop:


    And now i'm going to share a bit about the progress of the last few weeks, stick around if you like :)


    I'm so glad i made it in time, there were still a few "optional" things i would've loved to add (like a final boss wave) but due some in real complications (losing my phone..) and overal internship time consumption i still managed to get quite a game here!


    I am pretty proud of it too, might sound silly for such small game but it's my second game that i marked as "complete"! Also special thanks to my wife for creating all the model textures & GUI textures!


    For both me and my wife it was the first time we actual worked with 3D models (creating them from scratch and texturing them from scratch) this was quite a cool experience, i'm really glad with the results

    and i got more experienced in the tools i can use to make things look nice without too much complications.


    I personally think the cartoon-ish style was a great start for the modeling / texturing matter as this are my first proper game models that i build from scratch like mentioned above. I did have a small glimpse and trying to add bones, but i personally left it aside for now as i didn't really need them and i wanted to invest my time more in the game to reach the finish line.


    Overal in general, the progression went smooth (sometimes a stupid mistake like uppercase instead of lowercase.. You know the deal hehe), this was also my first time actual creating a wave system which i enjoyed a lot! I must say, tweaking & balancing each wave was harder then i honestly expected at first but i think i found quite a balance :)


    I don't really know what more to add haha, perhaps writting this after a day programming session wasn't the best idea.


    Thanks for reading and i hope you guys enjoy the game as much as i did creating it!

    • 2
    • 8
    • 41

    Recent Entries

    In my day job I get a lot of experience with different technologies. Mostly related to mobile or website, but there is a lot of bleed over in the game industry. I've done a few Ruby on Rails applications, it's not my primary toolbox, but it has some benefits. Mostly the ease and speed of development.


    I switched to using Ruby on Rails for the data management layer of my game. At the moment there isn't much data, only about 300 rows in a database for everything in the game. This is expected to more than triple within the next few months as I add achievements, more items, 7 new quests, and shops!


    Eventually this will go extremely large and hard coding all that data will become very error prone and next to impossible to manage.


    Ruby on Rails has the ability to have command line tasks which can be used to generate data.


    Sample task:

    namespace :codegen do
    task :achievement_types => :environment do
     erb ='lib/tasks/codegen/achievement_types.erb'))
     params = binding
     params.local_variable_set(:achievementTypes, AchievementType.all)
     data = erb.result(params)
     f ='codegen/AchievementType.h', 'w')


    What this code does is it loads an ERB file which is a templating file for Ruby.

    Queries the database for all AchievementType objects,

    Then creates a local binding scope for the template,

    Renders the template to a string

    Presto, Generated C++.


    Erb file in question:

    <% achievementTypes.each do |at| %>
    #define <%= at.macroname %> <%= %>
    <% end %>


    Code generated:



    The use case above is fairly simple, but more complex situations can occur, such as Npc Conversations. Currently my NpcConversation_Gen.h file is 500 lines long. with lists of data similar to this:


    new NpcConversation(34, 0, "69488b5b-cfd1-4255-bd74-a6b7eeb0e939",
     new NpcConversationAction(27, "AddInventoryItem", 39, 1),
     new NpcConversationAction(28, "CompleteMilestone", 3, 15),
     new NpcConversationConditional(12, "StartedQuest", 3, 0),
     new NpcConversationConditional(13, "HasItem", 57, 10),


    Maintaining that code by hand would triple the amount of time to create quests.


    So if your game uses a large amount of data, I really recommend using a web framework (Ruby on Rails, Codeigniter, Cakephp, Revel, Django, Spring, ect) to manage all your game data!

  13. blog-0813764001483675955.png

    I've finished the main concept of my game "Ball Hopper", which you can play at


    It was inspired by CS:GO surfing and the Impossible Game and your goal is to reach the checkpoints and get to the end. Checkpoints, for a lack of a better word aren't what you'd expect of them. They're really just points that you need to touch to be able to finish the level. Some level end points are right at the start, so would be a bit silly if you could just get to the finish and win, so that's what those are for. You don't actually respawn at those points.


    This blog post is mainly to gather feedback before the end of the tournament, so let me know if you have any suggestions.

  14. Hey!


    More stuff will come in the next version, my objective is to improve the Prologue to use as a demo for a Greenlight campaign to the next chapter. Much of the work this week (besides fixing stuff) was to detail the scenes a bit more to help you guys understand the water flood and how deep the water is.


    I removed the cars of the starting area, because floating cars in that place makes no sense.



    You can now even see the noisy bird (what a time to be alive!)


    The water in the game is really deep, the buildings you see in the game are the rooftops and the facility that you start the game barely survived to the cataclysm.


    Some additional rooms were planned for prologue but they were left out, I'll add them in the new version! So if you have already played the prologue you will have some surprises in the Uncut version.



  15. Ludum Dare 37 starts in 12 hours (as I type this)



    Most of you probably know (I think), but Ludum Dare is a game dev competition where you have to complete a game in 48 hours from scratch (no externals assets I think).


    The JAM portion of the event is a bit more relaxed and gives you 72 hours (if my memory serves me right - I really should check the rules) You can use external assets (I think - again I should have checked the rules before posting this right smile.png ).


    In the past I have sometimes participated unofficially and used it as a focus point to force myself to try to do a game in very tight timescale and so be forced to jettison most of the fluff you waste your time with normally.


    I think I might give the JAM (not the DARE) a go this year but probably just unofficially for my own benefit. Don't necessarily plan to submit anything as currently I already know I will have limited time over this weekend so it just might not happen. I suppose one outcome could be that I come up with the start of a small game I can enter into the Leadwerks Winter Tournament in just 2 days and can then either choose to submit that or continue on with my main idea.


    It can be a useful event to try out something that you've never got round to before in a bit of software (e.g. Leadwerks) and to refine your workflow.


    Sometimes there are also offers on software around this time which area usually highlighted on the site though I can't see any information on it at this time


    As I type this the theme is currently accepting voting still.


    Having a theme helps focus your mind but also think of things that might be outside your preferred area (space zombies etc.)


    If anyone decides to enter, officially or unofficially then good luck.

  16. Draws a box from one vector to another.

    To be used as some kind of arrow.


    Need feedback if its a better way to do this, but so far seem to be ok for my purposes.


    Example usage:

    ArrowUi *t = new ArrowUi(Vec3(0.0, 0.0, 0.0), testshadow->GetModel()->GetPosition());


    class ArrowUi {
        Model *model;
        Entity *pivot;
        Vec3 from;
        Vec3 to;
        float distance;
        ArrowUi(Vec3 from, Vec3 to);
        void From(Vec3 from);
        void To(Vec3 to);
        void Draw();
    ArrowUi::ArrowUi() {
       model = NULL;
       surface = NULL;
       pivot = NULL;
       from = NULL;
       to = NULL;
    ArrowUi::ArrowUi(Vec3 from, Vec3 to) {
       this->from = from;
       this->to = to;
    void ArrowUi::From(Vec3 from) {
       this->from = from;
    void ArrowUi::To(Vec3 to) {
       this->to = to;
    void ArrowUi::Draw() {
       pivot = Pivot::Create();
       pivot->SetPosition(from, true);
       distance = from.DistanceToPoint(to);
       model = Model::Box(0.05, 0.05, distance, pivot);
       model->Move(0, 0, distance/2);
       pivot->AlignToVector(to - from, 0);
       pivot->AlignToVector(to - from, 1);
       pivot->AlignToVector(to - from, 2);

  17. After I've returned from Steam Dev Days, I caught a terrible cold, so my first week home was unproductive when it came to LEX or Blue Portals. But besides that, I had a great time! I mentioned briefly in my last blog post before I went that I was giving LEX some reorganizing and defragmenting. This blog post, I'm going to go more into detail.


    LEX2 has a lot of things going for it. The developer console is really handy, the AssetManager prevents crashes and has the ability to pre-loads things for you and the PostStart() command for entities allows you to make entities do things RIGHT AFTER the map loads instead of during the loading process. All very helpful!


    Crawler's Den taught me a lot about what I was doing with LEX2, and where I should go. I designed it to be more Lua friendly than the initial release. but also allowed easy C++ classes to be made. Crawler's Den had the challenge of "Make a whole game in Leadwerks using nothing but C++". I know it was do-able, but how hard could it be?


    Leadwerks today isn't really as optimized to be developed using C++ as it is to Lua. I had to do go through a lot of hoops with somethings that could have been done easily if I just wrote the game in Lua. For instance, making C++ classes required more thought, and to attach my C++ puppeteers (actors) to entities in the editor, I had to make a Lua script that acted like a Hammer fgd file to sync it's keyvalues, inputs and outputs. Oh and on top of that, I had to make sure that each puppeteer got deleted properly. All and all, it was do-able, just not ideal at all!


    I'm switching back to be more focused to making games with Lua for now. I started by making a new project and re-writing the console system to be more flexible. Instead of defining all ConCommands in one cpp file, ConCommands can be defined anywhere now like:



    static void ConCommand_SayHi(vector parameters)





    static ConCommand sayhi("sayhi", ConCommand_SayHi);


    With this system, it may be possible to make your own console commands via lua, but I'd have to look into it.


    My ExSystem Class is derived from Leadwerks System Class, and it's how to talk to the application directly. It handles the dev console, pausing, resuming, and other states that the application might be in. 90% of ExSystem can be called from Lua.


    The Developer console is much more powerful than it ever was. You can now make entities fire script functions or outputs by the entity name, or using !picker when looking at it.


    fire <entityname> <functionname>


    There are also a lot of Utility functions from the previous codebase. One of my favorites is this function.


    inline Leadwerks::Entity* UTIL_PickFromCamera(int pDistance, int pCollisionType=0, float pRadius=0)


    Leadwerks::PickInfo pickinfo = Leadwerks::PickInfo();

    Leadwerks::Vec3 p0 = UTIL_GetActiveCamera()->GetPosition(true);

    Leadwerks::Vec3 p1 = Leadwerks::Transform::Point(0, 0, pDistance, UTIL_GetActiveCamera(), NULL);

    if (UTIL_GetActiveCamera()->world->Pick(p0, p1, pickinfo, pRadius, false, pCollisionType))


    return pickinfo.entity;



    return nullptr;



    I also made the settings.config file store in the AppData folder instead of the game's root. While I never had any permission issues with the old way, still best to have the user's settings there.


    I merged both the WindowManager and ContextManager to be one class; There is just a WindowManager now. There was no point to have the context be managed in it's own class; definitely now since I took out my UI code I had in there for the console drawing. I also fixed Screenshots being properly placed in it's own Directory in the game's folder!


    The World Manager is what got the most fat reduced. Before I had a great chunk of code that was ether commented or ifdef'd out. For example, I had old code for my cubemap factory before the Probes where a thing, and other checks that in the long run might cause more problems later. The World Manager is responsible that when a user want's to load a map, a world get's created or cleared, and PostStart is fired on all entities if they have a script. If the user want's to go back to the menu, the world manager clears, and then releases the world. Something that was 913 lines got reduced to 260, and it does pretty much the exact same thing.


    I removed the InputManager as at Dev Days I learned that that Steam will later be able to handle that for you, not exclusive to the Steam Controller. Also, the implementation was really confusing and tricky.


    Finally, I removed a bunch of classes that are no longer needed including the Puppeteer class as the focus is now Lua. I want to keep the scope of things small right now. All you need to convert a game using the standard executables to the LEX is to replace the 2 executables and add this self explanatory Lua script that'll override main.lua.


    --This function will be called once when the program starts
    function App:Start()
    return true
    --This function will be called right after when the program starts.
    function App:PostStart()
    --This is our main program loop and will be called continuously until the program ends
    function App:Loop()
    return true
    --This function is called once when the program pauses time.
    function App:onpause()
    --This function is called once when the program resumes time.
    function App:onresume()
    --This function is called while the program is loading a map. (This is where you draw your loading screen!)
    function App:OnMapLoad()
    --This function is called when the program finished loading a map.
    function App:OnPostMapLoad()
    --This function is called when the program disconnected from a map.
    function App:OnDisconnect()
    --This function is called when the program closes.
    function App:OnShutdown()


    Since it's really those three files that need to be shipped for the product to work, I can use the the standard Leadwerks Project Manager again. I don't plan on releasing the source code at this time. Maybe when making C++ games becomes more streamlined I'll re-integrate my C++ systems.


    There are still somethings to do though:

    1. Integrate the dev console to the Leadwerks GUI when that's fully done. The CMD using Cin approach that I'm using now is kind of bad.
    2. Play with the app a few hours a day, fix bugs, build on it a little each week.
    3. Find a good method in distribution, and keeping people up to date.


    In the future, I also hope to add more classes you can use while making gameplay objects. Somethings like a Beam class, and such to make things much more simpler.


    I also hacked together this shader that takes in roughness and ao sheets along with the diffuse, normal and spec. My artist gave me some textures right from Mamoset and my goal was to import them to Leadwerks as close as I could. I think they came out really well.



  18. blog-0128326001476525058.jpg

    TinyGom Racing PC Game is available !


    New demo : at: (register)


    or if you have an account on :


    lot of bugs corrected:

    • menu appearance now conform to what it should be
    • all sub-menus revisited
    • in game cosmetics adjustments
    • time trial mode now fully fonctionnal
    • screen resolution detection improved and working with multi monitors
    • no more bugs at the first launch of the demo

    SDMG-STUDIO production presents

    the fruit of my very long work,my completed game : TinyGom Racing


    Why 'TinyGom' ?

    because there are small tires... rolling !


    What is TinyGom Racing ?

    It is a solo PC game about driving remote control vehicles around levels in different environments.

    3 Game modes : Quick Race, Time Trial, Championship

    3 environments : School, Mall, Warehouse

    6 levels , 6 different rc vehicles with one mystery car (more levels and cars to come...)





    All races will be different because of the random placement at start, Music and AI racing are changing randomly too.

    Passing through the semi-transparent "red gates" you will progress along the level and finally loop a lap.

    When a bonus is available, going through it will give you three ping-pong balls to throw at opponents, wisely.




    Car abilities:

    Accelerate (!)

    direction left/right (good start, no ?)



    Flip car (in case of upside down)

    Replace car, Levels have saveposition tags, a "savepos message" will pop up when done.(see each mode for detail)

    Shooting balls (bonus gives you 3 balls to throw at opponents)

    Looking at 180° view right or left side of your car

    Position camera view from the rear of your car zooming + or -

    Pitch camera view angle from the rear (all positions of the camera are recorded and restored at start)




    Game Modes:

    Quick Race mode : you just race for fun, 5 opponents and clock ticking though, level lap record to beat too,

    you can choose the number of laps to run before racing.Simple ranking will show at the end of the race.

    Replacing the car in this mode will replace your car at the last "saveposition" recorded, from 3 to 9 savepositions spots are placed according to each level.

    In this mode you can also looking for the mystery car parts scattered around all levels by the naughty clown.

    With all the parts gathered you will unlock the mystery car and then be able to drive around with it.




    Time Trial mode : you will fight the clock and yourself with the ghost of your best lap running with you.

    If you beat the best ghost time, your lap will be recorded and you will racing against it then.

    At start in a new session you can choose to load the best ghost file so you will fight against it or

    if not, recording a new ghost as you drive and to race against it after the first lap, all over the session trying to improve it.

    If you ever beat the best ghost time (recorded in file and loaded in memory), you will then establish the new reference ghost record for future sessions.

    The game is, for now, solo but you can already exchange the ghost record files of your own with others players

    who have the game and then race against them through their ghost file.

    This is a fun part of this challenge.

    Replacing the car will replace you at the starting position of the level and restarting the clock.(no "saveposition" works in this mode)




    Championship mode : is based on the player name you enter (or leaving to "none")

    so you can leave the championship after a race in a level, quit the game and resume the championship later using the same name of player.

    Helping you by hitting the "restore last session" option in the main menu to retrieve your last session and resume the championship where you leave it.

    Replacing the car will replace your car at the last "saveposition" recorded, from 3 to 9 savepositions spots are placed according to each level.

    You will need to race 5 laps on each level to complete the Championship.

    You wont be able to redo a specific race before completing Championship, you will need to restart a Championship to do that.

    Points are distributed according to the finish positions of each level race : 100 for position 1, 80 to 2, 60 to 3, 40 to 4, 30 to 5, 20 to 6, 10 to 7 and 0 to position 8 (last one)

    Ranking is made after finishing a race level.

    Podium with global ranking will close the Championship at the end of the last race. Congrats if you are on the first step !


    Various objects, sometimes, will be throwing at you and the others along the levels slowing your race, putting little spice in your meal...

    Some objects are movable but a lot don't, you'll see.

    Mystery Car parts are seldom hidden from the direct view, you will need to rub the walls with your vehicle to discover the part-item then.


    Supported devices:

    mouse (menu)

    standard keyboard

    joypad X360 microsoft® controller

    Supported OS:

    Windows 7, 8, 8.1, 10


    Is the game ready ?

    yes :

    or here:


    Demo ?

    yes :








    This project was seriously started several (more than 5) years ago, after toying with Leadwerks engine for a while,

    decided to find the "make a game(mine)" function and finally found it works !

    I have counted 13419 lines of lua code, sweating on some...not counted the polys though !


    Thankful to Leadwerks Engine for enduring all my trials and errors and to restitute fluidly the render from my ideas.

    I need to give credits to a lot of people here : first to my wife Pascale, for her patience and her presence

    second my son and my daughter who always encouraged me to progress at it.


    And for all technical parts, in not particular order (sorry for those i forget to mention) : Josh Klint for the Leadwerks Software Engine.

    Forum People : MackleBee, Rick, Marley's Ghost, Tyler_H, Aggror, Gordonramp, Pixel_perfect, Shadmar...

    All these folks helped me directly or not, special mentions to MackleBee giving always good advices and good code examples,

    Rick for coding the joystick.dll (without it, i would never be here) and to Marley's ghost who gave me a great piece of code base of my main mecanics.

    Finally thanks to the great Leadwerks community, where i found so much usefull posts.


    Started from nothing, bought one Pure3D starting pack, grabbing most textures from others from my camera.

    Made all 3D models by myself, modeling,uvmapping,texturing and converting to gmf.

    Software used: Hexagon, Photoshop, 3DCoat, UU3D, Audacity, Leadwerks converting tools.


    I get a regular job so i have spent most of my spare time at my game.

    I started with Leadwerks 2.5 and stand with it because scene files (sbx) and all scripts in Lua

    would be a nightmare to redo and i love the 2.5 lighting (even if, the GI lighting Josh demonstrated is promising).

    Sure TinyGom is not perfect and could be more polished or more complete.

    My project is to extend the game even after the release, supporting bugs too.

    Hoping to compensate a bit the funds that i have put in this game, music bought at Partnersinrhyme®, pack from Pure3D® and the time dedicated,i have considered putting a fair price to the game,

    fee at a fast-food meal or a cinema ticket.

    Whatever happens, my reward is already there, accomplish the release of the game was my main objective,

    i am satisfied and relieved now.




    Videos are also visible on my web site too.


    Hope you will enjoy the videos, test the demo if you want,

    feedback welcome at

    The game and the demo are already available on my web site now :

    Excuse my english.

    Thank you for reading.


  19. Quick demo video of my Utility and Needs Based UI test framework.



    Click to see video on workshop



    This is a quick demo video of my Utility and Needs Based UI test framework.


    There are several things going on here to cause the AI actors to decide what to do:


    - A scoring function runs every tick that updates the score for each available action. The top scoring action is marked as the active mode; if the mode changed since the last tick, startup logic runs for the new mode and the new animation loop is activated.


    - The sleep action takes into account a "need", which is tracked as an increasing number from 0-100. It slowly increases over time, somewhat differently for each actor. Around when the need reaches 100, the score function for sleep does as well, eventually exceeding all other action's scores, activating sleep. When sleeping, scores for all other actions drop since it is difficult to do anything when you're tired. The script then activates the sleep animation.


    - While performing the sleep action, the actor receives a reward each tick that they are performing this action.


    - When awake, the actors currently switch between idle and wander actions since there is currently no other input in the environment to change the score of the other actions. These actions have an internal, random time limit which varies slightly for each actor. When the time limit expires, the action is disabled (turning it red). This allows for breaking score ties for time based actions.


    It's not an ideal framework but it's a start.

  20. A year has passed, time for an other update.

    Exspecially in the last weeks, I have been thinking and working onmy Game for long hours.

    yay !

    A Video from exactly a year ago shows the early Game functions which no longer will be as they are in the final game, unfortunately. (Youtube: Slastraf)

    Today I am focusing on Game Art, not as much as -programming , just because when I got into making Games, I started off and like to work with 3D programs such as Blender or Designing Levels with the built in Editor.

    So I needed to compromise and make my Game visually looking better and make the Player interact more with the surroundings , and less with things that are time intensive to program (Mirrors Edge's FPSplayer or something like huge RPG games).


    I have read somewhere that Games in general are more interesting and fun to play , if one has lots of decisions to make.. Looking at that, it took a while for me to think of an Point-and-click style adventure game, where the Player is able to visit much and different areas of the deadly Surface of the Planet.

    But not only did I want the Player to be on the surface, but be in an Underground Vault-style Construction,

    and fight enemies that are lurking inside of it.

    (Theres going to two boss fights in 3D and also the mentioned 2.5D , but later more.)





    These both Style of Games added up , lead to the Story.

    In late 2014 I first modeled a poor looking Space Station (Yes, I originally wanted to make a space Game) which was part of a Game where the player could flee in a capsule to the nearby Planet.

    Now I taught I will start the Game right where the protagonist does A crash Landing on the Surface.


    The main Objective is now , to find a way to survive the conditions of the Planet, since it has much Gravitation, less atmospheric pressure, and temperature (extreme long hot days, cold nights).

    I dont want to start talking about the over agressive hunter animals (Bosses).

    Of course you are not the only one to crash on the surface, you are able to get main Gear from the evil alien race Survivor,

    I have already modeled the Laser Blaster, but theres going to be a Blaster Pistol, and a multifunctional ,

    hand-attachable Taser, which generates a holographic protective shield . Only the latter will be available on the Surface to fight the boss, and in the later Game theres gun battles between Inhabitants, inside the Underground construction.


    All things Planned so far:

    Coast area, (will be big part of the plot , but I dont want to spoiler)

    Cliff area,(Crash site)

    Forest area,(First casual fight)

    Swamp area( First jumbo Monster boss fight ,, no spoiler )

    Interior maps of Underground Construction


    Things I am thinking of possibly putting in the game:

    Abandoned Small city

    Long Road in Desert


    I am looking forward to extend my knowledge, Make 3D Assets, and Share my game wink.png


    Some more WIP:

    Skyboxes By chrisV, thank you !


    Crash Capsule:



    Blaster Gun ( Am going to Upload timelapse on my Youtube Channel soon)



    Cliff area:


  21. Hello everybody. Today I probably will start the first lesson dedicated to developing games with LeadWerks Game Engine 4.1.


    Table of contents:

    • Introduction
    • Requirements
    • Project preparation
    • Setting up the project
    • Level creation (Prototype)
    • Ball Script



    This lesson is to create a game where the main character is a ball (or other primitive). By the way, there is such a lesson ( "Marble Game") in the official documentation.




    Before we begin, I would say the main requirements for the correct execution of the lesson:

    • You must dial the code themselves. This will allow you to understand the basic design principles.
    • Carefully read the text of the lesson and follow all the steps. It is very important.
    • Treat with understanding the author. I am a simple man, and I can make mistakes.

    Well. Now you can start a lesson.


    Project preparation


    Start LeadWerks 4.1 and open the "Project Manager" (how?)








    For the tutorial, I'll use an empty project ( "Blank Project"). The name you can choose any, I chose "BallGame".








    After the final creation, we make some modifications to the workspace. We need to add some starter content. For the tutorial, I'll take it from a template "Advanced First-Person Shooter". We need a folder with materials.


    Open this folder ({Steam Folder}/steamapps/common/Leadwerks/Templates/Advanced First-Person Shooter/) (If you change the directory LW then open it)


    And copy the folder "Materials" folder in your workspace.


    Well done if you have completed all the stages of preparation. It remains only to make a game )))


    Setting up the project


    Open your workspace (project) in LW.






    Now we'll do a few simple actions to configure our project. We will make a simple splash screen and other simple decorations.


    Open the file "Main.lua" ( "Scripts / Main.lua") in the script editor (how?)










    Now we have to modify the "Main.lua". I will not talk about work with Lua principles in LW (You can read about this in the Tutorial). I'll just write code and specify where to insert it (I'll refer to a reading material about this)


    All functions that are available to us, you can find in the API.


    To implement a simple splash screen, we need the following themes:

    A lot of material had accumulated. But not everything is so terrible.


    Will definitely start writing screen)


    Go to the 20th line of the code. It is especially this place? It's simple. All code up to this initialisere LW, and already runs code after the first level and run all in normal mode.


    Now I will write all of the code that you have to understand yourself to write, and later I will comment on it.


    --simple splash screen (only example)
    tempFont = context:GetFont() --Current Font/ We save for restore after display
    local font = Font:Load("Fonts/Arial.ttf",36) --Font for display
    local X = window:GetWidth() * 0.45 --the definition of the center of Width
    local Y = window:GetHeight() *0.5 --the definition of the center of Height(
    local A = 0 --Alpha
    local AStep = 0.005 --increment step
    local TimeScreen = 2.5 --Time in sec for display
    TimeScreen = TimeScreen * 1000
    context:SetColor(1,1,1,0) --Start Color
    while window:KeyDown(Key.Space)==false do --Space for skip
    context:DrawText(title .." with Leadwerks",X,Y) --Text
    Time:Delay(TimeScreen / (1 / AStep))
    A = A + AStep
    context:Sync(false) --Out on the screen
    if (A >= 1) then








    The result is bad. But this is only a simple example. At desire it is possible to complicate the code and will be all good)






    Now let's do the automatic detection of screen resolution (run full screen)


    Go to line 10. There will be a similar piece of code




    The values of the parameters screenwidth and screenheight define the starting desktop resolution. We can ask the system to know the current desktop resolution.


    insert before line 10 the following code:


    screen = System:GetGraphicsMode(System:CountGraphicsModes()-1)
    screenwidth = screen.x
    screenheight = screen.y


    Now modify the line




    in the following line




    And 9 line write "System:GetProperty("fullscreen",1)" instead of "System:GetProperty("fullscreen")"








    I know that experienced developers will tell you what to do, but we're just learning. In normal projects you can't do that)


    How much we have done. But even more lies ahead.


    Level creation (Prototype)


    In this part of the lesson, I'm not going to tell you anything. A lot of articles on this subject is on the Internet. I'll give a couple of links and it will show a prototype)


    The appropriate lessons LeadWerks you can find here


    To build a level, I will use primitives. Character is a ball, the levels are composed of platforms.


    Here's what I got (Show me what you have left)









    Are you pleased with the result? If not, then understand that you do not like your level and correct.


    Level ready. Make the character (ball)


    Ball Script


    Read the tutorial


    Now you have an idea how to do it. And I'll show you my implementation.


    Create a script of the player (Similar to that of a tutorial) ("Scripts/Player/BallPlayer.lua")








    It will be the main file for us. Through him we will make the control of the character/ camera / other.


    I will do as always. Write all the code and tell you how it works. So I'll give links to topics which will include (But will not give references to the functions themselves. You have to find yourself)


    --Script Settings
    Script.Mass = 10 --int (MassPlayer)
    Script.Speed = 25.0 --float (Speed Mul)
    Script.EnergyToJump = 1500.0 --float (It is for jump)
    function Script:Start()
    self.Force = self.Mass * self.Speed --Created Force Multiple
    self.Direction = Vec3(0,0,0) --Helpfull (Determines where we are going)
    self.entity:SetMass(self.Mass) --Created Mass
    --Camera = Camera:Create(), 0, 0),0, -4)
    self.light = PointLight:Create()
    --For Jump
    self.ETJ = self.EnergyToJump
    function Script:UpdateWorld()
    --The cursor displacement (rotation camera)
    self.offsetx = window:GetMousePosition().x - window:GetWidth()/2
    self.offsety = window:GetMousePosition().y - window:GetHeight()/2
    --Camera Rotation with offset +, self.offsetx/10 +, 0, false)
    --Generate points for a jump
    if self.ETJ < self.EnergyToJump then
    self.ETJ = self.ETJ + self.EnergyToJump * 0.005
    --Camera,0, window:GetMousePosition().z - 4)
    --Direction for move
    self.Direction.x = -Math:Sin(
    self.Direction.z = Math:Cos(
    if window:KeyDown(Key.W) then self.entity:AddForce(self.Direction * self.Force,true) end
    if window:KeyDown(Key.A) then self.entity:AddForce(Vec3(self.Direction.z, 0, self.Direction.x) * self.Force * -1 ,true) end
    if window:KeyDown(Key.D) then self.entity:AddForce(Vec3(self.Direction.z, 0, self.Direction.x) * self.Force,true) end
    if window:KeyDown(Key.S) then self.entity:AddForce(self.Direction * self.Force * -1 ,true) end
    if (self.ETJ - 100) > 0 then
    if window:KeyDown(Key.Space) then
    self.ETJ = self.ETJ - 100
    self.entity:AddForce(Vec3(0, self.Mass, 0) * self.Force * 0.7 ,true)
    window:SetMousePosition(window:GetWidth()/2, window:GetHeight()/2, 0)
    function Script:PostRender(context)
    context:DrawText("Energy to jump" .. self.ETJ,2,2)


    Apply this script to the ball physics and play.


    The lesson was over. You made a simple game. Now you can finish the leveling/ points/ achievements to sell on Steam.


    Here are screenshots of my result:








    I hope you will find useful this tutorial. In the future, I can tell you other things)