mdgunn

I understand Josh sees a need for better learning material too and the plan was to have more templates (and probably of a more in depth nature) at some point in the future. I don't believe there is time scale on this but I think it has been considered high priority by him in the past. This would probably significantly close the gap that you (and many others) are experiencing. I hope there is some progress or announcement on this soon.

Thirsty Panther's suggestions are good ones.... I'd also suggest a few other things: keeping the thing you are trying to solve very simple and isolated. For example, create a test project where you experiment and build your knowledge, create a blank map for your specific problem of the time, solve that problem with cubes or whatever in the simplest way possible. Consider creating your own project template where you copy in your own own scripts you've built up over time. Just copy the blank project in steam to a new location and give it a new name. Copy in various starting assets from FPS template. E.g. sounds, hud materials etc. So the FPS controller works (its needs various sounds etc). I then tend to create a sub-folder in the scripts folder with my initials on and put scripts in there so its VERY obvious where my own scripts are. The example scripts (particularly the FPS controller and associated scripts - i.e. projectiles etc) are worth studying and tweaking. The online help system has some useful simplified examples which are worth checking out and tweaking to build understanding. Work shop items have some useful scripts with them. Beware though some may not be best practice (e.g. may process something when they should be doing a check and avoiding running code) but they often solve a focused problem. E.g. camera dolly, smoke mine, multi-level elevator etc. I almost always start from an existing script. E.g. the switch one where some of the basics are in place that are hard to remember (e.g. syntax for script parameters, exposing a function to be called by the flow graph - if you use it). System:Print is your friend (but your enemy if running in release code). If you're not sure what's going on System:Print the value and look in the console output. Long term you want a better strategy but for understanding problems it is quick and easy to put in place (and comment out). In general lua is fairly simple at the level you will 99% of the time be using. I don't think there is too much you need to know. Tables are one of the key features that make it a bit different to some other languages but I would not worry about knowing everything about them. The important thing is that they are a container which can hold values, other tables or functions. Because you can have these 3 things in there this gives you a simple mechanism to construct a sort of 'object' where you can store values in slots, create lists of items in sub-tables and work on those values and lists with functions. I think the confusion comes in the way the code needs to be written to talk to these things (e..g self.whatever Script:whatever) it's a bit odd but try to get through it. Leadwerks also has conventions for how it talk to lua (e.g. defining parameters and exposing functions to flow graph). These are not really LUA, just how leadwerks uses lua. Studying existing scripts is the best way to get comfortable with the conventions. Suggest your focus on some things (in isolated test project) like: - System:Print - types such as booleans (checking a boolean condition before running chunks of code is a good practice). - loops - useful but avoid doing many loops if you can (e.g. keep a reference to an object or thing so you can operate on it straight away) and if you have to loop exit out as soon as you have the answer see LUA loops. - Knowing how to loop through a table (check out key/values/pairs) - some built in table functions - manipulate strings - casting an object - So if you have a list of items you might need to cast it to the right thing so your code can access it properly (e.g. an entity etc.) - Understand that all objects are global unless you declare local, so most of the time you SHOULD declare local in your objects. Global is usually bad as if something else creates something with the same name you have issues. It can be useful in games, where you work along and understand ALL the code, to have some limited globals though as on small amounts of code it can be a quick and easy solution. OK this has got way bigger than I had thought it might. Better cut it short here. Suggest that it might be good if you generate a bullet point list of all the things that you can think of regardless of whether they seem silly or not. It's probably impractical to think that you'll get answers to them all here but I'm kind of interested in what you might list. I'd like to think I might do a tutorial or something to help you out, but it would probably take some time to do and I'm not sure I'll get round to it. If I do your list might be useful. Personally I think you have a very valid point about there being a bit of a gap in how you actually sensibly progress on on non-trivial project. Anyway maybe if you do a list and maybe high-light a couple of things that might help most then we may be able to get you on the right track. If you read all that and got this far....you have too much time (me too? - really need to get back to work)....you should be learning LUA in Leadwerks!

There is a workshop item for this. If it works like how you want. Don't have link right now got to rush out to work.

I think you need one per room because the reflections that you see bouncing 'back' of the probe box are what would have hit that box from the central location of the box (er...I think). So if you're in a room but the box doesn't match the room (I usually have the box just penetrating the walls etc - don't know if that is optimal) you're probalby going to see something which doesn't match up with what you should see reflected there. I think if you have an open area you can probably have multiple probes and in that case it might work to have a large encompassing one and maybe that sort of takes over when the if you aren't currently in a more localised one but I've not really checked that out so I'm just guessing.

I think the expectation is that there will be pressure for dual cores to disappear from new machines when AMD Zen is out (late 2016/early 2017?) as I don't think there is going to be a dual core Zen and I *think* even the most basic Zen is expected to be significantly better than any current dual core Intel (which wasn't the case previously).

The thought of unit testing had been through my mind a few times (and just a few days ago actually) but not yet pursued it. This should help a lot. I hope to look at the Behaviour Tree stuff next time I do some AI http://www.leadwerks.com/werkspace/topic/14865-behaviour-tree/page__hl__behaviour. Thanks!

