Pixel Perfect

That's correct, it should be an int. It is just used to check whether something was hit or not

3D objects of the supported file formats can be imported by moving the objects to a suitable directory under the models folder and adding their textures to a suitable folder under the materials folder of the 3DWS install directory. So if you had some trees you could create a tree directory in both areas and move your models and textures there. When you open 3DWS they will be available from the drop down boxes. You can texture any individual csg object in 3DWS and adjust the texturing if need be so you maybe need to think about how you want the final textures to be before constructing. You could import a flat plane already textured with a water texture or create a second terrain object and position and texture that, but otherwise no.

You can use the tag property and just set them in the material file. This is the mat file from the firepit object: texture0="abstract::heathaze.dds" texture1="tag::rendercolor" texture2="tag::renderdepth" depthmask=0 zsort=1 shader="abstract::particles.vert","abstract::particles_heathaze.frag"

Try the examples, they appear to use a depth buffer but I've never actually used it. Failing that you could alternatively use CameraPick. I use that in my Editor for placing items in the world based on the mouse position on the screen: gotSurface = CameraPick(&pickStruct, camera,Vec3(MouseX(),MouseY(), 1000),0,0,NULL); you can extract the position from the pickStruct. If nothing is returned you can assume it exceeds the raycast distance and assume a default far distance value.

Make a careful evaluation of the pros and cons of each and choose what's right for you, there is no better advice. It's pointless any of us saying 'Use Leadwerks' if it's not right for you. Good luck, I hope you chose wisely.

Take a look at the function CameraProject. This projects the specified screen coordinates into world coordinates. Once you have that the rest should be fairly straight forward.

I'd used an animated billboard for the main explosion effect when I developed my destructible objects which works reasonably well. The animated sequence I used was not very high quality but it proved the point. You could mix in some nice particle effects for extra effect: http://www.youtube.com/watch?v=-2DDSbw0_V8 I like Aggror's idea of using a heat haze shader to simulate a blast wave, I think that would look very effective!

http://www.youtube.com/watch?v=QevCQOKTi0U&feature=related

If you're the sort of person that wants complete control over your game engine and are prepared to work round the lack of tools then I'd definitely go with Leadwerks. It's going to take a lot of coding but it's beautifully constructed for programming, a joy to program with to be honest. The renderer, as NA has already mentioned, is kind of special too. Things just seem to look that little bit better when rendered with Leadwerks. If you are the type of person that wants an already existing game engine framework that you can simply work with and require lots of high level tools to aid the game design then LE2 is probably not for you and you might want to look at UDK or Unity. I have no experience of T3D so cannot comment on that.

That's a really nice solution Rick.

Attractors and deflectors would be useful

Great to have you on board Chris, look forward to news of the particle system development

Sorry, I have no tips on texturing, I'm sure someone with those skills will make suggestions soon. I just wanted to say the modelling looks excellent. Nice work, I hope you'll showcase them when the're completed.

I'll take a look at these too, thanks for the pointers Lord Hippo. It is something I've been vaguely aware of in the past but never looked at in detail.

That does seem an overstatement in my opinion. Sure there is a move towards data oriented design but I know of few engines that don't also use object oriented techniques too. A simple search on available jobs at DICE shows requirements for both object oriented design and data oriented design experience in many of the available jobs!

Wow, that's fascinating! The lengths some people will go to and the misused skills of some programmers! Good luck with the refund. That too is a very good point.

You need to ascertain where optimisation is important and where it really doesn't matter, that is key. You can waste a lot of time making something faster than has little to no effect on the overall performance. PROFILING is your friend. Profile all your code first and find where the real time is being taken. Then ask yourself for each of the areas where large amounts of time are being consumed, is this expected or do I have an optimisation issue here? This way you will concentrate your effort into the areas which can have an effect. Identifying these areas is half the battle. Optimising those routines sufficiently is the other. Good luck There is no need to define your functions before the entry level int main function. You can simply forward declare those functions with a single line per function. What's more, those can be defined in a header file. Good structure and the use of modular code be it Object Oriented or Procedural will help with the readability of the code and also with bug fixing as it promotes encapsulation of functionality but will not in itself increase the performance or efficiency of the code necessarily. Object oriented code lends itself well to most areas of game design and I would strongly recommend it. However, it is often less efficient and should be avoided in some key areas where performance really counts like anything that involves lengthy computations (path finding routines would be a good example where you need to squeeze every last micro second of performance out of your code and the last thing you want to be doing is incurring the overhead of creating thousands of new objects).

