Pixel Perfect

I agree. How nice would it be to be able to run a cut scene at the end of a level and have the next level load in the background. i.e. make LoadScene run in a background thread. I've no idea how complicated this would be given the current scene, or at least part of it, would still be resident but if there was a possible mechanism for doing this and simply swapping between the scenes it would represent the ideal from my point of view.

Ah sorry ... I understand now. Do the model's underlying polys get occluded as a result of being hidden by the outer clothing? I'm guessing probably not as to occlude it the whole model's bounding box would need to be occluded by the bounding box of the clothing which is not going to happen as the head would always be visible. I guess it depends on the culling routine and how it's implemented. Not being a modeller myself I'm not entirely sure how add on clothing works though. In an animated model does that not also have to have its vertices attached to the skeleton and weighted like the rest of the model, in which case would it not be seen as part of the same model anyhow. Would the modeller not just remove the underlying (hidden) polys manually in this situation? Excuse my ignorance in this field if I'm missing the obvious.

In terms of the poly count, assuming modern hardware, I'd say aim at the following: Main Characters: 15,000 - 20,000 max Others: 5,000 - 10,000 max Obviously if you can get the poly count lower then all the better. Also, if you are intending using large numbers of NPCs or running on lower hardware specs then these would need to be reduced accordingly. But the engine does handle large poly counts well. Home motion capture is definitely becoming feasible now although how easy it is to get good results in practice I don't know; never having tried it. I'd love to play around with that stuff though, looks great fun

Looking great Dan. The hair looks very good. Looking forward to seeing the final model complete with its normal map detail. Will you be animating it yourself too?

Many thanks Richard, they look great! Expect to see these in Kingdom Of Soul in the near future

Cheers Dan. Might go a little quiet now as I have a lot of programming to do before I can move on but then the project hopefully should get a lot more interesting

To answer your first question the term SOFTWARE PRODUCT is defined at the top of the EULA as follows: Secondly, the EULA as such and it's restrictions on the type of 3D game or application that is created is specifically designed to prevent licenced users producing games or applications that can then be modified by end users to effectively produce new games or applications that could be resold. This is simply to protect loss of licence revenue by Leadwerks by people who would encapsulate the engines functionality under the guise of a configurable game or application. This has been discussed many times before and if you have a specific implementation in mind then please submit detailed descriptions to Josh (Leadwerks) for concideration.

However you look at it the problem is a simple one, as the engine is not inherently thread safe you cannot have two threads access the same shared memory without locking it in some way. This is expensive in its own right but for something like model loading (which is intrinsically a lengthy process) it might be worth while. Whether this can be done without altering the existing source code I'm not sure.

Cheers Richard. That's a 1024 x 1024 terrain. I'm really just honing my skills in all things 'level design' so come the final design I have a good idea of how to implement what I can see in my head ... and hopefully a good feel for what works and what doesn't.

Thanks guys. As a break from programming today I started some experiments with terrian design using the earlier Sandbox terrian tools so I could get some erosion features. I must admit I like the tools. After a little playing around to get the feel of them I was able to produce reasonable results fairly quickly. It's a shame we lost the fractal and erosional stuff in later versions although it's easy enough to port the heightmap of course. The first screen shot shows an ariel view of the terrain topography and the second a would be 'in game' shot:

I had every belief that this community would arrive at a sensible solution and it sounds like this point has been reached. Mono is indeed a great choice. Good luck Brent.

@Laslo. Don't be deterred by people attempting to derail the good work you have done. If you feel you don't want to compromise then keep your version as a community only supported version. It's not ideal but offers people choice. I do agree that an official supported version would be a good thing as it brings a sense of stability which can make all the difference when new people are making the decision to buy or not. Many developers have previous bad experiences of using community versions that subsequently lapse or disappear altogether. I also agree with Rick in as much as real world situations often demand some compromise from the ideal and as you appear to be one of the leading authorities here on C# could you not find a way to work with Josh on this?

Cheers Richard. Unfortunately the level design has been put on hold whilst I radically re-design my NPC/AI system. Most of the work I have done so far has been with a single NPC type (the soldier from STRANDED) so I could concentrate on developing an AI system; which is working really well. Although it was designed to work with multiple NPC types from the beginning, hence I was able to implement the female character in Kingdom Of Soul, it's not proved flexible enough for my liking. So with the beauty of hindsight I'm now re-coding a better system which will make mixing and matching lots of different NPC Types each with their own AI far easier. This is needed for Kingdom Of Soul far more than was the case with STRANDED as the diversity of character types is likely to be far greater, but of course STRANDED will inherit the same capability as both games are using my same engine. The engine is now designed to support both FPS and RPG/Adventure type games which will run stand alone or in my editor. The work is already partially implemented and I'm hoping to start seriously testing it within the next week. I'm hoping shortly after that to introduce many more characters with their own behaviour traits so that the game really starts to feel like its going somewhere and has a life of its own.

