Jump to content

Blogs

Using Multiple Entity Scripts in Turbo Game Engine

During development of Leadwerks Game Engine, there was some debate on whether we should allow multiple scripts per entity or just associate a single script with an entity. My first iteration of the scripting system actually used multiple scripts, but after using it to develop the Darkness Awaits example I saw a lot of problems with this. Each script used a different classname to store its variables and functions in, so you ended up with code like this: function Script:HurtEnemy(amount) if self.enemy ~= nil then if self.enemy.healthmanager ~= nil then if type(self.enemy.healthmanager.TakeDamage)=="function" then self.enemy.healthmanager.TakeDamage(amount) end end end end I felt this hurt script interoperability because you had to have a bunch of prefixes like healthmanager, ammomanager, etc. I settled on using a single script, which I still feel was the better choice between these two options: function Script:HurtEnemy(amount) if self.enemy ~= nil then if type(self.enemy.TakeDamage)=="function" then self.enemy.TakeDamage(amount) end end end Scripting in Turbo Game Engine is a bit different. First of all, all values and functions are attached to the entity itself, so there is no "script" table. When you access the "self" variable in a script function you are using the entity object itself. Here is a simple script that makes an entity spin around its Y axis: function Entity:Update() self:Turn(0,0.1,0) end Through some magic that is only possible due to the extreme flexibility of Lua, I have managed to devise a system for multiple script attachments that makes sense. There is no "component" or "script" objects itself, adding a script to an entity just executes some code that attached values and functions to an entity. Adding a script to an entity can be done in C++ as follows: model->AttachScript("Scripts/Objects/spin.lua"); Or in Lua itself: model:AttachScript("Scripts/Objects/spin.lua"); Note there is no concept of "removing" a script, because a script just executes a bit of code that adds values and functions to the entity. Let's say we have two scripts named "makeHealth100 and "makeHealth75". MakeHealth100.lua Entity.health=100 MakeHealth75.lua Entity.health=75 Now if you were to run the code below, which attaches the two scripts, the health value would first be set to 100, and then the second script would set the same value to 75, resulting in the number 75 being printed out: model->AttachScript("Scripts/Objects/MakeHealth100.lua"); model->AttachScript("Scripts/Objects/MakeHealth75.lua"); Print(entity->GetNumber("health")); Simple enough, right? The key point here is that with multiple scripts, variables are shared between scripts. If one scripts sets a variable to a value that conflicts with another script, the two scripts won't work as expected. However, it also means that two scripts can easily share values to work together and create new functionality, like this health regeneration script that could be added to work with any other scripts that treat the value "health" as a number. HealthRegen.lua Entity.healthregendelay = 1000 function Entity:Start() self.healthregenupdatetime = CurrentTime() end function Entity:Update() if self.health > 0 then if CurrentTime() - self.healthregenupdatetime > self.healthregendelay then self.health = self.health + 1 self.health = Min(self.health,100) end end end What about functions? Won't adding a script to an entity overwrite any functions it already has attached to it? If I treated functions the same way, then each entity could only have one function for each name, and there would be very little point in having multiple scripts! That's why I implemented a special system that copies any added functions into an internal table. If two functions with the same name are declared in two different scripts, they will both be copied into an internal table and executed. For example, you can add both scripts below to an entity to make it both spin and make the color pulse: Spin.lua function Entity:Update() self:Turn(0,0.1,0) end Pulse.lua function Entity:Update() local i = Sin(CurrentTime()) * 0.5 + 0.5 self:SetColor(i,i,i) end When the engine calls the Update() function, both copies of the function will be called, in the order they were added. But wait, there's more. The engine will add each function into an internal table, but it also creates a dummy function that iterates through the table and executes each copy of the function. This means when you call functions in Lua, the same multi-execution feature will be available. Let's consider a theoretical bullet script that causes damage when the bullet collides with something: function Entity:Collision(entity,position,normal,speed) if type(entity.TakeDamage) == "function" then entity:TakeDamage(20) end end If you have two (or more) different TakeDamage functions on different scripts attached to that entity, all of them would get called, in order. What if a function returns a value, like below?: function Entity:Update() if self.target ~= nil then if self.target:GetHealth() <= 0 then self.target = nil --stop chasing if dead end end end If multiple functions are attached that return values, then all the return values are returned. To grab multiple returned values, you can set up multiple variables like this: function foo() return 1,2,3 end a, b, c = foo() print(a) --1 print(b) --2 print(c) --3 But a more practical usage would be to create a table from the returned values like so: function foo() return 1,2,3 end t = { foo() } print(t[1]) --1 print(t[2]) --2 print(t[3]) --3 How could this be used? Let's say you had a script that was used to visually debug AI scripts. It did this by checking to see what an entity's target enemy was, by calling a GetTarget() function, and then creating a sprite and aligning it to make a line going from the AI entity to its target it was attacking: function Entity:UpdateDisplay() local target = self:GetTarget() self.sprite = CreateSprite() local p1 = self.entity:GetPosition() local p2 = target:GetPosition() self.sprite:SetPosition((p1 + p2) * 0.5) self.sprite:AlignToVector(p2 - p1) self.sprite:SetSize(0.1,(p2-p1):Length()) end Now let's imagine we had a tank with a main gun as well as an anti-aircraft gun that would ward off attacks from above, like this beauty I found on Turbosquid: Let's imagine we have two different scripts we attach to the tank. One handles AI for driving and shooting the main turret, while the other just manages the little machine gun. Both the scripts have a GetTarget() function, as the tank may be attacking two different enemies at once. We can easily modify our AI debugging script to handle multiple returned values as follows: function Entity:UpdateDisplay() local targets = { self:GetTarget() } --all returned values get put into a table for n,target in ipairs(targets) do local sprite = CreateSprite() self.sprites.insert(sprite) local p1 = self.entity:GetPosition() local p2 = target:GetPosition() sprite:SetPosition((p1 + p2) * 0.5) sprite:AlignToVector(p2 - p1) sprite:SetSize(0.1,(p2-p1):Length()) end end However, any scripts that are not set up to account for multiple returned values from a function will simply use the first returned value, and proceed as normal. This system supports both easy mix and match behavior with multiple scripts, but keeps the script code simple and easy to use. Scripts have easy interoperability by default, but if you want to make your function and variable names unique to the script it is easy to do so. Let me know if you have any other ideas for scripting in Turbo Game Engine.