Well in my FSM any NPC in the idle state will automatically drop into the idle state processing code and perform the exact same checks that presumably your NPC idle state cycle checks, that is anything that might cause the NPC to come out of the Idle state. If non of these trigger a state change no further processing is done, where is the difference. Same with the FSM, once the idle state has been triggered to something else the FSM will process the new state and no further processing of the idle state will take place. There is no way of avoiding the state control for what ever state an NPC is in at any given point in time, all you can do is avoid calling additional code which is of no benefit at the time. FSMs do this quite elegantly if designed well. Maybe I am not understanding your explanation well enough to see what you are really citing as an advantage. Either way, debating aside, I hope Clackdor has enough food for thought to do some investigation into these areas of AI control.

I don't believe operationally there is any advantage in what your describing NA. Whatever checks are required to determine what triggers an NPC to come out of Idle state have to be done regardless of what system you are using, in mine it's in the FSM but there is little overhead associated with this, if no other state is triggered it simply returns.

I too use Finite State Machines for my NPC behaviour. I have a FSM defined for each NPC type and my NPC update routine simply calls the FSM update routine from its own update routine which is in turn called from an update event triggered from the game loop. The FSM contains all the behavior logic and responds to various input stimuli such as line of sight input, sound input, NPC state input etc and interfaces with my path finding functionality to determine NPC movement and switching between different NPC states which control the aspects of the behaviour etc. So the top of my NPC class update routine simply looks like this: void npc::update(float gameLoopTime) { // Update the controller position m_vecControllerPos = EntityPosition(this->m_NPCController,1); // Update the wait timer if activated if(m_bTimerActive) { updateTimer(); } // Update the State Machine if(bNavDataLoaded && !m_bDisableFSM) { m_pStateMachine->Update(); } // Handle weapon fire if(m_bFireWeapon || m_bWeaponIsFiring) { updateWeaponFire(gameLoopTime); } // If nothing to do then simple return if(!m_bHasUpdateWork) return; // If currently moving then update movement if(m_bIsMoving) { .... Some examples of the many states I use are: idle patrol moveToPosition moveToCover moveToCoverFirePointPos closeOnEnemy attackEnemy defendPosition hit waitThenTriggerState Behavior trees can also be used and offer certain advantages over FSMs but then have some disadvantages too.

It bothers me that there is seemingly no sign of any licence on the site regarding the models usage. Unless I have a clear statement of the right to use royalty free then I tend to assume I probably don't have the right and avoid as I would have no way of defending that in a court of law.

I suspect you'll need to be patient as we don't have many people developing with purebasic

That's probably because its actually a fairly complicated thing involving path finding (even if its just a simple system), line of sight and some sort of AI algorithm. There are plenty of tutorials on the individual components that go to make up such systems which people tend to research in order to put their own combinations of things together to suit their individual game requirements. Of course you can go for simpler static type systems where the enemy are pretty much based in set positions and simply attack the player as he comes upon them. If they are in open spaces simply emerging from behind cover then there isn't the need for complicated path finding systems, the enemy instead just heads straight for the player and engages, or if the player avoids conflict then give up fairly quickly and are respawned at their cover positions once the player has left the area.

Good to hear you are to continue it Aily, my son loved that game and we would definitely buy it

Successfully tested the first character tonight, it's talking away quite nicely. Will have to give some serious thought now to how I will proceed with this. The advantage to using a unified skeletal structure through out all my required character models is apparent but would mean pretty much abandoning all the models I have purchased so far. I need to start looking at what facial rigging systems are out there and get an idea of what the technology offers and the associated costs.