Pixel Perfect

If you can find the 'Leadwerks User Guide' by Aggror then I would highly recommend that but I currently have no idea where it is. The link in the Leadwerks Wiki is broken!

One could equally argue you get none of the advantages of C++ either, but I don't want to rain on your parade. We each choose a path and live with the consequences

The first part already is. The exporter for Leadwerks levels into their Sandbox (Configurator Tool) is complete and available from the Leadwerks Asset Store here: leadwerks-2-eki-one-exporter. I have to correct Dennis on his assumption. This is not a plugin as such but rather a tool to import your Leadwerks levels along with a minimal integration example of their AI engine running in Leadwerks. I am currently working on the minimal integration example which will see a deployed EKI One AI solution running in a Leadwerks level. The code and demo level will be freely available once I have made it available to the Masa Group (the current owners of EKI One) and have agreement to release it. You can find on-going progress information here: EKI One Thread It's taken some time due to the limited free time I have to devote to the project and the fact that Artificial Technology got bought out in the middle of the project. However, it is nearing completion. Hope this helps.

Lua was introduced really as an object scripting language and support for it is embedded in the Leadwerk API code, so it works regardless of what language you are using to write your game. Some people are taking it further and writing their entire game in Lua. I personally wouldn't do that, but if the game is simple enough and doesn't involve a lot of heavy computation then it's quite practical to do so.

CameraPick() is indeed raycasting

lol ... it's true that not every one can see them, but then again it takes a little while the first time to discover how to SEE them. It really is like you have to look right through the immediate 2D pic as if you were focusing on a distant object well behind the image then after a while the mind just adjusts and brings the 3D detail out.

I love magic eye pics, that one's very clear. But I don't think it would ever be a viable technique for moving 3D animation as it always takes a while for the eyes to adjust and decode the depth information plus the 3D objects and background are always composed of the same texture.

I don't know if this was the final version but here it is anyhow: Gandi\'s Decal.rar

So many good things have been lost on this site. I think I may have a copy of this though. I will have a look and post it if I do.

Most people would use a simplified physics representation like a ramp for stairs, otherwise you need to control the vertical movement in code. I do this in my stranded game to ensure a nice vertical progression when climbing stairs and not the sudden unnatural jump you get otherwise. The controllers do vertical displacement as a result of the physics instantly, that's probably what you are seeing when they are on the edge of a step.

I believe bevels do help with the leaks at the edges, I used to get this with models designed in 3DWS. I guess it depends on how its been constructed.

I assumed there was a point light in there too, that is one huge leak otherwise !!!

Probably an issue with the geometry resulting in leaking light. You could either fix up the geometry (someone else can probably advise you better on how to do that but I think bevelled edges on the walls and ceilings generally help) or if there are no windows you could simply turn the directional light off whilst in the building (only applicable when redering in your game engine of course).

Just an observation: People are trying to help you, maybe you should show a little more gratitude when people answer rather than simply replying with new questions. They are not employed by anyone to do this, they do it in their own free time and most of them have had to find the very answers you are looking for the hard way, because there was no one with the answers at that time.

I find it is fascinating getting insights into other people's experiences and working practices so I'll illustrate mine. Ours is maybe not a typical software development house in as much that we have a team of 8 developers which have been together for over 15 years and a couple of mature products; so be it they are constantly evolving. In my company 'Product Specialists' produce change requests and requirement (functional) specifications which are passed to the development team to implement. There is a review stage that allows for interaction between the development manager\developers and the Product Specialists in order to where ever possible ensure that the proposed requirements are unambiguous and achievable but effectively all additional design and modification of existing products is driven by these. The Quality department will have already written the test specifications for the proposed additions/modifications based on the requirements spec by the time the programmer gets to start the job and any code is produced. Depending on the complexity of the task the programmer may be asked to produce a design spec with time scales at this stage for submission which is then reviewed by the development manager and possibly other programmers before being rubber stamped. It is each individual programmer's responsibility at that point to then code the software and test it to a sufficient level to ensure conformance to the design/functional specification which is left in our organisation to the discretion of the individual programmer. Once the programmer has completed the task it's released to the QA department for testing to their specifications before being either passed or failed. Maybe we are a lot more formalised than many software houses but I am used to a high level of professionalism in the programmer's ability to not only design but test their own code to an acceptable level. Sure we have bugs, we have over 1.2 million lines of code in our main product and it's almost inevitable, but it's managed to an acceptable level. I just find that a lot of these 'methodologies' are cloaked in an air of mysticism and actually just boil down to good common sense application of functional testing in the strictest sense of ... if you design anything, test it to a sufficient level to reasonably satisfy yourself that it's fit for purpose and this involves the definition of functionality at many different levels and the testing of that. This is especially true of component software designed to be reusable where it certainly pays to test that thoroughly at the point you create it so it can be reused with confidence. Whilst this is not strictly formalised in our company, but it is something that our programmers do as a matter of course. Having your software repeatedly failed by the QA department is incentive enough for increasing your level of testing whilst having your customers report failures and bugs reflects upon your organisations ability to control the definition and compliance of software and acts as feedback for corrective and preventative action to try to prevent this in the future. There are no perfect systems or simply 'follow this and all will be well' solutions as, per most things in life, reality is a little more complicated than that. But could we benefit from reviewing our own and looking at other systems ... I'm sure we could. It's been an interesting topic and its certainly something I'll consider looking at in more detail.