It's a really draconian system but yes ... all vegetation models must be prefixed with 'vegetation_' and all terrain textures prefixed with 'terrain_'

Sounds interesting (if you excuse the pun) So is it going to contain sampled musical phrases which can be mixed and matched to form songs or is it more sophistocated? Looking forward to seeing (hearing) more on this.

As I have had Lumooja's posts on ignore for some time now I'm enjoying a new game of guess what Lumooja said from the resulting comments of others .... I think I probably need to get a life I completely agree with this. LE2 is a very capable engine, the only practical limitation I find is the restriction of 5 terrain texture layers which really limits it's ability to reproduce realistic outdoor scenes.

Early experimental results with a river: For various reasons this is not a very practical technique and I'd rather use a shader based solution like the one Josh provided for Michael in the GDC Demo he did. Does anyone know if the details of that were ever released?

I think the answer is in your own question Dan. Create some code that counts the number of visible NPCs and if over a certain number then dynamically determin and set the LOD distance such that you get the spread you are looking for. Not sure how effective that will look though if you are seeing LOD changes up close!

There are certainly plenty of midi libraries available in C/C++ including wrappers for the Microsoft MIDI API. A quick google of 'midi lib lua' revealed a few indications of libraries too! You might want to investigate these to see if anything is suitable.

Thanks Mike, I think you hit on my key goal there ... believable! That's really all I'm looking for and quite happy to settle for that; as this is not a focal point of the game but simply an aspect of the environment the player will pass through. This weekend will see me implementing the updates I've planned to my NPC/AI framework to better accomodate multiple NPC types with their individual AI requirements so I can really get things moving in this game regarding NPC behaviour. Inheritance is a wonderful thing Also, further lessons/adventures in level design ... time permitting!

Thanks. It's just experimental at the moment Richard. I've been trying out different techniques. This uses an animated quad and is looking the best so far but the animation is only running at 15fps currently. I'd need to take it up to at least 30fps really to make it look really smooth. As I have no real background in level design (or game design for that matter) I'm trying out a myriad of tests in small areas of the terrain so I can go through the learning curve and discover what works and what doesn't before committing to the full level design.

I think I probably agree with every word of that Rick. I have gone over the top on both the graphics and the game mechanics I needed to deploy within such a limited development time scale. I do consider it to have been a worthwhile lesson though and out of the ashes I hope a phoenix will arise. Respect to you and the other finishing contestants of the first contest though because, as I've subsequently discovered, it's not an easy goal to achieve and you guys managed that admirably!

Many thanks Aggror and Ywa for your comments. I can't really argue with you there Rick. With hindsight I definitely set my sights far too high and it proved impossible to complete in a month. The first three weeks were spent programming developing the object selection functionality and inventory system along with an overall 2D graphics manager to support it all and a few other bits of code. I guess my major downfall was in thinking the assets I had planned for conversion (models, textures etc) could be completed in a day leaving me five days left to complete the remaining game play code. It actually took 4 days and left me with insufficient time to complete the deadline at which point I duly admitted defeat and posted in this thread to that effect. Disappointing, but ultimately uplifting as I yet again have learnt so much from this and now feel I have a worthy game project to continue work on. My current move to doing more level design / graphics based work has been mainly by means of contrast. When you program all day long as a profession and then program for three weeks in your spare time on top of that you reach a point where to be honest, you need a break. Well at least at my age I do, and my family will only put up with so much time with me absent and sat behind a computer It all has to be tackled sooner or later in order to complete the vision so moving onto more graphics based work was better than just stopping work altogether for a while. I'm now in no hurry to complete this and instead want to give it the care and attention I feel it deserves still with the intension of releasing it as a playable demo once it’s complete. I have improvements to my current NPC/AI framework mapped out on paper which have yet to be implemented in code and still need to design and code the dialog system. Then there are the overall game play scripts too. Still a lot to do! I have removed the reference to the MAGIAM in the title now as that hardly seems fair being four days past the deadline now.

Thanks Lazlo. I have to agree, Flexman had also made some pertinent comments on the difficulties of waterfall design and they are incredibly hard to perfect. I really don't want to get side lined for a long period of time on this as it's simply a small bit of eye candy for the game so may well settle for less in the end. Thanks Dozz. The Tina and picnic comment really made me laugh out loud

The first of my waterfalls: