Jump to content

Pixel Perfect

Members
  • Posts

    2,110
  • Joined

  • Last visited

Posts posted by Pixel Perfect

  1. As in theory all nav mesh nodes are walkable I think the next phase having returned the list of nodes you need to walk through is to produce curved path through them so it looks natural (its referred to as string pulling I think). Again, I've not worked directly with nav meshes so I'm trying my best to remember what Chris had described when talking about his implementation. My system of navAreas is more akin to the old 2D grid system so I have fixed sized nodes.

     

    I suspect it doesn't help to allow your nodes to extend beyond a certain maximum size or as you say you will be needing to pathfind through the nodes themselves :D

  2. As far as I'm aware Rick A* is still used to find your way through the nodes. The navmesh polys represent individual nodes and A* iterates through the list of linked nodes. Chris will probably give you a much fuller explanation.

     

    In terms of do they need to touch, I'd say probably not so long as your logic links them where its deemed appropriate ... such as the steps on a flight of stairs for instance. If an area of nav mesh is totally isolated from the main section, such as on top of the roof of a container, then that may be also quite valid as although there is no way to link to it as your NPCs couldn't jump that high, they still might fall of a building and land on it.

     

    A* in theory should work with any number of dimensions, the traditional 2D square grid is just a special case.

  3. The only advantage I see is the fact that realistic ballistics come into play, so you can have parabolic movement as gravity pulls the bullet down over distance, realistic transmission of momentum into hit objects and also true rickochet (which would be quite tricky to simulate without using a real object and the physics engine). Personally ... I'm just using raycasts.

  4. ..in my game where some quite complex scenery arise at some points(30+ characters doing some stuff simultaneously, dialogues, lipsync, AI, etc)..i figured out that speed difference between Bmax and C++ practically 'doesnt' exist (it does exist but its so so so minor that FPS is absolutely unnoticable)..and it was not worth to sacrifice, clean look and simplicity of code in bmax for exchange with less than 0.2 msec speed difference i have gained with C++ .. so, in my book, I highly recommend Bmax..

    I'd agree, there is no reason why a game couldn't be written using BlitzMax, in fact it's a good choice for people new to programming (which in no means undermines BM as it's a very capable language). The differences between C++, BlitzMax and C# are much closer. But your statement fascinates me, are you saying that you have your entire engine written in both languages and are able to run benchmark tests between them? How much processing time is taken up by your code on average per game cycle, min and max values would be a good insight if you have these figures? Do you use multithreading or any other processes devised to average out peak processing demands over multiple game cycles? You are far closer than most of us to having a completed game and some feedback on this would be really useful.

  5. To put it simply .... the more your game has to do in code, the more difficult you will find it to fit that in between each frame render in order to maintain a decent frame rate. This is where the raw speed and performance of a language comes into play; before you get to that point you will see no difference. Most people have relatively little or no code executing between frame renders at the moment so they see little or no difference between any of the languages. This is simply because they have not really started to tackle what is really needed in a game engine to make a game.

     

    If you intend making a very simple game then you will get away with using LUA (which at times may execute 50 times slower than C++ for example) but if you intend making a modern day contender for a FPS, RPG etc then basing your engine design totally on LUA would be impractical. Well written routines in C++ will execute the fastest of all the languages mentioned with BlitzMax and C# falling in between and LUA trailing well behind at the end.

     

    Lua can be combined with other languages successfully and used with serious engine designs but in this case it is normally relegated to a scripting language carrying out high level logic with all the clever and tricky stuff being done underneath in faster code, as Josh was highlighting above.

     

    It's all a question of choosing what is right for your game but also listening to those with experience, because unless you have been there before these things are not always obvious at the beginning but will hit you hard later on if you get it wrong.

  6. The actual rendering side (the graphics) will run pretty much at the same speed using any of the languages, it really depends on what you are looking at doing between rendering frames. If you are planning lots of complicated AI for instance you probably would benefit from the raw speed of C++, otherwise any are a valid choice imho. You can of course mix and match either C++ or BlitzMax with LUA. Just don't do anything that's very intensive in LUA. There is also C# too, but I have no experience of using that, but I'm sure its an equally valid option too.

  7. Yeah, working fine on my nVidea (spec as below). The water and sky effects are both really very good. The HDR seems a bit fierce and I'm getting occasional issues with what might be clipping planes but the water is top notch. I particularly like the foam on the water ... that looks completely natural. The only water I have seen that betters this uses FFT for all those cascaded wave frequencies that make it look totally realistic. Very impressive!

  8. Wow. It would be cheaper to just learn how to animate.

    Believe me Rick it wouldn't. To model and animate to a AAA standard, which I assume Michael is referring to, is beyond the capabilities of most of us. I have had quite a bit of experience recently and I have come to the conclusion that whilst the fundamentals are easily understood to move from that into producing work approaching that quality is a pipe dream for most of us. It's a bit like coding AI, you can get 90% of the way quite easily but the devil is in that last 10%.

     

    I would prefer to work with an animator/ modeller as part of a team but have faced the possibility that I might have to shell out a sizable amount of money in the end to pay someone to do it for me. After all, if someone was to ask us for a sizable chunk of game code, which might take us several months to write, how much would we charge?

     

    yes, or use my motion capture system, lol

    Very impressive ... did you train the squirrel too ;)

  9. I agree whole heartedly. It was not meant as a criticism of DexSoft, as I do think their assets are very good value for money which is probably why I have bought so many, but as a general statement of fact. Having done some rigging and animation myself I am accutely aware of how time consuming this is and the skills required.

     

    I currently am using placeholder art and animated models (a lot sourced from DexSoft and other similar companies) in order to complete and test my code and produce a working demo and then, if there is any interest, I will be prepared to either team up with good animators or commission work from freelancers as you suggest. I'd welcome the contact details of anyone you could recommend Michael if you'd like to PM me.

  10. This is basically a re-worked version of their SWAT model (still waiting for my replacement for that by the way DexSoft ;)). If the SWAT model is anything to go by it's quite nice but lacks a lot of the basic animations you would need in a game. This seems to be a general problem with most Indie based model suppliers, a lack of a comprehensive set of good animations. They tend to supply the bare minimum!

×
×
  • Create New...