Development Blog

• A security camera with render-to-texture set up would be cool.
  
• Laser beam using picking to determine beam length, and creating damage wherever it hits.
  
• Explosion
  
• Conveyer belt.
  
• Tesla lightning.
  
• Text message display.
  
• AI patrol nodes.
  

 

A lot of this stuff involves a combination of models or textures and not just pure code.

Still waiting on Global tesselated hair physics

• A security camera with render-to-texture set up would be cool.
  

 

Would also be cool if the camera followed the player/object like they do in Portal.

 

 

• Laser beam using picking to determine beam length, and creating damage wherever it hits.
  

 

Glad Jazzoyna did this already, so the battle is half over. I've made an actual laser sprite if you want it.

 

 

I'm pretty sure you can use the turret model that's already on the workshop and include it in the SDK. I've made a custom phys file for that as well. Was gonna make HL2 styled turrets until I got pulled aways to do other stuff.

We're making a new one that fits into the modern military theme a bit better:

 

The amount of custom artwork we produce is going to be limited, but I am just creating stuff that is very well-targeted and useful.

 

I'll add the AI and then put it up in the Workshop for $4.99.

http://www.leadwerks.com/werkspace/topic/14318-my-monsters-can-run-through-walls/

 

I think this is a good example of some of the challenges faced with game devs who don't have a ton of experience (towards the end). He's using the crawler and now he introduces a concept of them chasing the player through doors even. He hasn't thought about how that would work. He just wanted the crawler to keep running into the door while it opened. Clearly that's not acceptable in today's games. He simply hasn't gotten that far to see that issue yet and lacks the game dev experience to think forward enough to see it.

 

So this rolls into AI. LE has no AI system. It's brute force homegrown at this point. I still have the feeling that your time is better off making systems that make things easier for us to make games. You are going into a part that a couple years ago you hated and said you'd never do. You are trying to write games for us. I disagree with that approach personally and would prefer you write systems. I think you are better at that and it's a better use of your time. Saying this I have Behavior Trees in mind or even a basic state machine system.

 

Without making actual systems that empower us, people are going to run into issues with their game and the things you've written not working in their game design, which we see a lot of these days.

We've had this discussion before, which is fine, but my take on this is that Leadwerks has these three layers:

• Flowgraph / pre-made scripts
  
• Lua scripting
  
• C++ programming
  

 

Inserting another layer of complexity doesn't make things any easier. In my opinion, it's a way to rearrange things while deferring the decision-making of developing a game.

I really hope that the template system will get an update reflecting these changes. It'd be nice if someone want's to make a game completely in C++ can just clone the necessary files to get the engine to run, rather also cloning a bunch of scripts and assets that they're mostly not gonna use.

 

This benefits both sides, as new users get to make games using the flowgraph and pre-made scripts, while advanced/experienced users have the option to start with a clean slate, and not have the project manager keep copying over files they don't need/want.

 

I can go in-depth with a suggestion thread about this another time.

My approach has been to include all scripts in the core template, in order to avoid the issue of an object not working with a project that wasn't created with the right template...and if someone is that hardcore, they're not even going to be using the template system to begin with.

We've had this discussion before, which is fine, but my take on this is that Leadwerks has these three layers:

• Flowgraph / pre-made scripts
  
• Lua scripting
  
• C++ programming
  

Inserting another layer of complexity doesn't make things any easier. In my opinion, it's a way to rearrange things while deferring the decision-making of developing a game.

 

My opinion is that you can deny an AI system isn't needed until the cows come home, but until you implement one of the common systems out there in the gaming industry you're never going to get your more complex and interesting games that you seek from us.

 

You said yourself that you have plans for implementing a multiplayer system and a GUI system. Why? Given your stance above there would be no need to do such a thing. People can just implement it themselves like you want them to do with AI. Why would you view networking and GUI any different and make plans to implement those systems in LE? An AI system is no different than a networking and GUI system.

 

So for me, your opinion seems inconsistent. All I can think is that you devalue AI because you feel it can be thrown together willy nilly, which hey, let's face it, any of those systems can be thrown together willy nillily. The point of an engine is to provide nice, consistent systems for it's users that make making those things easier. Today your solution to that is to write your own and give it to your users. Do you really think that's the correct solution to this problem?

 

Let's put it this way. Think back before you implemented pathfinding. Do you remember those days? Probably about 1% of the users had things moving around in their game and those users went to great lengths to do so. Your stance was that you didn't need to make a system for them, they should be able to do it themselves. Flash forward to today. Basically every game created uses the pathfinding system in some way and everyone has things moving around their game.

 

When you implemented pathfinding you created a 'movement in game' boom. Every kid on the street could now easily move their character controllers around the scene. Yes, it has issues and limitations and caused you a headache, but would you take it back? Would you remove it from your engine? No way!

 

The exact same thing will happen if you create some kind of AI implementation, which you don't have to fully make yourself but just implement a library that exists like you did for pathfinding.

 

There is no way you can deny the implementation of pathfinding in LE helped people make more interesting games and doing an AI system will do the same.

 