A few suggestions: 1) Take a simpler model (e.g. textured cube or something quick to generate). Make sure you're happy that the basic process of import does usually work. Usually you do have to do calculate normals. 2) Make sure the model in blender looks OK turn on the normal direction display. It looks most like an issue with the source model given just a few triangles seem out. 3) Post a link to your blender file (textures probably not required if it's a normal issue) so others can try.

I seem to keep missing these things. I wonder if there's some way I can be 'push notified' of these events? I think it is always a different forum post so can't 'subscribe' to it.

Great article. Looking forward to the next one!

If I'm correct (I don't use the C++ version just now) the C++ files produced work best in Visual Studio. I think there is a '.sln' (SOLUTION) file produced which I think you can just open and will compile and run to a bare project straight away. You might get it working other compilers but it may be tricky. As I say...I'm personally not a C++ guy, I just saw no response yet and thought I'd tell you what I thought may be the case. Ah...I see you're on Linux. Sorry, guess it must produce something Linux friendly too. I wouldn't know much about that sorry.

Will it work on VS Community Edition 2015? I believe at this VS CE (2015) is now pretty much full VS more or less and as it's free is a good selling point for LW I believe. I know some others engines have mentioned VS CE support.

As a guess, maybe check the entity has a script exists before you access something on it? Some entities coming back are probably not the ones you want to look at and may not have scripts.

Thanks for this! I had a bit of a go at this a while ago but the results weren't pretty.

Interesting reading as always.

Interesting idea. Recent trends in editors have tended towards light-weight editors with plugins to add small extra features which are often simple or text based UI additions. Unfortunately the Leadwerks editor lacks some basic editor tools and doesn't allow plugins. For your scenario I would usually use what in most editors would be called a 'bookmark' at the location I want to return to (not a feature of the editor - but present in most other editors). The other way that is supported is to use Ctrl-G to move to a line number ( so Ctrl-G '0' ENTER will get you to script property area at the top, and CTRL-G '494' ENTER will get you back to your coding location. I think Ctrl-Home and Ctrl-End jump between the top and bottom of the page too. Rick also makes a good point that some good coding practices can help keep things from getting out of hand, such as splitting out functionality into separate files and breaking out lengthy code sections to functions. The main body of the sequential code is then likely to remain close to the property definitions with the function definitions out of the way at the bottom or in separate files. The 'flow code' becomes a series of simple logic statements and function calls and the function names give you something identifiable and memorable to jump to with Ctrl-F should you want to navigate around. It takes some discipline to work this way. I think a lightweight editor with plug-in support would have been a nice way forward to allow the community to drive forward what is perceived to be the necessary extensions, and also to learn and build upon those too. (See Sublime editor, Visual Studio Code, Brackets etc.),

There are a few approaches that might work. Some people might like to know that they have assets that are going to work for them so they get this detailed work of sorting out engine working characters early. However if your new to game dev I would suggest working with assets from the workshop and just getting a game done and under your belt. A good way is to build your game from simple to complex. Personally I try to split everything down into tiny chunks and make sure I can do that thing in isolation on a bare bones map. Literally a cube for a floor with the generic FPS prefab dropped in it. Maybe I'm creating a teleporter or something. Once you have the thing working you can save it out as a prefab and bring that into your main level map. For level maps a possible approach is to 'block out' the level very roughly and quickly with CSG, apply materials and align them to faces then add in external FBX models (chairs, pipes etc) and creatures. It is also possible to export the CSG to a file which you can take into a 3D program then bring it back in as an object. Lighting is probalby best left till late in the map development. You may need to fine tune the amount of lights and the types to retain performance (only some lights should have dynamic shadows). Try to make your first games ones which will not run into performance issues so much anyway, e.g. an 'outdoors', maybe abstract game were there is maybe only 1 light or few. Keep mechanics simple. Better to do multiple short games than 1 big one. Each can tackle different aspects of a bigger project you may be working towards (e.g. something with an inventory, somthing with a better UI, something with more complex lighting etc.) Personally I try to keep any scripts or prefabs etc I create separate so I can easily copy just those folders around if I want to put them in a new project. As far as MP4 goes....you mean for videos? I can't remember if Leadwerks supports that and I couldn't find the list of supported files, but I think it does not (which may be why you're asking)? It will play video files, for cutscenes or whatever (I believe) but you may need to convert to a supported format. When using C++ things are a bit more open as you are essentially using Leadwerks as the core of your game and you can wrap whatever other libraries around it (e.g. extra file type support). So you're game might load the video and play it, then talk to Leadwerks to launch a map. If you're using LUA then you're more 'within the engine', sort of anyway and are more reliant on what it exposes to LUA. You can use LUA libraries to gain some functionality but I think they have to build on what is there (e.g. maybe some AI routines) rather than allowing support of file types not supported by the core. I'm not sure I explained many things well just now so if you've got further questions I'll try and make things a bit clearer. The forum has a handy chat feature (bottom right). So if I'm around you can get in touch that way if you want. Providing I'm actually at my machine and not just lurking . I'm on UK time and am most likely on in the evenings.

