Josh
-
Posts
23,327 -
Joined
-
Last visited
Content Type
Blogs
Forums
Store
Gallery
Videos
Posts posted by Josh
-
-
This is not presently a supported feature. I have a list of a handful of items that are high-priority to implement, and this is one of them. When it is done, it will be very easy to control from the editor.
-
1
-
-
I found a trial of 3.0 to check out in the meantime however, I do have a few questions
The 3.0 trial isn't really comparable in graphics.
Is 3.1 standard going to be available on steam as well? Also, if we buy the indie version now will there be an upgrade option afterwards?Yes, and it will be available as an upgrade from the indie edition on there now.
what kind of time frame are we looking at? I'm looking forward to it.March.
what were the changes from 3.0 to 3.1 that was worth charging people money for? normally minor version for other programs such as 3.x are included for free if you purchased 3.X...Version 3.1 brought an OpenGL 4 deferred renderer and is bringing native support for Linux, editor & all.
-
1
-
-
I am planning to have a free weekend on Steam after 3.1 standard comes out.
-
Simple networking has actually been built into Leadwerks since the first release, but:
- It's not exposed to Lua.
- There's no documentation.
- There's no NAT punch-through.
- There's no high-level entity synchronization or predictive movement.
So for those reasons I don't consider it an official supported feature right now.
We also have access to the Steam peer-to-peer networking library. This is nice because it allows direct communication between two Steam accounts and automatically manages NAT punch-through, but of course only works in a Steam game.
-
1
- It's not exposed to Lua.
-
It should work with animation. It is possible it might not under the right circumstances. I never encountered this with the example game level.
-
Does that pragma line actually work?
-
After the flags parameter, there is a hidden feature I use for lighting shaders:
Shader* Shader::Load(const std::string& path, const int flags, const std::string& precode)
I use it to pass preprocessor defines to the shaders so I don't have to keep a lot of extra versions of them.
-
I have experienced the opposite. Separate scripts are nice for a simple example, but quickly break down as your game gets more advanced.
-
Yes, I am pretty sure I can do that. That idea kind of changes the way I think about rendering, and I love it.It'd be fantastic if we could get both views to render in one pass, yes
-
1
-
-
My goal is to maximize emergent behavior between arbitrary scripts that were not necessarily written to work together. Leadwerks is particularly strong with communication between objects, with the flowgraph and the dynamic nature of the Lua script language. The approach I have taken provides the best ease of use for programmers, who don't have to deal with the cognitive burden of classes straddling different files, and non-programmers who don't have to remember a complicated series of required scripts to make one object work.
-
That kind of illustrates the problem. If another script is looking for an "FPSPlayer" component, it won't work with a third-person player script. I thought about what the Workshop would look like a couple years from now, and realized the namespace requirement would damage a lot of functionality we would otherwise have. It turns the script system into a sets of scripts that all have to be designed to work together, and actually makes the system less modular...which is the opposite of what we want.
-
There's a good reason for this. During the development of Darkness Awaits, we got into a lot of extremely ugly script code like this:
for script in entity.scripts do
if script.health>0 then
if script.TakeDamage)~nil then
result = script:TakeDamage()
break
end
end
end
return result
When this was all we really wanted:
if entity.script.health>0 then
if entity.script.TakeDamage~=nil then return entity.script:TakeDamage()
end
The 1:1 entity to script paradigm reduces a lot of code complexity. As soon as this was implemented, it opened up my creativity since I wasn't stumbling around trying to make code conform to an ideological design that made life harder instead of easier.
In theory, having a bunch of different pieces you put together sounds nice and simple, but in practice those things are not so easily separable. We ended up with excess abstract classes like a HealthManager, that baffled experts and beginners alike. Simplicity has proven to be the best approach.
Also note that the first case is ambiguous. You can't simply poll a variable from an entity, because multiple scripts can have variables with the same names. So if you want non-ambiguous variables, you now have to come up with a namespace for everything. And if your idea doesn't happen to be the same as everyone else's your scripts aren't going to work together.
With a 1:1 design different scripts not written by the same person can work together and create emergent gameplay. For example, pretty much everyone will use 'health' as an indication of how much life an object has. So scripts designed by different people will naturally work together to create new and interesting gameplay mechanics.
-
1
-
-
What I found is that recalculating chunks of the navmesh was too slow when terrain was involved. What is really needed is a separation between static and dynamic geometry, so the static data can be cached and then the dynamic geometry laid on top.
Leadwerks internally already uses a tiled approach, so we're halfway there.
-
I wouldn't do it without the stereoscopic view.
You know what, using geometry shaders we could easily do both views in a single pass. It's not like the vertex pipeline is going to be a bottleneck, so in that case it would cost nothing.
-
You might consider adding a point light to those bullets, but just set their shadow mode to 0. It would probably look pretty good.
-
Calling Entity::Instance() will generally be fast enough for real-time use. Entity::Copy() should not be used in the game loop. A pool of entities will be slightly faster than calling Entity::Instance(), since nothing needs to be allocated.
-
The octree is automatic and built-in:
http://www.leadwerks.com/werkspace/page/graphics?showbanner=0
The whole system was designed around the big forest map and the Zone concept scene. Basically it means all the systems are designed so that if something is happening off-screen or far away, it has no impact on rendering performance. You can keep making the map bigger and more complex, without it slowing down. For example, a non-scalable engine would simply loop through a list of all entities in the scene, every frame. Leadwerks never does that.
Of course there's a practical limit to number of characters onscreen, number of lights being updated, etc., but if you keep those under control you can have very large scenes. I think there are additional optimizations that can be made for the shadow redrawing and character physics, but the most important thing is that the engine is designed in a scalable manner.
-
2
-
-
I wouldn't worry about it quite yet. Some additional encryption is planned to be added later on, so it is likely to be done before any major titles are released.
You are free to release games right now without a problem.
-
We have a grouping system; it's the object hierarchy. However, I see your point and have noticed the same thing.
-
If La Vida switched to Leadwerks, then could it use the code from the Python or Unity3D projects?
For scripting, we use the Lua programming language. Lua is the most popular script language among professional games, with hundreds of AAA titles using it: Crysis, Call of Duty, World of Warcraft, etc.
La Vida is supposed to be open source. In my vision of La Vida, it should have good support for mods. Would this go against that license?A "game maker" with the purpose of exposing the functionality of Leadwerks to people who don't own it is something we definitely do not want. So this is sort of in a gray area.
Although it's much easier to pay $100 or $200 for Leadwerks than $1500 for Unity3D, Leadwerks doesn't appear to have a free version unlike Unity. Can Leadwerks be used alongside other programs (unlike Unity3D)? I mean, could contributors who don't have Leadwerks still write code etc in a different program?I'm not really keen on great numbers of people programming with Leadwerks without owning the software. Their experience would also not be good without the Lua debugger built into our editor. A better approach would be an open-source game for Leadwerks users.
Unity3D has unbreakable limitations (like multi-monitor). But is Leadwerks designed so that any features unincluded can be coded by the user?Almost all third-party game libraries are written in C++. Since Leadwerks is written in pure C++, the standard edition allows easy importing of these libraries into a project, with no wrapping code required.
-
Is that a shader you got from Shadmar? His bloom shader actually uses a script, and the shader file itself doesn't work alone. It's probably a good idea for him to keep those shaders in a sub-folder, to avoid confusion.
The editor presently only allows shader-based post-effects, because I am not 100% happy with how scripts run live in the editor. It needs to be made more user-friendly before I enable that feature.
-
Please post screenshots. I cannot produce any bug like this.
We do not provide a bloom shader at this time.
-
1. Are you on the beta branch in Steam?
2. What GPU do you have?
-
Fixed in beta branch on Steam.
Dynamic BSP / Level creation
in General Discussion
Posted
The brush class is rather complex and involves a lot of different update parameters, so this is not an official feature.