Josh

Josh

True Single-Pass Stereo Rendering in Turbo Game Engine

Virtual reality rendering is very demanding on hardware for two reasons. First, the refresh rate of most VR headsets is 90 hz instead of the standard 60 hz refresh rate most computer monitors operate at. This means that rendering must complete in about 11 milliseconds instead of 16. Second, we have to render the scene twice with two different views, one for each eye. Without any special optimizations, this roughly means that we have to pack 16 milliseconds worth of rendering code into five milliseconds. There are a few optimizations we can make to improve efficiency over a naive implementation. Although VR rendering requires two different views to be rendered, the two views are only a few centimeters apart. We can perform culling for both views at once by simply widening the camera frustum a little bit so that both eyes are included the camera volume. For rendering, Nvidia provides an extension for single-pass stereo rendering. This doubles up the geometry and renders to two different viewports at once, ensuring that the engine makes the same number of draw calls when rendering in stereo or normal mode. (The same can be done using a geometry shader with Intel graphics, although it has yet to be determined if VR will be possible on this hardware.) Here is the result: Combined with all the other optimizations I've packed into Turbo, like clustered forward rendering and a multithreaded rendering architecture designed specifically for VR, this makes VR rendering blazingly fast. How fast is it? Well, it's so fast that SteamVR diagnostics thinks that it is going backwards in time. Take a look at the timer in the lower left corner here: The obvious conclusion is that we have successfully broken the speed of light barrier and time travel will be possible shortly. Start thinking about what items or information you want to gift your past self with now, so that you can be prepared when I start offering temporal tourism packages on this site.

Josh

Josh

What the Heck is Josh Doing?

