Pixel Perfect

Thanks Dan, that's appreciated, but this is my way of giving something back to the community by giving people a chance to use a quality AI design tool with Leadwerks Engine 2. This is a great community and I felt it was the least I could do. My reward will be to see it breathe life into Leadwerks games in the not too distant future

File Name: EKI One Exporter File Submitter: Pixel Perfect File Submitted: 04 Dec 2011 File Updated: 14 Jan 2012 File Category: Tools Leadwerks Engine 2 To EKI One Exporter Tool Exports a Leadwerks Engine 2 level to a EKI One (Version 2.7) project enabling the level to be loaded by the EKI One Configurator. See the Leadwerks Engine 2 To EKI One Exporter Tool.mht file in the zip container for instructions. Both executable and source code provided. Licence: The code is provided free of charge to licenced Leadwerks users for use with Leadwerks Engine 2 and is unsupported. You are free to modify the code in any way and distribute those changes so long as the changes are clearly documented. In this way people can tailor the Tool to suit there own requirements. Credits: I would like to thank the following: Franck Gwosdz, Serein Pfeiffer and Valentin Seegert from Artificial Technology Gmbh for providing help and advice on the EKI One product integration. Paul Frischknecht (aka Masterxilo) http://www.hurricane-eye.webs.com for contributing his gmf to obj file conversion routines. The version present here is a modified version so it didn't require some of Paul's additional library support. It also does not handle the full material conversion as that functionality is not required here. Dejan (aka paramecij) for contributing the routine to flip the terrain raw file. Hans Dietrich for providing his public domain XBrowseForFolder code. Jurgen Timm (aka flachdrache) for helping with the initial testing of the exporter and providing some test levels. Click here to download this file

My vote is 'leave as is'

Sure, if there is to be a common communications interface used by all components then someone would need to design that up front, that almost goes without saying as you are requiring everyone else to use that, but then the rest boils down to functional specs again for the remaining components. If you want say a path finding system writing, or a foot placement system with IK, or a blended animation manager please don't tell me you'd be designing all that up front and telling me how to code it because that would probably result in any decent programmer walking at that point as you have effectively de-skilled the job and demotivated your staff by turning them into a team of monkeys who just churn out code. Sure you can operate in that way, but that's your own choice. It's not because it has to be that way. Maybe lots of software houses do operate in this way and I've just been lucky in not working for any of them yet, I don't know.

Just loading it for me

In my working experience of team based software development programmers are given functional specifications to work from and actually do all of the design themselves, often starting with a detailed design document which may be subject to review. I admit that where an actual game engine is being designed which is a fairly performance critical component there might well have to be much tighter control on the overall design, but again you would expect to employ people who have experience in this field and any desired techniques to be implemented discussed in advance of any design work. When it comes to people using Leadwerks to design their games I wouldn't have thought the design was that critical in many areas for someone to have to do all the design up front simply to delegate it out to programmers to code, unless the quality of the programmers employed was very poor!

That might be more representative of the type of situation you would really face but there would normally be a non rendering cost associated with running game logic/AI too (unless it was a very simple game) which is better simulated by loops. A combination of both might be better. But you could try increasing polygon rendering initially, that should start to bring the frame rate down fairly quickly from an initial high value.

As Macklebee suggests, you might get lucky but you might be better just asking for the strafe animation from Dexsoft (worth a try) or using an animation package (I use Fragsoft) and adding the strafe animation yourself. Strafe would be one of the easier ones to do. This is where it pays to use a modeler that uses a standard skeleton for its characters as you can then mix and match the animations.

I don't know how accurate the AppSpeed() function is but certainly the sleep function is not that accurate and is dependent on the tick resolution of the system its being run on. It tend to be less accurate on low values (< 10ms) and even when it completes, the thread is not guaranteed to restart immediately. You might want to do a comparison using a high resolution timer that simply loops rather than sleeps the thread.

I agree, sounds tasty .... I'll have second helpings

I get the same too

This argument ends in one place and one place only ... no future gaming if you take the big players out ... was really refering to removing all of the big companies including the hardware producers as the argument seemed to be edging towards big is bad. I totally agree that we could lose the big software houses overnight and smaller companies could supply games to the market place. But then capitalism being what it is will simply start the process of growth and acquisition all over again and we'll be back to where we started. I don't disagree with you Josh over the efficiency gains of remaining smaller but modern life demands a lot of companies need to operate on a scale well above this and its inevitable that they will no longer be as adaptable or possibly innovative as the smaller ones, but they do deliver things the smaller companies are just incapable of delivering and as such are often needed. I don't personally see the big game companies disappearing any time soon because, as Afke pointed out, they know there is a constant stream of new purchasers coming on line and lots of people crave big block buster type games as well as movies. But it's certainly never been a better time for small Indie developers to sell their games too.

