Jump to content

Pixel Perfect

Members
  • Posts

    2,110
  • Joined

  • Last visited

Posts posted by Pixel Perfect

  1. Out of interest Josh, how does your current nav mesh implementation handle large areas like a 4096x4096 mesh and have you given much thought to how you'll implement path finding with streaming terrains?

  2. Although I'm currently not working on any game development I thought I'd just post a recent video that features the fantasic level design of Falk Lochmann. We were exploring the idea of a STALKER type game idea and Falk provided the level you see in the video. All I did was add some of my path finding and patrol capability to emulate a patrol scenario with a couple of NPCs for this video. The footage is taken directly from my Game Editor. I will be using the level for enhancing and testing my FPS AI as soon as I'm able to find some time in the future.

     

    Falk is a very talented artist and I hope to work with him in the future again

     

    • Upvote 1
  3. I just think its important that people know exactly what they are getting into right from the start so they can make the initial purchase without any misconceptions

     

    This requires as a bare minimum:

     

    • Revised initial purchase costs
    • A definite roadmap of development with time scales
    • A reasonable indication of the expected cost of each of these upgrades

     

    There is no immediate requirement but it should be made available before asking people to purchase the engine. If you are asking people to make a not insubstantial investment both financially and time wise then this is essential so people can plan their finances and development.

     

    The release of a trial/demo version for people to try is a good initial move and I welcome that.

    • Upvote 2
  4. Ok, lets try and look at this objectively. Lets forget the iOS and Android versions for the moment and simply consider the pros and cons of a move from LE2 to LE3 Windows and MAC version as this represents the core functionality of all three modules.

     

    Advantages as I see them (although currently untried and untested):

     

    • A better art pipeline (much more streamlined), in fact what was asked for in LE2 time and time again!
    • The ability to scale objects (and their physics counterparts) in editor, a big plus in my opinion
    • In built CSG capability, probably good for amateurs and programmers but not that necessary for professionals who will have access to good modellers anyway. Also owners of 3DWS already have the ability to design and import.
    • NavMesh generation and path finding, a very useful addition but will not always provide a good solution for all game cases
    • A better underlying game engine code structure, I trust Josh on this one as his past record speaks volumes. The LE2 API is very nice. This is pretty essential if planning to expand the functionality effectively.
    • Integrated Lua support and effective debugging tools is a good move as I see it.
    • A basic game framework with built in support for flow graph control of scripted objects - ok not that interesting for me personally as I think there are limitations with this approach but great for the more artistic types who just want to plug in pre-built scripted objects and wire them up.
    • Support for the industry standard C++ language (native code). I see that as a plus, many will see it as a curse however.

     

    Disadvantages as I see them:

     

    • Currently a vastly more primitive renderer compared to LE2 or any other engines at the asking price, so no deferred rendering and no shader support
    • No support for real time shadowing
    • No support for terrain at all let alone streaming terrain
    • No support for a vegetation system
    • No inherent GUI support
    • No built in networking support
    • Limited physics support as I understand it (no joints for instance)
    • Reliance on flow graph building of scripted objects leaves you dependent on the provision and quality of such objects if you are unable to write them yourself which can seriously limit your game design options
    • No inherent plugin support to enable communities and third parties to add and embed functionality into the editor
    • Virtually no additional game development toolsets
    • A price which is comparable with a fully fledged engine with most of the above features
    • No given time scales as to when further functionality will be introduced (as yet)
    • No given promises that this will not incur additional cost (as yet)

     

    Now its up to individuals to determine whether the asking price represents value for money and whether this initial investment will pay off in the end. It seems to require something of a leap of faith to get from what we are actually being offered to what we should be getting for our money when you look at what that money can buy you else where.

     

    My personal experience of LE2 has taught me to be wary of Josh as he has often ignored the wishes and advice of large areas of this community seemingly often listening to those who simply shout the loudest! As Flexman pointed out in an earlier post many of us have contributed greatly to his success via this community and if nothing else acted as unpaid testers for his original engine. I feel having paid for an engine that it deserved to be supported far better than it has been. In the last year bug fixes have been taking up to 6 months on average which is unacceptable. Likewise the original road map and design criteria for LE3 has deviated greatly over time, the previous bombshell being the dropping of a modern renderer for the initial release which caused a lot of protest.

     

    I'm not sure I want to pay up front for something that I'm not sure will ever happen and even if it does where i have no guarantee of the timescales. Will this be supported any better or simply fall victim again to the next project that takes Josh's attention.

     

    I'd like to think he'll eventually deliver on everything and believe it could be a great engine again but I view this as a complete marketing fiasco and it doesn't instil in me much faith.

     

    Only time will tell I guess.

    • Upvote 8
  5. As I've stated all along, I'll not be making anything with LE3 until I see a stable fully functional product ... which I suspect is still a long way off! Only at that point will I make any decision and of course not without comparing it to whatever else is around at the time.

     

    The cost is not of primary concern, I've always been willing to pay for something that I concider worthwhile. LE2 was a good investment in that respect, good because it was cheap enough to put up with the two years or so it took to get the product stable. With hindsight I will not go down that road again though ... very frustrating for a developer.

     

    I obviously have my doubts about the current pricing strategy but in the end I hope Josh is successful otherwise there will be no Leadwerks and any chance of a bug free LE2 will go out of the window too!

    • Upvote 1
  6. I already have a local copy of the the entire Wiki site and may well do the same for the documentation URL to ensure I'm not dependent on it's continued availablity.

     

    What's the situation with the LE2 Assets? Will they continue to be available or should I be doing a last asset grab to ensure I have anything I need should I return to development work in the future?

  7. Also, define your classes in seperate files with associated headers and simply include the headers in files in which you wish to reference the objects, usually their header file. Makes the main code much more readable and modularises the code nicely.

     

    If you need to share variables between classes then pass them as parameters or create a singleton which contains these and allows global access.

  8. Cor blimey!!

     

    How you doing Franck. Yeah we have had some fun moments here. Thanks for the comments and yes, I'll be back in the forums from time to time. Good luck to you too. I'm sure we'll catch up again in the not too distant future :)

  9. Thank you everyone for the lovely comments, it makes the leaving all the harder but is greatly appreciated none the less. You are like an extended family to me and will remain so, nothing will take that away!

     

    Hopefully I can return to development again at some time in the future, till then I'll drop in from time to time to catch up on all the news and peoples projects.

  10. I just thought I’d make a statement to clarify my recent status announcement as, like Ken previously, I have received a lot of requests wanting to know why.

     

    The main reason, and it’s important to clarify this, is for personal reasons. As my children grow older they are placing an increasing demand upon both myself and my partner and rightly so. As a result of this I am finding my time for development being progressively reduced to the point where it’s becoming difficult to continue in any meaningful way. The game development work to be honest has always been a hobby, as I had no designs on making a career out of it, but an extremely interesting and enjoyable one none the less. Another contributing factor has been the fact that I’m a much more accomplished musician than programmer and my playing and composition work has also had to be put on the back burner for the last three years or so whilst I pursued my interest in game engines and game design and it’s something that I miss greatly.

     

    Combined with this the change in direction for LE3 has also been a contributing factor as it’s clearly catering for a different marketplace to LE2. It has consumed the bulk of Josh’s energy to the point where LE2 has suffered and has never quite reached the point of being free of bugs that are not critical, in one way or another, to finishing a game engine design. It still appears that every bug fixed somehow introduces new issues; but is perhaps understandable as it’s clearly no longer the primary focus of his attention. In addition recent comments from Josh, and in particular his comments regarding how to implement AI, have served to illustrate to me how divergent our visions are and how focused on simplistic game design he has become. Not that there is anything wrong with that I’m sure it will result in a greater number of games appearing, but again I can see where the bulk of the future support and development will be concentrated and how anyone wanting to develop a grander vision may struggle to get the support they need.

     

    I have to say that the Leadwerks community really is a great community and I have really enjoyed my time here. LE2 has also been a great vehicle for allowing me to explore game engine design and develop my skills to the stage I have. I leave with a far greater understanding than I came with. I have made some good friends here and have thoroughly enjoyed the experience.

     

    Times and engines change and people move on and others take their place. I wish Josh, Chris and LE3 success and I’m sure a new generation of game designers will flood into the forums and some of that vibrancy, that has been lacking lately, returns. I may well continue work but at a much reduced level (if indeed it’s possible to be any slower than I have been of late) but regardless of that will still visit the forums to catch up with the you all and see how things are progressing.

     

    Best wishes to all of you and I hope to be playing some of your games in the not to distant future :)

     

    ps ... I’ll get back to all of you who PM’d me asap, its my son’s birthday this weekend so even more busy than usual!

     

    [EDIT] Just noticed I posted this in the showcase ... opps! Meant to be in the Off Topic! Feel free to move it

  11. OK, thanks for the feedback Quast. If you have any further question then just ask. In the meantime have a play around with the demo version and see how you get on. There are the tutorials too and a good guide to the engine. There is a lot to learn about game development. I've been playing with game design for 3 years now (in my spare time) and I'm still learning. Have fun and I hope you decide to join our community and become a licensed Leadwerks user :)

     

    Yes, LE2 is quite capable of making PS1 quality games. With a full team of programmers and artists it would be possible to make a quality AAA game but that's unlikely to ever happen. LE3 is soon to be released and offers a different approach and cross platform capability. Although its not fully featured yet we are told that will follow.

     

    Your games/puzzles look interesting, I'll take a longer look at those!

  12. I still think C++ is terrible, it's just the best thing we've got. tongue.png

    Ha ... well fair comment biggrin.png But please don't make your next project a new language that's going to revolutionize the gaming world, because, as we know .... Mika has already done it tongue.png

  13. I read the description here of behavior trees. I really do not see why anyone would use this, because you're going to have to buckle down and write the code in the terminal nodes eventually anyways

    That's fine, that's pretty much what I've been advocating in this thread. Do whatever you feel comfortable with and leave other things to other people if they feel comfortable with those.

     

    Not everything is obvious at first glance, you had little time for C++ a few years back Josh and now its one of your biggest selling points! Our perception of things change sometimes when we actually start using them, sometimes they don't and it just re-enforces our initial suspicions.

  14. I agree Rick, there is no right or wrong and I wasn't meaning to imply mine was any more right than yours. As I said originally, if it works then it's fit for purpose, the game player really doesn't care.

     

    I think you are right when you describe higher level actions, when you break them down, being really many lower level actions all done in the 1 state. This does lead to complexity and a bigger class but with complexity comes complexity, it's kind of hard to avoid that.

     

    Here by means of illustration is an example from my previous FSM system (as I'm using the EKI One Hierarchical FSM system now). This is the moveToCover state which would be triggered by a perceived enemy in whatever state it was currently in. It checks that it is closer to the cover point than the enemy before switching to the moveToCover state, if no cover points are closer it will simply lie down and engage the enemy from its current position. This previous version of my NPC class had functions embedded in it for supporting general AI or for calling the AI manager when requiring support from other systems:

     

    void moveToCover::Enter(npc* pNPC)
    {
       pNPC->setCurrentFSMState("moveToCover");
    
       // Stop path finding
       pNPC->stopCurrentActivity();
    
       // Get the nearest cover point and move to it
       pNPC->moveToPosition(pNPC->getNearestCoverPointPosition(), 0.9, RifleRun, 160, 1);
    }
    
    void moveToCover::Execute(npc* pNPC)
    { 
       int randomTime;
       TVec3 rot1;
       TVec3 rot2;
    
       // Has the NPC reached the cover point
       if(pNPC->isAtPosition(pNPC->getNearestCoverPointPosition(),0.8))
       {
           // Set the atCoverPosition flag
           pNPC->setIsAtCoverPoint(true);
    
           pNPC->rotateToVector(pNPC->getNearestCoverPointRotation());
    
           // If its a partial cover point
           if(!pNPC->getCoverPointIsFull())
           {
               // Set the NPC to crouch
               pNPC->addAnimationToQueue(RifleCrouch, 0.0, yes, no, 0);
           }
    
           // If NPC Status Type is set to Attack
           if(pNPC->getCurrentAlertState() == alert)
           {
               // If the cover point is of type full
               if(pNPC->getCoverPointIsFull())
               {
                   // Wait for a random period of time and then trigger moveToCoverFirePointPos state
                   // Store the state to be triggered after wait
                   pNPC->setNextState("moveToCoverFirePointPos");
    
                   // Create a random time between 1000 and 3000 mS
                   randomTime = 2000 + rand()%3000;
    
                   // Store the wait time
                   pNPC->setWaitTime(randomTime);
    
                   // Change state
                   pNPC->GetFSM()->ChangeState(waitThenTriggerState::Instance());
               }
               // The cover point is partial
               else
               {
                   // Wait for a random period of time then trigger standAndFire state
    
                   // Store the state to be triggered after wait
                   pNPC->setNextState("standAndFire");
    
                   // Create a random time between 1000 and 3000 mS
                   randomTime = 2000 + rand()%3000;
    
                   // Store the wait time
                   pNPC->setWaitTime(randomTime);
    
                   // Change state
                   pNPC->GetFSM()->ChangeState(waitThenTriggerState::Instance());      
               }
           }
       }
    }
    
    void moveToCover::Exit(npc* pNPC)
    {
    
    }
    

     

    I find this pretty simple to keep track of but other people might not. As I say, we all find ways of doing things and systems that work for us. But it is interesting to hear about and discuss other peoples systems.

  15. They would be different class entirely since the functionality is different.

    Exactly, but this negates the whole idea of abstraction because now you are creating Actions which are tied to specific Actors. You effectively do the same if you start conditionally branching within the object in order to supply differing behavior. There is really no escaping this, which is why most game designers design behavior for actors. Sure there is some commonality that can be shared but its difficult if not impossible to keep it completely generic!

     

    The Action idea would work within a FSM system but its really not necessary because the State equates to an Action. Whatever you need to provide to the Action must inherently come from the State which rather than passing it to an object that subsequently makes the calls might as well make those very calls itself! There is nothing to stop you defining this additional layer if you so wish, there could be some advantages in some circumstances but it's all additional calling overhead for not that much gain. The States are classes which can simply be instantiated whenever you need them just in the same way as your Actions are!

     

    I'm a great believer though of implementing whatever works for us as individuals and whatever we feel comfortable with. Josh's suggestions are just as valid. I think systems like FSMs and Behavior Trees enable you to tie in the decision making to the action commands in a way that is more maintainable and easier to follow but every system has its advantages and disadvantages. Non hierarchical FSMs can lead to a lot of repeated logic, Behavior Trees I believe are better in this respect but I have never used them. But regardless of the system you use ... AI decision making and the actions resulting from those decisions are inextricably interconnected and are influenced by the subject they are acting on.

  16. Out of interest Rick, how would your action system handle say an 'Attack' action which may be implemented differently depending on the character it's being assigned. With your system being abstracted from the actors how do you handle this?

  17. Yeah, its always interesting to see peoples approaches and discuss these things.

     

    No, the objects (if meaning like actors, trees, weapons, etc) don't know how to do the tasks, they just know about the task classes. Classes for each task knows how to do the task on said object. The more actions you have the more your object code starts getting big and messy if the logic of doing said actions are directly in these object classes.

    Well with FSMs the states are classes in their own right and this is where the actions are defined. The NPC knows how to do things by virtue of the FMS states its assigned, its not hard coded in the NPC class!

     

    The end effect is the same, the AI determines what Action should take place and then some mechanism tales over and invokes whatever is required. In my case the NPC's FMS calls the animator to run the animation, the sound manager to run the sound, the path manager to move the NPC. In your case you construct some Action/Task object that essentially does the same by the sounds of it.

     

    Two different ways of looking at the same thing as far as I can see.

  18. I think you need to go back and read through this thread again if you are asking these questions! For one, LE2 has only been stable for the last two years or so and secondly it has a relatively small following compared to some of the bigger engines out there.

     

    Have you made a game before, in which case how long did it take you and what engine did you use? There is no game engine as such with Leadwerks Engine 2, it's a game engine API, so you first need to write your game engine.

     

    Either way, there are sufficient mini games to show what its capable of, I don't see why you would need them to be full games or even published to deduce the general flavour of what's possible and what's not with LE2.

×
×
  • Create New...