I finished our first little project for NASA and it was a big success. We only had two weeks to produce a VR demo and it came in under budget with a great result. So that is great. Right now I am staying in my brother's house in California. I'm in a room surrounded by boxes. I need to take a shower and my cat is upstairs meowing for food. I also need a haircut. The next version of Leadwerks is pretty much already written. I want to roll back the repo a bit before I started really hacking up the engine to make Turbo. There was a point back around April where I finally put Turbo on its own repo and separated the two code bases. Theoretically I could be working on it right now, but in reality I find it very difficult to settle into the deep concentration that hardcore coding requires. I do the best when I am comfortable in my surroundings, and right now that is not the case at all. My cat is still meowing. Loudly. So now that I am back in the U.S., where should I go? It feels nice to be back in southern California. Rent for a one-bedroom apartment anywhere here that is nice to live will run about $2000 / mo. When you factor in taxes, that means you actually need to make $3000/mo. to pay for that $2000 rent. Now add another $2000 in living expenses (again, times 1.5 for the money you have to actually earn to pay that). That works out to $72,000 in annual living expenses. Not for buying anything, just for living. I can afford it, but do I want to pay for that? The U.S. is pretty uniform. Everywhere you go, American English is the main spoken language. You can find restaurants, bars, coffee shops, Staples and Target, everywhere you go. Shipping countrywide is cheap and fast. Everything is distributed pretty evenly across the country except high-paying jobs and natural scenery. If I were to settle down somewhere in the midwest I could get my cost of living so low that I could just live off the interest in my bank account and pour any income I make into investments. I don't think this will be a very popular thing to do that people tell me is a good idea, but not a lot of people have the freedom i have. I am sure people here in California would say "why the hell would you move to Nebraska?" (or wherever) but is it really any different from living somewhere that is "cool" like Austin? Does Omaha have bars and coffee shops? Yes? So what is the difference? After living in Europe, New York is about as boring to me as Oklahoma City. I don't really see a difference between the two except one charges you a lot of money so you can feel like you are a superior person while being just as bored. As far as business opportunities go, nothing I have ever succeeded with came about as a result of living in proximity to other people in the tech industry. Everything has come about as a result of being at a conference or interacting online. Physical proximity has never done anything for me. Of course I love the Pacific Ocean and the natural beauty of California, but do I love it enough to pay an extra $40,000 a year to live near it? Or would I rather just put that money away into investments that are doubling year over year right now? What is the wise thing to do with the realities of technology and society in 2018? I need to get set up and comfortable so I can get back into some deep coding sessions. I'm going to go buy a new laptop and get a plane ticket to a city I have never been. And I need to feed my cat. On an unrelated note... I was scrolling through iTunes the other day and I noticed it was very slow on my 4K display. I correctly guessed that iTunes on Windows does not use hardware acceleration for drawing. So now all my music is stuck in this program and I am forced to scroll through this stuttering display of images to find music. And I don't have any choice. Digital music was supposed to make life easier but it's giving me a worse experience. And the Bose music player I have, although it is very compact, it gives me much worse sound quality than a nice mid-level shelf CD system.  So why am I doing this? After going without any physical media for a few years, I think I am going to start collecting CDs again. The sound quality is better, the experience is better, and rummaging for used CDs was a fun hobby I used to engage in before the wonders of technology eliminated any reason we have for ever leaving the house. Also, there is no good new music, and I don't expect the American music and film industries to every produce anything of value ever again, so everything I will ever want has already been released on physical media. At the same time, there is a wealth of high-quality movies and albums I have never seen or heard if I go backwards. I might even get a component system and add a record player. The sound quality is theoretically better but I just remember record players making terrible pop and scratch sounds, so I'm not sure. I also have this weird urge to buy an original Mortal Kombat arcade machine. And I know that, like any drug, it will begin with one and quickly spiral out of control. I like my job a lot but I don't really like the modern world and I would like everything except for PC gaming to just go back to the 1980s.

Josh

Josh

Some Road Blocks

I've uploaded a new release last night correcting the player's pickup to be much more reliable. It should be very rare for a case in which the player is in a object and releases it causing the player to fly backward. I could have kept objects solid but that caused another can of worms. I also posted this on my OneDrive due to issues of people not being able to download it from this site. Yesterday I was working on implementation of the power balls and the launcher. I've written a rough draft of this a few weeks ago and I had it fully working in normal player code. When I started to work on the VR version, that's when I started to run into some problems. First, I didn't like how the code was looking. It involved a lot of referencing of entities and classes. What made it hard is that the VR implementation was different from the normal players. What didn't help was after too many restarts of my application with VR enabled, the entirety of Steam would just crash. So developing for VR was very frustrating. With Turbo coming a long, I wanted my code to work with little modification as possible. I've written a function wrapper that'll only be called if the application is ran under Leadwerks. This both will save time in replacing these functions when the time comes, and get's me used to the new functions. One thing I'd still have to fix is how Lua is implemented in the new engine. Most of the heavy functionalities are in classes which will defiantly keep self.entity for referring to the entity it's being used on. However somethings will still need to be changed and there are a lot of unknowns right now. With that being said, I think it's safe to say it'll be best to focus on the art and assets going forward. With the amount of time I have to make these assets, I'm sure more clarification with Lua scripts with the new engine will surface, maybe even a beta to play with. But with it being Leadwerks or Turbo, they both need assets. VR mode will also be dropped for now. It'll still be there, just not fully supported. You'll need to run the app with -devmode to see the VR tab now. After the project transitions into Turbo, VR development will continue. I shall be going back to my Linux machine with my ultra wide color calibrated monitor to work on these assets. I've created a lot of Vectronic themed stuff in the past and I'm going to go through it and see what I can savage from it. All my models are done in Blender, and I want to create all textures in GIMP this way my files can be used with free and open sourced tools. Also, if there is any Linux developers who wish to use this package, they don't have to be hit in the face with Maya and Photoshop files. Releases will slow down, but I'll be posting screenshots of my work soon.  

reepblue

reepblue

A value for everyone?

Hi Leadwerkers ⚙️, today I have a cool announcement to make. In the past two years I was working on the Phodex Framework, which is a set of helpful tools, utilities and systems, created to unleash Leadwerk's true power and potential, to be able to create the games I had in mind. Now, that I have released my first Leadwerks game Bladequest: The First Chapter and the Phodex Framework has proven its worth in practice, I thought it is time to share some parts of the framework, especially those I think everyone could make use of. I step by step will release different components of the framework, some of them are free, some of them paid. The best is, the first component, the very powerful and flexible Event System is already available for free. If used correctly, it can massively improve the structure of your code and also offers you the opportunity, to build your own powerful systems upon it. For the future I also plan to produce some video tutorials to explain everything more detailed. For now you can read the documentation, that comes with each component. The following components are planned to be released in the future:     🔹 Advanced Animation Manager     🔹 Advanced Debugging Functions     🔹 Easy Raycaster System     🔹 Helper Functions     🔹 Input Manager     🔹 Object Orientation for LUA     🔹 Save & Load System Together, those systems will massively improve your Leadwerks experience. I can't imagine working without them anymore and am sure you will feel them same once you use them. As always stay cool and have a nice day Markus from Phodex Games

