Sorry your browser is not supported!

Whilst trying to make a mega "wave" competition entry, I have the segmented level ready, and have been "tweaking" the AI on a stripped down level.

Now things work perfectly (Well not perfectly, but exactly as I expected), on the stripped down level.

So I move over to the real game level, set exactly the same settings, the entities are the same distance from the player, the segment they travel through are the same etc

Yet they do not act the same way. By this I dont mean that they seem to be following a differnt part of their AI script, I mean that if I spawn them they do not act like the ones previously spawned. (That probably made no sence so an example)

I create an entity, which will spawn, follow a node path, then die. It does this perfectly on the test level. Ill move over, and insert it in exactly the same way into the real level and sometimes it jumps in the air, sometimes it just stands there, and sometimes it waits until the next spawn and walks along with a copy of itself. Thinking it was the surface, I went so far as to change them to standard "Ground", but no joy.
(To sepcify a bit further, its normaly the 10~12 spawn thats the problem, then every third spawn after that)
(To Specify again, NONE of the spawns in the stripped level have any problems, and ALL the entity settings are the same, including height above ground)

Any Ideas.

ps. These are the Only entites so far in either level, so I dont think its an entity max problem or anything like that.

Edit: The ONLY difference other than the map itself, is that in the stripped down level the entities spawn on level 5, and on the real map on level 3, but you not going to tell me that the entities only act as expected on level 5)

Sometimes if you have two entities close together with the same main AI script one or both can act funny.Try giving the enemies a variety of scripts and see if that helps.

FredP,

Is correct - and additionally as I have found and said here previously with regard to numerous entity behaviours :

In complex levels or levels where entities, Paths and Characters have close proximity or cross over one another even at differeing level (tile) heights - then one enity can seriously impact on its neighbours.

For example if a character follows a path which may pass directly over a character that is stationary or indeed walking on the level below then the one above or below or both may come to a standstill when the cross over point occurs.

Similarly other entities such as trigger zones, switches checkpoints and so on can be activated by player or sometimes other characters if they exist on one level and another character walks above their position in a room above or below.

This is nothing to do with the individual set ups but is due to poor handling of multiple entities in side the engine caused by various influences which are too complex to discuss here.

The result is that in test levels things may work perfectly but in real game level sceanrio when the engine is under pressure things can go haywire.

This is frustrating as one may have to do much work in redsigning you levels and perhaps scripts to overcome the problems and it can take a considerable amount of time and effort in continuous testing in real game levels. Test compile times alone in testing to fix these problems can be very considerable.

Moving path layouts - characters positions and proximities as well as changing activation distances and more in scripts may be necessary in complex layouts or game scenarios.

Its not an end user issue as such but the engines inability or inefficiencies in handling many complex interactions of game AI entities all at once.

Entities AI think time and other influences do not seem to work in a box in isolation but is shared and confusion sets in as the engine think time and the math is dished out. There may also be some other issues or possibly bugs which further complicate these issues.

Something like that anyway - Lee would know I guess - I just know that I myself have had serious problems with complex AI interactions in regards to characters in particular and have overcome them with the methods above - but it requires a big investment in time and effort.

You may have to change ideas about how you would like to set up your interactions within a level, placement of characters and what they do and when etc.

Optimisation of levels as described by various methods around the forum to reduce the strain on the engine at any one time will also help considerably.

All in all a lot of work but currently if you want a lot of complex character/entity scenarios going on at any one time theres no other way.

Hopefully any update will provide some improvement to the situation.

Oh.

Thats a bit of a pain, because as you said the compile time alone makes testing of small changes proibitive on the main level.

As an additional question, I've been following this build order doctrine

1) Segments
2) Entities (Dynamic Characters)
3) Entities (Dynamic Secerey)
4) Entities Static
5) Zones
6) Lights

I was doing this for speed of build/development. This was a good doctrine when I worked under the assumption that the Dynamic Entities were not affected in any way by the subsequent additions

I would stil want the lights to be placed last, because otherwise... well you know. But are you saying I should have all the static segments/entities and zones done before I add dynamic enties?

1) Segments
2) Entities Static
3) Zones
4) Entities (Dynamic Secerey)
5) Entities (Dynamic Characters)
6) Lights

(I did read, in teh Faq I think, about a build order doctrine, but I had just assumed this was for methodology, and not that the specific order was obligatary)

One final question, (Before I go and read teh FAQ again), can I assume that an entity will act the same when Im not looking at it?

[Reason: I wanted to have a timer, and have made this a "If the creature gets to point X before you, then the world ends" (or what ever). So I have a waypoint path marked out and the entity does nothing but follow it. (At times during your "dash" you get to overlook the entity and see its progress). When looking at the entity is seems to follow the path correctly, but from what has just been said, I now doubt it will]

This does need to be fixed

If a user is as fussy as I am about everything in a level being, behaving and looking exactly how I want it to be then I dont see any option currently than to perhaps in a very large and conmplex level to have to test run it many hundreds or perhaps even thousands of times before one can is happy with the outcome.

Unfortuanately theres no other way currently other than test run and physically walking around a large level - sure you can move the player position to an area currently being worked upon - but as with any engine you then cant see whats happening elewhere unless you walk everywhere to check out whats going on. You have to accept the long compile times all those tests add to game making with FPSC.

You can do a part test of world objects only if you choose the second test button in the edtior menu just to test out the world construction if that helps.

Currently we have no real time feedback, compile or 3D world camera flythrough or anything of that nature so full test runs are the only way to see all is as it should be.