Well I don't think the millions of people buying MW3 are doing so out of an obligation to make Activisions shareholders rich, they are doing so because they genuinely enjoy the games, regardless of whether we feel they are getting real value for money! I'd also like to point out that there is no escape from the multi-billion dollar companies of this world where gaming is concerned .... as the hardware they all run on are produced by them. We don't get little Indie hardware companies producing affordable tablets and mobile phones for worldwide consumption do we, or even better 'Open Source' hardware Shall we damn them and their shareholders too! This argument ends in one place and one place only ... not future gaming if you take the big players out. Sure we Indie game producers have a rightful place in all this and can cater for a market that wants more creative output rather than just playing it safe and churning out the same content over and over again but lets not lose sight of reality altogether! Hollywood has been doing the same for countless decades. You don't need to like it but to say there is something wrong with that is elitist ****, it simply caters for a market that exists. That's what capitalism does!

There are good examples and bad examples at both ends of the spectrum and to make out that small is good and big is bad is not really very scientific or to be honest very astute. Minecraft may sell like hot cakes but fails to keep my interest much beyond half an hours game play whilst Skyrim (which has also sold like hotcakes) has had me hooked for the last two weeks continuously. If that's an example of game companies targeting five year old technology and not pushing the technology forwards then fine, because it delivers on the sort of game play I enjoy. Maybe pushing technology forwards is not all it appears to be .. as to use your own example most Casual games are hardly pushing the technology forwards, they are simply running on the latest technology!

Great work zaphos and a very nice demonstration!

The simple fact is large teams are required for large endeavors. You are not going to make a modern AAA title with two people so big teams are required if that sort of product is being created. I agree with Josh in as much as any large production team will inevitably have a few key people at the top with the big picture who have the vision and direct things. Certainly, large team work does require different working practices and procedures as Rick has already hinted at. However, if its handled well there is no reason why individuals within a big team can't contribute to the creative process and inject their own input. It's really down to how the key people choose to manage the projects. What I'm really saying is large team production work requires a completely different kind of professionalism and discipline from small Indie projects. It is what it is, I don't really think it makes any sense to compare one with the other as they are such different endeavors. I personally find working in small teams more rewarding as the level of involvement in the overall project and communication is far greater, however, the scope of the projects are always going to be correspondingly smaller. So it is good to get experience of working in larger projects but you very much need to be a team player and not everyone is cut out for that. Some people have a nature where they need to control everything or have communication problems and are unable to work effectively with others. But as a general 'look at what I've done so you can do it too' prep talk I agree with Josh. If this forum is representative of a lot of others I'd guess that probably less than 10% of the total membership of this forum have ever worked in the software industry so have any first hand experience of this.

I think there is a lot of truth in what you say Josh. So long as Indie developers keep their goals realistic then there is no reason why they can't succeed with small teams and budgets.

I find most programmers who are good with one language can move between languages pretty easily. Take your time, review the language and the rest should come easily. I don't use LUA at all currently, I code everything in C++ but I don't think I'd find the transition to LUA much of a challenge.

Well that's a great opportunity for you to find a solution and make a name for yourself

Worth taking a look at this thread: Progress Bar

You can display a load screen but its not going to be dynamic as there are no inbuilt hooks within the LoadScene command to supply loading feedback plus, being single threaded, this command must execute first before control is handed back to any other Leadwerks code that might be updating the load screen. There is nothing to stop you launching seperate threads or applications to display say a video cut scene but the problem is still synchronising those, maybe through the use of some shared memory and critical section type devices you might get something workable. As I say, I'm sure others have looked at this in some depth, I seem to recollect Metatron having some threaded solution to aspects of this but I don't remember if it was a full and viable solution.

Leadwerks 2 does not inherently support multi-threaded execution so you can't simply load the level data in the background whilst executing LE code in the foreground. However, I know others have looked at this in the past and come up with a few suggestions. You might want to search the forum for previous threads on this or hopefully someone who may have implemented a solution might see this and provide some more direct input.

If I can, ask away!

that explains it. Yeah treat it just like an NPC then, it just happens to be controlled by a player

You simply need to load a character model and move it to match your controller position and rotation in each iteration of the game loop. You will probably want to tie in suitable animation control for your character too so it animates as it moves. Take a look at the various tutorials dealing with loading characters and controlling animation. However, if you do this you will probably need a model that supports weapon attachments and has existing animation support for the weapon rather than using a stand alone weapon and simulated arms which is not expected to have a full model for the player. Not sure why you are wanting this if you are not planning on having third person camera support? If it's just for a third person view of the players death then you could just substitute in a model with a death animation at that point.