Phodex Games

Phodex Games

Trademark for "Turbo Game Engine"

About six months ago I filed a trademark for the term "Turbo Game Engine". Today I heard back from the US Trademarks Office. I sent the requested reply. So it looks like we will get a trademark for the name "Turbo Game Engine" which means no one else can legally use it. 👍 This was the whole point of me announcing the name and putting it up for sale as a commercial product six months ago.

Josh

Josh

How to Expose C++ Classes to Lua in Turbo Game Engine

I'm using the excellent sol2 library to interface C++ and Lua in the upcoming Turbo Game Engine. I've decided not to create an automatic header parser like I did for tolua++ in Leadwerks 4, for the following reasons: There are a lot of different options and special cases that would probably make a header parser a very involved task with me continually discovering new cases I have to account for. sol2 is really easy to use. Each class I want available to Lua will have a static function the Lua virtual machine code can call when a new Lua state is created. The new_usertype method is able to expose a C++ class to Lua in a single command. At a minimum, the name of the class and the base class should be defined. This method can accept a lot of arguments, so I am going to break it up over several lines. void Vec3::InitializeClass(sol::state* luastate) { //Class luastate->new_usertype<Vec3> ( //Name "Vec3", //Hierarchy sol::base_classes, sol::bases<Object>() ); } We can export members to Lua very easily just by adding more arguments in the call to new_usertype: //Members "x", &Vec3::x, "y", &Vec3::y, "z", &Vec3::z, Metamethods are special operations like math operands. For example, adding these arguments into the method call will set all the metamethods we want to use. //Metamethods sol::meta_function::to_string, &Vec3::ToString, sol::meta_function::index, [](Vec3& v, const int index) { if (index < 0 or index > 2) return 0.0f; return v[index]; }, sol::meta_function::new_index, [](Vec3& v, const int index, double x) { if (index < 0 or index > 2) return; v[index] = x; }, sol::meta_function::equal_to, &Vec3::operator==, sol::meta_function::less_than, &Vec3::operator<, sol::meta_function::subtraction, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator-), sol::meta_function::addition, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator+), sol::meta_function::division, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator/), sol::meta_function::multiplication, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator*), sol::meta_function::unary_minus, sol::resolve<Vec3()>(&Vec3::operator-), sol::meta_function::modulus, &Vec3::operator%, And then finally the class methods we want to use can be exposed as follows: //Methods "Length", &Vec3::Length, "Cross", &Vec3::Cross, "Normalize", &Vec3::Normalize, "Inverse", &Vec3::Inverse, "Distance", &Vec3::DistanceToPoint In C++ you can not retrieve a pointer to a function, so we are going to create a quick Lambda expression and expose it as follows: //Constructor luastate->set_function("Vec3", [](float x, float y, float z) {return Vec3(x, y, z); } ); This allows us to create a Vec3 object in Lua the same way we would with a constructor in C++. Here is the complete Vec3 class initialization code, which makes Lua recognize the class, exposes the members, adds math operations, and exposes class methods: void Vec3::InitializeClass(sol::state* luastate) { //Class luastate->new_usertype<Vec3> ( //Name "Vec3", //Hierarchy sol::base_classes, sol::bases<Object>(), //Members "x", &Vec3::x, "y", &Vec3::y, "z", &Vec3::z, "r", &Vec3::x, "g", &Vec3::y, "b", &Vec3::z, //Metamethods sol::meta_function::to_string, &Vec3::ToString, sol::meta_function::index, [](Vec3& v, const int index) { if (index < 0 or index > 2) return 0.0f; return v[index]; }, sol::meta_function::new_index, [](Vec3& v, const int index, double x) { if (index < 0 or index > 2) return; v[index] = x; }, sol::meta_function::equal_to, &Vec3::operator==, sol::meta_function::less_than, &Vec3::operator<, sol::meta_function::subtraction, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator-), sol::meta_function::addition, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator+), sol::meta_function::division, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator/), sol::meta_function::multiplication, sol::resolve<Vec3(const Vec3&)>(&Vec3::operator*), sol::meta_function::unary_minus, sol::resolve<Vec3()>(&Vec3::operator-), sol::meta_function::modulus, &Vec3::operator%, //Methods "Length", &Vec3::Length, "Cross", &Vec3::Cross, "Normalize", &Vec3::Normalize, "Inverse", &Vec3::Inverse, "Distance", &Vec3::DistanceToPoint ); //Constructor luastate->set_function("Vec3", [](float x, float y, float z) {return Vec3(x, y, z); } ); } To add your own C++ classes to Lua in Turbo, you will create a similar function as above and call it at the start of the program.

Josh

Josh

FBX Converter Updated

A small update has been published to the default branch of Leadwerks Game Engine on Steam. This updates the FBX converter so that the scene units (meters, feet, etc.) are read from the file and used to convert the model at the proper size. Previously, the raw numbers for position, scale, and vertex positions were read in as meters. The new importer also supports both smooth groups and per-vertex normals, so models can be imported more reliably without having to recalculate normals.

An error in the probe shader that only occurred when the shader was compiled for VR mode has also been fixed.

Josh

Josh

The reincarnation of Vectronic: Vec-Tec

For who those who don't know (or remember) Vectronic was my first person puzzler project I was developing from 2013-2016 starting with the Source Engine and then onto Leadwerks. The goal of the project was to create a puzzle game and allow people the assets to make their own puzzles. Although it never saw it's end, you can still play the demo here. So what happened? Vectronic was how I pretty much learned a lot about programing, art and game design in general. I kept going back working on it for a month or so and then stop because I would hit a road block with assets, code, performance, or time. I made a lot of cool things too that just never saw the light. Over the years however, I also noticed I don't have patience to work on one game alone for months at a time. I do however like to play around with stuff so I began to think: "What if I had a project for me to tinker with and post it publicly every so often?" I'm more busy than I was in the past so time is more limited. However, I've probably written Vectronic game code over 50 times and I now know the right way of doing such. So what's the plan? After some experimentation, I've decided to go ahead and start a new project taking everything I did and learned with Vectronic and making a base template for people can use for their own purposes. My packaged game will be free to download and play (Because it's just me playing around) while the assets and will be posted on the Leadwerks Marketplace for a charge.The package will contain all assets to build your own test chambers, and you'll also get the original source files too! My release game will act as an outlet to my tinkerings and provide as an advertisement to the asset pack. With the code, the idea is that everything will be modular and users can easily create their own power balls to do various of things. The power balls can now be applied to any entity under certain conditions so there is no need for a VecBox.lua script anymore. There will be plenty of examples for many to see how things were done. I learn best by references and examples, and having code, art, and maps accessible should help new users into learning game design, or aiding developers in assets to start their ideas. I've decided to change the name to Vec-Tec as the asset pack will be in the Vec-Tec Research Center. Also with the new approach, I think it's time to drop the name Ive been using for four years. You can give Vec-Tec a try right now here!  It's very minimal, there is no art, but the foundation is there. VR is now gonna be a thing with this, If you have a VR HMD, you can play any map in Roomscale VR! I hope this is a start of a remarkable development. I hope you are interested and see value in this  project. You can find the project page here for the latest updates and releases.

