Jump to content

Pixel Perfect

Members
  • Posts

    2,110
  • Joined

  • Last visited

Everything posted by Pixel Perfect

  1. Pixel Perfect

    Launch Day

    Congrats Don't forget the LE2 bug fixes though
  2. Welcome words Tyler, nice to see you back!
  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.
  4. Exactly, that's my question too. As much as I'd like some of the pipeline and editor benefits we are realistically saying to get to the same graphics level as LE2 on Windows will take two chargeable upgrades and a minimum of 9 -15 months wait?
  5. Reassuring words Josh, I believe that should calm the community somewhat.
  6. 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!
  7. 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?
  8. 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.
  9. 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!
  10. Ha ... well fair comment 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
  11. 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.
  12. and you would know this how? You really might give people the benefit of the doubt before you play Judge and Jury
  13. 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.
  14. 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.
  15. 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?
  16. Yeah, its always interesting to see peoples approaches and discuss these things. 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.
  17. 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.
  18. Well yes, but I assume your object knows how to do what it needs to do, so once the AI directs it to do so it does so. If the state is 'Chop Wood' then that inevitably leads to the playing of the Chop Wood animation, sound effect etc and anything else that is associated with that until such times as the state changes. How you choose to package that up is up to you I guess. The FSM for instance facilitates this by allowing you to code actions within the state with transitions in and out of it. It's not just about making 'AI' decision as to which state it is in as about ensuring it does whatever you need it to do within the state. If your game objects are designed well that could be as easy as a series of calls to other objects.
  19. Well I guess traditionally those types of things tend to be handled by Finite State Machines or Behaviour Trees simply because they have been designed to do exactly this and make it easier to handle the logic. Not that is necessarily easy even with these tools, it depends on the complexity you are building! But yeah, its good to explore different ideas and systems. There is little substitute for real experience, its a great teacher!
  20. That also is good advice! The game player is generally completely oblivious to what code is running underneath it. As long as it works it's achieved it's purpose. Sure its nice to have elegant code etc and it certainly pays to make it as maintainable as possible but there is a real danger of getting too 'hung up' on the technicalities and over complicating systems for the sake of it.
  21. The projectiles used in my spell casting system are instances of a projectile class, everything from the creation to the destruction of the visible projectile and associated effects is controlled by the class: http://youtu.be/yA60NJ4PeUc
  22. Beware: 3DWS supports a few more standard texture formats. If you use the proprietary one you will not be able to use them in any game engine as its totally unsupported outside of 3DWS!
  23. Neither happy nor offended. I was just trying to ascertain whether you were talking from experience or not Good to know we are all in the same boat
×
×
  • Create New...