Users need be careful if they wish to skip full testing and just get on building large worlds or levels and not testing them fully and regularly. As if any errors occur and you have not seen them and save your level you could get caught out. I always make my changes or additions and test fully before saving my levels - so have to test often then save. With this in mind regular backups before editor sessions are to be recommended so you can go back to a previous version of the level if need be. If you invest months of work in a level you dont want to lose it.

A long time ago now I suggested to TGC improvements or changes to the way the whole testing and compile procedures work so that accumalative real time compiles could be put into affect. That means in short that only any currrent changes would have to be updated in levels at test run or full game compile. I doubt that will ever happen but I have no influence upon that.

If you want to see what entities do when away from the player then you need move to or follow them or try viewing whats going on in wireframe mode in Test run.

Max entities limit is currently just less than 200 - 200 by default. This Limit is apparently to be removed but dont expext to hold TGC to that.

**************************

As to preferences for order of game level buiding - well each to their own - having experience of FPSC I use my own.

This is in reference to anyone wishing to build large complex worlds.

1. Have level design plan. Game design plan

2. Build levels starting at any level you choose.

3. Always start building in centre of world and work towards the extremities - this is very important. You need a grid type layout plan for this so you know your level will fit to world size. Keep important content away from world edge. At least try and keep the complexity of content balanced throughout a level. i.e. spread the load and burden on the engine at any one time.

4. Do extensive tests for any possible level or entity scenarios that may pose problems or present you with difficulty in getting them to work, behaviors and so on - in empty tests levels to perfect them. You can do this as you go (build main levels) if you wish and not necessarily all first of course.

5. Build world objects (walls)

6. Finish one part at a time completely including any and all entities to a basic level completeion so that you encounter as many possible problems early on. You can do this while testing out any probs or anything you want to do but dont know how as above. At the same time as you go add a little more of the next part of your level. This you should do so you can watch how the level design and content affects fps and gameplay speeds and stop if necessary before you go to far. Entities either static or dynamic can be switched to one or the other at any time so I would not worry too much about that - general rules about quantities of either apply. If you have too many of one or the other then you will need to ascertain that in real time - (and this is partly guesswork or detectivework) and use well documented methods to overcome any limitations. Trial and error in this in individual levels is the only way.

7. If necessary stop to redesign your level and use all of the optimisation methods available and detailed at this forum to keep the fps accaeptable. When it is move on and keep building - this way you get to know FPSC limitations and overcome them as you go. If you reach a max out and cant maintain fps then you have your level more or less complete to a certain stage and could start a new level to continue if necessary. Obviously you would need an appropriate level change built in.

8. Keep this going - build, optimise if necessary until each single level is by and large complete and problems are overcome and fps is maintained.

9. Try and keep the fps at your required max for gameplay and when your level is overall in a stage of completion - see if you can optimise a little more and squeeze in some improvements or aditions by going back over the level and making last final improvements wherever you can. Improve anything you can to provide maximum quality and gameplay experience.

10. Repeat for all levels.

11. Compile your Game.

When I get there I will let you know. Easy to say not so easy to do.

Now someone not I should place this info somewhere it may be of continual help to other users - that if its helpful at all. Unfortunately its a little more invloved and complicated than it sounds here but together with other information available here at the forum it may help some users.

I do not think that is in "teh faq"... mabey it is.

But order DOES matter. You want all the static objects in first. If you are using dynamic lights you want that BEFORE you put in the enemys. If they are static then it doesn't matter. Finally, before enemys, dynamic objects.

Reason being is that enemys are just supplements to the level. What matters most is not the enemys in the level, but how the level it self runs.

You can allways move enemys around but if you have the enemys in perfect places yet after dynamic objects or static objects are added you may have to rebuild the whole level.


Finally, each section should be saved separatly. The simple segments, the statics, the dynamics, the lights, and the enemys. Any touch ups (minor decals, sounds, triggerzones, scripts) can be done last due to their lack of influence in the game.


Also, scripts can be changed after the game is compiled, so if you need to touch something up you can. (and technically you might be able to add enemys after compile...)

I realy dont want you to be right about the lights needing to be done before the entites.
The majority of my builds are with everything turned off/down.
Epecialy the lights.

What you are implying by saying do the lights before the entities, is that haveing "No Lights" selected as your test build option will make the entites act differently than when they are under a blue light (for example)

Now maybe you are right. But if so, its the stupidest stupid thing that has every been stupidly programmed.

My assumtion about the lights cannot be true? Can it?

Having just paused before posting.
I have realised that Im being stupid here, Your saying put the lights in early, but I can still build with "No lights". And that will not effect the dynamic enities. Right?

I would like to explain the problem again.
The Test level is exactly the same as the build level except that the build level has some walls, and the test level doesnt. Not walls "in the way", just some walls. And the enties start to act stupid

Can someone reasure me about the lights not needing to be turned on for builds?



It might not be. But its somewhere, and teh FAQ seem a good guess

I design the level first (segments,etc.),then the lighting,entities and enemies last.When I have done my lighting last it hasn't worked well.

It has nothing to do with how entitys are affect via scripts. (and for technicallitys, entitys can detect dynamic lighting with PLRCANBESEEN) but how well they manage in game.

It is known that a large amount of dynamic enemys can cause serious lag. Dynamic lighting does not help the situation. Now, if you build a game with dynamic lighting LAST that means you will have to change MORE to get what you want.


The process is not getting your enemys to work propperly, but your level. Minimizing lag and keeping a backup copy of previous changes.



And I think I know this post.... I posted it in the bug reports under "read me". It explained this procedure as a way to keep a backup incase of file curroption. It also explained how to post a bug report including what few do "INCLUDE your level file with your report"