reepblue

reepblue

Turbo Game Engine Beta Updated

An update is available for the new Turbo Game Engine beta. Fixed compiling errors with latest Visual Studio version Fixed compatibility problems with AMD hardware Process is now DPI-aware Added high-resolution depth buffer (additional parameter on CreateContext()). Subscribers can download the new version here.

Josh

Josh

Introducing the new game

Hi there 🤗 It is very important for me that I only deliver you interesting news and good content and would feel bad, if I don’t. Therefore I created a short survey where you can tell me what you want to get notified about and what not. But for this time I am pretty sure to have interesting news for you. Today I would like to introduce the idea for my next game. Its called "Bladequest" here, because it emerges from "Bladequest - The First Chapter", however I would like to give it a new name. I will probably bring a content update to The First Chapter turning it into Bladequest, when I have a name for my new game. At the end you also have the opportunity to tell me your thoughts about it, by participating in a short survey. So I recently did all the pre-production and am glad to finally present you all the new concepts and features. So let’s go! 💎 The general idea
In Bladequest you are an adventurer living in a small house, outside in the forest. There are different places where you can travel to at any time. Your goal is to earas much gold as possible, by looting everything you find. Of course there will be a reason you want to do this, but I don’t want to spoil it yet. But the places you visit are not abandoned. Bandits, Skeletons, Goblins and other creatures are getting in your way, preventing you from looting. Every time you visit a place, the number of enemies, their location and the time of day will be different and sometimes you even meet vicious end bosses. Once you purged a place, you need to wait a bit, until you can visit it again, to make more gold. In the meantime you can have a good time spending your money, or go for other adventures. Your gold can be spend for new weapons, equipment and even pets. This promises to be a lot of fun. 💎 New gameplay mechanics I especially made myself a lot of thoughts about this, as this is what makes the game fun! ✔️ Travel to different places ✔️ Buy new equipment & items ✔️ Own Player Home ✔️ Destroyable Objects ✔️ New combat features such as parrying and kicking ✔️ All new loot mechanic ✔️ Hidden treasure rooms 💎 New Sound Design Sound & Music is very important for an immersive and atmospheric game, therefore I want to bring the sound design to a new level! ✔️ Professional soundtrack ✔️ High quality sound effects, especially for combat ✔️ New exciting sound events 💎 Content
A lot of new exciting content is planned. ✔️ More enemy types ✔️ More weapons ✔️ More places, including exterior scenes 💎 AI The AI of the First Chapter is one of the first complex AIs I wrote and I got some critics on it, but because I have more experience now and due to the revised systems I believe to be able to fix this issue. ✔️ Smarter AI ✔️ More immersive behavior (e.g. different Idle behaviors) ✔️ More dangerous ✔️ Special enemies, behaving differently 💎 Design & Graphics
The main focus for Bladequest is to make it as performant as possible. I will also fine tune the graphics, work on the models and animations to give the graphics the final touch. Because Bladequest introduces many new features and mechanics I will also revise the UI design. ✔️ New effects like SSAO ✔️ New UI Design ✔️ Revised Models & Animations 💎 System Optimization I am revising nearly all of the systems, bringing them to a whole new level. This includes the UI System, Rendering, Animations, AI, Sound and so on. ✔️ Better Performance ✔️ More Stability ✔️ Allows more complex features ✔️ Save & Load mechanic That’s it so far. Keep in mind that all of this is a work in progress. Not all ideas or features may find their way in the game, but I am very optimistic and can’t wait to make them come true. I am very excited about this game myself and I really mean it, I want to play it NOW! What about you? Tell me your thoughts in this short survey, can’t wait to hear what you think. Stay cool! Markus from Phodex Games 💥 Get Bladequest: The First Chapter on Steam
✔️ Give Feedback for Bladequest: The First Chapter
🎬 Offical YouTube Channel