You're situation is quite typical of many LW users so don't worry. Many people would use a 3rd party model for a character model and then may model some of their own simple assets, or get them from elsewhere. Get familiar with the Workshop and what is in there. Some things (e.g. post effects are almost essential in most projects). A character model could probably be updated later on without it totally breaking your game as long as the models have similar animations (the names don't need to be the same or anything - you can remap animations at any time). So don't let the lack of a perfect model stop you prototyping out your idea. At the end of the day it will largely stand or fall on the gameplay over the model quality. Arteria 3D are often used for LW models and I've heard Unity models work quite well so buying or using Unity assets is a possibility. Try some free ones first if possible. In general if you can get an animated model in FBX format you should be able to use it. You could try looking through the gallery for people who seem to be highlighting models (in which case they may be showing a model they've made and you may be looking at someone who has some model specialisation - there are a few people). Good luck.

Only difference with Professional (I believe) is that you can use C++ yes, which it sounds like you don't need. Sounds like you are doing 2D side scroller with 3D models? There have been a few of these. Think Angelwolf (http://www.leadwerks.com/werkspace/user/15469-angelwolf/) did one recently for the game jam so if you're stuck you might want to check with Angelwolf for recent experiences, or just post a general request for help.

Does that mean that if you're using orthographic then everything is 'fullbright' if you know what I mean (maybe controlled by ambient level or something). Do you have to just make your graphics have the right look in your art program so 'lit' by drawing them with shadows, highlights etc. and then they'll look the same in Leadwerks?

I'd say the official tutorial *IS* worth going through in that it covers a good portion of what Leadwerks does but you will need a bit more....see below. An often recommended set of video tutorial series is this one. This is beginner level but covers many things. He also has some C++ tutorials if you have that version. I recently watched another set by Rick (often in the forums) here which shows real time development of a game from an experienced Leadwerks user. The game is just for a game jam but the end result is well on the way to being a decent game. https://www.youtube.com/watch?v=OHPP67rJ1Ok These pinned items in the Game Art forum are worth a read (http://www.leadwerks.com/werkspace/forum/57-game-art/). Mapping Standards: http://www.leadwerks.com/werkspace/topic/10016-mapping-standards/ Content Creation Guidelines: http://www.leadwerks.com/werkspace/topic/14017-content-creation-guidelines/ Blender Exporter (though FBX works well too): http://www.leadwerks.com/werkspace/topic/10246-official-leadwerks-exporter-for-blender/ Blender & Leadwerks: http://www.leadwerks.com/werkspace/topic/14215-blender-leadwerks/ In general Leadwerks tries to do be a game engine/tool that a single person could concievably master the whole of and produce a reasonable game that will work across desktop platforms (not mobile). It supports open standards rather than trying to do everything well internally. It doesn't try to model and animate but instead supports importing boned and animated assets which you can then tweak a bit. E.g. re-apply materials, remap animations etc.. It does have CSG brush based capabilties which can help to mock up levels and the idea of prefabs (a container of sorts for CSG/object models etc). You can also export CSG, take into modeller, modify, export, bring back in more complex geometry. LUA scripts attatched to CSG or models can then be very easily setup with parameters so you can tweak them in a UI and connect them together with a flow graph editor. Or you can write almost everything in code if you want and have code talk to code. If you have the C++ edition then you can write (faster?) object-oreinted code and hook into libraries that may only exist in C++. In general I think the software does not have any major 'limits' in terms of texture size or model faces but I don't know for sure. It isn't something I've had a problem with. AI you may need to code yourself, depending on what you want to do, though there is some supplied AI which can navigate using navmeshes which the engine builds. If you are hoping to buy lots of complex assets to do the heavy lifting for you and make you rich then Leadwerks probably isn't going to get you that. if you are hoping to be able to piece together a simple to moderately complex game working through simple issues by youself and assistance of the community and freely availble (generally simple) assets and have fun doing so, then Leadwerks is more like that. IMHO of course. I'd be interested to know what you thought needed to be better in the tutorials as I'm vaguely thinking of writing a few (.....erm maybe).

Not seen this but suggest some very obvious troubleshooting ideas that you may well have tried. Make sure the build output works on your machine, not just running the build from within Leadwerks. Try building the default FPS template project (because I think that has a torch in it too right) and run the OUTPUT of that on yours and the other machines. My only thoughts so far are that maybe something is not going into the build to define the torch light, or that the other machines are using build in GPU perhaps? More info is probably required. You could put a link to a build you've uploaded somewhere and others (with machines that presumably run Leadwerk builds OK) can download and see if the torch light shows. Not much info to suggest much else, given my knowledge anyway.

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.

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.

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.

Yep I saw that with the Merc character (which I bought) and I think that helps pull the trigger. Thanks for informing me Nova's stuff has textures. I will probably buy one now. On the workshop item it mentions the dimensions of textures but I wouln't have read that as certainty that they contain files outside the models. I'm guessing they are the dirtied version. Would have been neat to have a clean version too so you could use it as old and new.