You shouldn't be spending your time implementing custom spaghetti AI code for all these different types of enemies in my opinion. It's a waste of your skill.

Well, all those visual AI systems basically just boil down to a complicated way of representing an "if" statement. Our AI scripts already have a "state machine"...it's a variable called "state".

 

Letting the user adjust a few sliders so they can control a subset of the API without touching any code isn't that useful. The real behavior still has to be written in script, which allows you to do anything you want.

Letting the user adjust a few sliders so they can control a subset of the API without touching any code isn't that useful. The real behavior still has to be written in script, which allows you to do anything you want.

 

You are correct, however, the complexity with AI isn't in the tasks that check for conditions or even do specific actions like shoot a gun (and these are the things we should create in script), it's in structuring all that logic. That's where the AI complexity comes in and that's why having a more structured "if" statement system is important.

 

Imagine if you/we are able to just focus on writing small scripts that do specific checks and tasks and people can pick from a huge library of those and combine them in ways they want visually to make different behaviors.

 

You can devalue these systems all you want, but the entire game industry has moved to behavior trees. If you don't do them today in LE, you'll be doing it in 2 years. If you haven't looked into behavior trees, it's well worth it.

 

I'll stop beating a dead horse now

+1 for behaviour trees.

I notice there is a LUA implementation of behaviour trees.

 

https://github.com/tanema/behaviourtree.lua

 

I've not used it but anyone knows how practical it would be to use in Leadwerks?

 

I've seen some people re-use LUA projects from elsewhere but I've never tried it yet.

 

Is building on existing projects to get an official or community-official solution to some problems a practical option?

 

It sort of gives you an existing 'system' using open code which you can modify rather than being locked out from.

 

Personally I think re-using an library that requires much work to integrate is, if not beyond the skill of most, then beyond the desire of most users who would choose LeadWerks.

 

If that is a viable route then I think there would need to be EXCELLENT and SPECIFIC documentation on how to get these things going.

In general I think it's a good idea to have more scripts though I think Rick has some valid concerns about LeadWerks long term needs.

 

Some more good quality scripts may help people better realise their game ideas. More scripts, and assets using them, might achieve some quick wins for LW. Such as:-

• Better understanding of scripts by users and an expansion of possibilities to reuse them
  
• More 'value' store resources if good scripts included - scripts can be time consuming to produce (right?) but a good script can be re-used many times.
  

 

Scripts don't only have to be available only in their in indvidual assets in the store. There is also the option to make them available elsewhere as incentive to highlight a store item that uses them well. I think there is a wish to keep scripts out of paid items to minimise 'come-back' on old scripts not 100% working at somet future point for paid assets. Perhaps a forum section for store items. I think the new Mercenary asset had the relevant scripts provided without purchase?

 

This area of script production sounds like the sort of thing that Josh doesn't HAVE to be the only person doing everything on. Though he probably wants strong editorial control over and maybe 100% input in some areas it seems not impractical for others to be involved with. More so than core system work.

 

I'd be interested in Josh's take on scripts for sure but it would be cool to see some others and maybe this might help kickstart things a bit. I know there are some scripts up on the wiki and you can usually find answers in the forum (which is excellent guys!) but maybe it should be a little easier to find them.

Maybe this is a good time to put some time into improving the flow graph editor as it is often a natural partner to scripts. This would get some SYSTEM improvements going and maybe they move forwards together.

 

I think most experienced users abandon the flow graph editor as projects get large but maybe with some improvements it can remain useful.

 

A zoom feature seems like the simplest missing feature to implement. Though it the GUI doesn't support scaling at all then probably not so simple.

 

Another easy one seems to be that if you click the object in the flow graph then the script editor opens the right script (only one script per object right?)

 

Maybe some sort of componentised/node based script (not attached to an object) so you can link scripts together and perform logic/decisions before feeding into the next (e.g. Maths functions).

 

Better way to organise all the flow graph objects. A simple note would be a start so you can stick a note next to related items. Maybe clicking the title bar expands/collapses the body and you can collapse all/ expand all/collapse selected/expand selected.

 

Many, or all, of these have been mentioned by others in the forums.

 

Maybe a few quick flow-graph plasters aren't the answer but I think other current engines have something similar and in general it's quite a neat tool that can help users get going. Currently it is feels somewhat bare bones, but with basic UI abilities zoom/show/hide/collapse/group it might help usabilty.

 

I think Josh recently mentioned a desire to address general UI cross-platform limitations and maybe the flow-graph editor is bound by issues in this area but it would be neat if it were possible to have some quick improvement to let us enjoy the new scripts in nice environment.

I've not used it but anyone knows how practical it would be to use in Leadwerks?

 

I'd used it and it works. It's complicated to setup though because behavior trees really need a GUI to be easy. I might do a video tutorial on it.

 

I think the flowgraph in LE is just really meant for level designers making level events and honestly it's great at that.

 

My concern is that Josh thinks he can make our games for us all by himself by providing all the models and scripts instead of focusing his time on systems for the engine that all us to do all that stuff for ourselves easier.