Phodex Games

Phodex Games

Luawerks Updated

Luawerks has been updated to 1.2.6, making some small adjustments and fixes to the system. If you have previously purchased Luawerks, this update is available for free on the Leadwerks Marketplace. Following changes include: Fixed flag typo correcting LUAWORKS to LUAWERKS Moved error.mat/tex to the Materials/Common folder Added a useuisystem boolean to disable the menu, Adjusted VR mode not to call any UI elements. At this time, this update is only exclusive to the Leadwerks Marketplace. About Luawerks Luawerks is a Lua framework for video games developed on the Leadwerks Game Engine. It supplies developers with additional functions, handles the game loop and allows them to debug their code with a developers console. With all that out of the way, you can focus on making your game fun! You can purchase Luawerks from the Leadwerks Marketplace for $9.99. For documentation and bug reporting, please visit the GitHub page.  

reepblue

reepblue

Pre-Alpha v1.1

After three weeks of work, Pre-Alpha v1.1 is ready.   Terrain The terrain has seen some behind the scenes improvements with speed as well as visual improvements to geometry and texturing.  When I manage to get Texture Arrays working I will be able to finish of the new texturing shader that will include Tessellation and over 16 different texture maps as well as various masks that will paint according to erosion and forest locations. An image of one of the mountains randomly placed in the First World, textured with two 4k textures.  The way the generator works is there is a predefined list of terrain features, like mountains, rivers and valleys.  Based on a low resolution base map which is unique for each fragment, these features are placed at different scales, positions and rotations.  They will also merge with one another to provide enough variation that it will be hard to see any similarities. At the moment though there are not enough maps to make this unnoticeable.           Saving and Loading I have now implemented the ability to save and load a game.  Currently the only states that are saved are the players position, stats and inventory. Each slot shows the date and time that it was saved on as well as the save name and version number.  Slots can be deleted and overwritten.  The version number will change over the course of the updates, but the ability to load older versions will always be available.  And to save a new game, click the empty slot then click save. Now that this mechanic is done I can work on more game play.             What's Next The next step is to improve the blacksmith and general store.  These two places will be the first to provide work opportunities for the player.  These opportunities will improve skill and eventually allow you to buy and use crafting equipment outside of the towns. I will also be implementing some other mercenary characters and animals to hunt.  The mercenaries will just offer some fun conflict to begin with and the animals will offer another source of income.  I hope to have a deer and wolf done by the next update in a few weeks.   The full change log is packaged with the game, here.

The new vehicle for Mars

With Josh's news about Nasa, it was the motivation to develop this model of an explorer on Mars with six wheels. It wasn't so complicated after all, and I think it fits more into a Mars game, the real problem is, I don't know anything about textures, and possibly I have to do magic so that this can look nice in some way or another.  But for my taste, it's nice. 



Yue

Yue

Leadwerks Software to Provide VR Services to NASA