Whilst I accept that testing at a function/object level represents in many ways the ideal it's very costly in time and in a competitive world a balance often needs to be struck. I guess it all boils down to how complex the functionality of the software is and hence your ability to fully test it. As its gets more complex it requires testing at increasingly lower levels to ensure correct operational behaviour. But even testing at each function or object level is still effectively testing to a functional specification because how else do you test anything? You can argue that if a piece of software passes the tests against its high level functional specification then it's fit for purpose as it meets its design criteria. Granted an internal function may have a bug that a lack of function level testing failed to identify but if that bug does not effect the overall functional operation of the software then that is generally not of operational concern. I'm not arguing against the fact that methodologies like this might well catch and identify potential software bugs at an earlier stage, they undoubtedly would but you are also paying a high cost of testing most of your good code. It does smack of overkill especially if the functionality is fairly straight forward. I guess I'm saying you apply the level of testing that is required by the complexity of the software being produced unless cost is of little concern. If it’s not easy to test all functional outcomes at a modular level then it’s probably better to test at this level. If it's mission critical software then it would go without saying.

So be honest Rick I think most developers inherently follow this methodology in as much that it is rare for any reasonably accomplished programmer to develop code without a good idea of the functional requirements they are trying to achieve and to not test these at appropriate steps along the development to check their code is conforming to the functional specification. In most cases once the developer has finished with the code module a Quality Assurance team would take over and independently check the conformance of the software too. Sure it may not be as rigid and formalized but it's essentially the same thing.

wise words NA

Ken is right, that's essentially how I've handled the weapon acquisition side. In my case I place ammo clips and guns (actual models) in the editor scene which have properties associated with them (but it could just as easily be a pivot as a generic place holder). When the scene is loaded these items effectively sit there until my player comes across them where upon as a result of ray casting the items are identified and then, and only then, does anything happen in terms of instantiation of objects. No need to create object instances that may never be used ... by creating them during loading! The player may never find them or may already have that gun or a full set of ammo. The models are simply hidden at this point then subsequently destroyed and if it's ammo then ammo counts against the player updated or if a weapon then an instance of that weapon created and associated with the player. All the associated data for the weapons and ammo will already have been loaded as part of the initialisation of the game. In this way my game engine can acquire anything, as the player comes across them, as the objects identify themselves and my engine knows how to handle each type of object. The game engine actually has no idea what is in the level or where.

So drop Lua for something like this and do it in C++. Game development is hard enough as it is, you really need to work from your strengths. Put some time aside, if you can, to develop your Lua skills and you'll have more flexibility in the future.

I would agree with most things that have already been said regarding this. I would however recommend just jumping in with both feet and designing as you go. You are going to change this many times as you progress and unless you have experience of this previously then designing up front is often not the best way as you will be unaware of many factors. Learning this way will teach you loads and is more likely to get you to where you want to be than having someone hand you code for their system. Once you have arrived with a system that meets your requirements you can refine your code, but yes, keep it object oriented as that will make your life so much easier. Some key aspects for consideration are: An easily configurable way of loading weapon data including the associated animation data A way of identifying which weapon types can be used by whom What the current selected weapon is, what state it is currently in, what animation is currently required, what sound file needs to be playing and the associated logic for controlling all of this An associated damage system which is dependant on the weapon and type of ammo Maintaining real time counts of ammo, clips etc A weapons acquisition system (picking up weapons or ammo you can use in your level)

Lua will run C functions easily but not C++ as it doesn't know anything about the this pointer in order to reference the class objects. There are some libs out there that will wrap C++ for use with Lua so that's always an option but if your prepared to just provide a C interface between the two then that works pretty seamlessly. Lua is written in C after all. As Aggror stated previously, having a good IDE at your disposal makes all the difference in any sizable development. The tools available for C++/C# are just so much better.

Fair comment, looking forward to seeing it.

I had some problems in Chrome too. Sometimes the images didn't load at all and other times when you have them magnified the zoomed window doesn't always come back when you click next, instead you get some tiny white distorted graphic in the middle of the screen! Other times it worked fine! Looking nice but why still no in-game video or are you waiting for the soundtrack to be completed?

The site lost about 6 months of data last year after a problem with a restore. You should email Josh 'support at leadwerks dot com' and explain that you have lost your registration key. I can assure you Leadwerks is alive and well