TLDR: I made a long-term bet on VR and it's paying off. I haven't been able to talk much about the details until now. Here's what happened: Leadwerks 3.0 was released during GDC 2013. I gave a talk on graphics optimization and also had a booth at the expo. Something else significant happened that week.  After the expo closed I walked over to the Oculus booth and they let me try out the first Rift prototype. This was a pivotal time both for us and for the entire game industry. Mobile was on the downswing but there were new technologies emerging that I wanted to take advantage of. Our Kickstarter campaign for Linux support was very successful, reaching over 200% of its goal. This coincided with a successful Greenlight campaign to bring Leadwerks Game Engine to Steam in the newly-launched software section. The following month Valve announced the development of SteamOS, a Linux-based operating system for the Steam Machine game consoles. Because of our work in Linux and our placement in Steam, I was fortunate enough to be in close contact with much of the staff at Valve Software. The Early Days of VR It was during one of my visits to Valve HQ that I was able to try out a prototype of the technology that would go on to become the HTC Vive. In September of 2014 I bought an Oculus Rift DK2 and first started working with VR in Leadwerks. So VR has been something I have worked on in the background for a long time, but I was looking for the right opportunity to really put it to work. In 2016 I felt it was time for a technology refresh, so I wrote a blog about the general direction I wanted to take Leadwerks in. A lot of it centered around VR and performance. I didn't really know exactly how things would work out, but I knew I wanted to do a lot of work with VR. A month later I received a message on this forum that went something like this (as I recall): I thought "Okay, some stupid teenager, where is my ban button?", but when I started getting emails with nasa.gov return addresses I took notice. Now, Leadwerks Software has a long history of use in the defense and simulation industries, with orders for software from Northrop Grumman, Lockheed Martin, the British Royal Navy, and probably some others I don't know about. So NASA making an inquiry about software isn't too strange. What was strange was that they were very interested in meeting in person. Mr. Josh Goes to Washington I took my first trip to Goddard Space Center in January 2017 where I got a tour of the facility. I saw robots, giant satellites, rockets, and some crazy laser rooms that looked like a Half-Life level. It was my eleven year old self's dream come true. I was also shown some of the virtual reality work they are using Leadwerks Game Engine for. Basically, they were taking high-poly engineering models from CAD software and putting them into a real-time visualization in VR. There are some good reasons for this. VR gives you a stereoscopic view of objects that is far superior to a flat 2D screen. This makes a huge difference when you are viewing complex mechanical objects and planning robotic movements. You just can't see things on a flat screen the same way you can see them in VR. It's like the difference between looking at a photograph of an object versus holding it in your hands.
What is even going on here??? CAD models are procedural, meaning they have a precise mathematical formula that describes their shape. In order to render them in real-time, they have to be converted to polygonal models, but these objects can be tens of millions of polygons, with details down to threading on individual screws, and they were trying to view them in VR at 90 frames per second! Now with virtual reality, if there is a discrepancy between what your visual system and your vestibular system perceives, you will get sick to your stomach. That's why it's critical to maintain a steady 90 Hz frame rate. The engineers at NASA told me they first tried to use Unity3D but it was too slow, which is why they came to me. Leadwerks was giving them better performance, but it still was not fast enough for what they wanted to do next. I thought "these guys are crazy, it cannot be done". Then I remembered something else people said could never be done. So I started to think "if it were possible, how would I do it?" They had also expressed interest in an inverse kinematics simulation, so I put together this robotic arm control demo in a few days, just to show what could be easily be done with our physics system.   Turbo Game Engine is Born With the extreme performance demands of VR and my experience writing optimized rendering systems, I saw an opportunity to focus our development on something people can't live without: speed. I started building a new renderer designed specifically around the way modern PC hardware works. At first I expected to see performance increases of 2-3x. Instead what we are seeing are 10-40x performance increases under heavy loads. Once I saw this I was very encouraged, so I decided to name the new engine "Turbo Game Engine" (the point is absolutely unmissable) and bought the domain name turboengine.com. During this time I stayed in contact with people at NASA and kept them up to date on the capabilities of the new technology. At this point there was still nothing concrete to show for my efforts. NASA purchased some licenses for the Enterprise edition of Leadwerks Game Engine, but the demos I made were free of charge and I was paying my own travel expenses. The cost of plane tickets and hotels adds up quickly, and there was no guarantee any of this would work out. I did not want to talk about what I was doing on this site because it would be embarrassing if I made a lot of big plans and nothing came of it. But I saw a need for the technology I created and I figured something would work out, so I kept working away at it. Call to Duty Today I am pleased to announce I have signed a contract to put our virtual reality expertise to work for NASA. As we speak, I am preparing to travel to Washington D.C. to begin the project. In the future I plan to provide services for aerospace, defense, manufacturing, and serious games, using our new technology to deliver VR simulations with performance and realism beyond anything that has been possible until now. My software company and relationship with my customers (you) is unaffected. Development of the new engine will continue, with a strong emphasis on hyper-realism and performance. I think this is a direction everyone here will be happy with. I am going to continue to invest in the development of groundbreaking new features that will help in the aerospace and defense industries (now you understand why I have been talking about 64-bit worlds) and I think a great many people will be happy to come along for the ride in this direction. Leadwerks is still a game company, but our core focus is on enabling and creating hyper-realistic VR simulations. Thank you for your support and all the suggestions and ideas you have provided over the years that have helped me create great software for you. Things are about to get very interesting. I can't wait to see what you all create with the new technology we are building.

Josh

Josh

Leadwerks Spanish

As far back as I can remember, I've always been interested in video games, but over time I've learned that it's always necessary to learn something and that thanks to Josh when he gave me his free Leadwerks Script license, I got to know Leadwerks and I really loved it.  My point of view is that Leadwerks is much better than other video game platforms I've been on, and it's that Leadwerks is aimed at enthusiastic people without knowledge who want to make a game, and with this software it's all very easy.  However, something interesting about it is that I have understood that one person doesn't make a game, and even if you have a wonderful tool I can't do it all by myself. That's why I decided to translate my knowledge of the Leadwerks engine into a website in Spanish, the goal is that many Spanish-speaking people know it and therefore socialize with people of my language who suddenly we are interested in making a game, so that being two or three people can possibly do something fun at the level of the Leadwerks engine.  Translated with www.DeepL.com/Translator

Iris3D Games  Leadwerks Spanish

Yue

Yue

The new vehicle

The current vehicle doesn't convince me of much, that's why I've wanted to change it for one that is more suited to the Mars scenario.  A 6-wheeled vehicle is much better and in the absence of having what it takes to create a custom model and in the absence of money, I think the next model is fine. Although I could try to make one, but I'm sure it would never end.   The new vehicle completely ignores the spring system in the rims, only hinge joints to prevent this from getting screwed up at high speeds, even if it is damaged is not as evident as reaching high speeds with the sliding joints.  Although there is always the hope that Josh doesn't come across the Atlantic Ocean in the best style of the film the shipwreck. In the end, I don't seem to have made any progress, I create a simple vehicle system, and again I create it again, this is a repetitive shekel, but the advantage from my point of view is that I find ways to make the same process much easier and in the process I learn new things. 
Translated with www.DeepL.com/Translator      

Yue

Yue

Vector Image Support

Building on the Asset Loader class I talked about in my previous blog post, I have added a loader to import textures from SVG files. In 2D graphics there are two types of image files. Rasterized images are made up of a grid of pixels. Vector images, on the other hand, are made up of shapes like Bezier curves. One example of vector graphics you are probably familiar with are the fonts used on your computer. SVG files are a vector image format that can be created in Adobe Illustrator and other programs: Because SVG images are resolution-independent, when you zoom in on these images they only become more detailed: This makes SVG images perfect for GUI elements. The Leadwerks GUI can be rendered at any resolution, to support 4K, 8K, or other displays. This is also great for in-game VR GUIs because you can scale the image to any resolution. SVG images can be loaded as textures to be drawn on the screen, and in the future will be able to be loaded as GUI images. You can specify a DPI to rasterize the image to, with a default setting of 96 dots per inch.

Josh

Josh

Asset Loader Class

There's a discussion on the forum that sort of veered into talking about Khronos' GLTF file format specification: Some of this gave me some ideas for changes in the art pipeline in Turbo Game Engine. I was not feeling very concentrated today so I decided to do some easy work and implement a loader class: class Loader : public SharedObject { public: std::vector<wstring> extensions; virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; Then I created a TEX texture loader class: class TEXTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; When the engine is initialized it creates a TEXTexLoader object and saves it in a list of texture loaders: GameEngine::Initialize() { textureloaders.push_back(make_shared<TEXTextureLoader>()); } And the class constructor itself creates an array of file extensions the loader supports: TEXTextureLoader::TEXTextureLoader() { extensions = { "tex" }; } When a texture is loaded, the engine looks for a texture loader that matches the extension or the loaded file path. At this point, all we have done is restructured the engine to do the same thing it did before, with more code. But now we can add new loaders for other file formats. And that is exactly what I did. You can now load textures directly from PNG files: class PNGTextureLoader : public Loader { public: virtual bool Reload(shared_ptr<Stream> stream, shared_ptr<SharedObject> o, const int flags = 0)=0; }; I've done the same thing for model file loading as well, although I have not yet added support for any other file types. If we can add a C++ loader, we should be able to add one with Lua too. I haven't worked out the details yet, but it could work something like this: function LoadModelObj( stream, model ) while stream:EOF() == false do -------------- end end AddModelLoader(LoadModelObj) So with that, you could download a Lua script that would add support for loading a new file format. I think in the new engine we will support all common image formats, including Photoshop PSD, as well as DDS, KTX, and our existing TEX files. Textures loaded from image formats will be less optimal because mipmaps will be generated on loading. Settings like clamping and filter modes will be stored in the associated .meta files, which means these files will start getting published along with your game asset files. This is a change from the Leadwerks 4 way of doing things.

Josh

Josh

×