Jump to content

  • Log In with Google      Sign In   
  • Create Account


VladR

Member Since 04 Dec 2001
Offline Last Active Jan 16 2014 07:47 PM

#5061146 A* advices

Posted by VladR on 11 May 2013 - 02:50 PM


1) Perform only several steps with each update while taking other enemies into account

This solution looks nice, however I cannot figure out how would I be able to detect if there is no path, since A* (at least the form I know) detects it from having an empty list of open nodes at the start of new loop.

You seem to be missing the point. You won't actually detect the full path (or even if it is possible to get there) until you actually went though all open/closed blocks. How many frames will it take - that depends on the number of blocks you check each frame vs number of all blocks. if you check 5 blocks each frame (for each unit) and you need to check 100 blocks to come up with full path, then it takes 100/5 = 20 frames to come up with full path - and that is OK.

 

All, that you really want to do, is just to give the player an illusion of instant pathfinding (even if it takes up to a second to come up with full path).

If your initial estimate was wrong, well that's OK. You never played an RTS where you give few units a command and they suddenly change their direction after a second ?

 

This is why it takes so long in those RTS games to finish the initial rotation towards the correct direction. While they are rotating, they're giving the player an illusion that they know where to go, even though, for a fact, they still don't.




#5061129 DX11 - Swap Chain - Slow Engine

Posted by VladR on 11 May 2013 - 01:25 PM

1. You are most obviously fillrate-bound. Post the FPS in lower resolutions (e.g. 640x480).

 

2. You took a shorter / simpler route and created an uber-shader. That's great during debugging/development, but as you noticed, it has a negative impact.

 

3. It is very easy to check the impact of conditions. Just create a separate technique/shader pair that will have only single codepath (say - just bloom), without any conditions whatsoever.

 

4. Make sure VSync is off.  With 52 , it doesn't look like VSync is On, but better safe than sorry...

 

Of course, as always, there will be 10 other things that impact FPS (many of them on the CPU side - AI, pathfinding, ...) , but let's first address those that have biggest impact.




#5060586 Vertex declaration and app crash

Posted by VladR on 09 May 2013 - 08:54 AM

This is one of those nice things that XNA runtime checks for you and you don't have to spend hours trying to find where you made the typo. It even gives you a beautiful exception with exact spot in either your declaration (or an actual VB) is messed up.

 

You were actually lucky to get a crash. But, that's exactly what the C++/DirectX combo brings to the table...




#5060583 XNA terrain painting

Posted by VladR on 09 May 2013 - 08:46 AM

You could do the Picking on the quads and just adjust the vertices of the quads.

Have a preview window/RT with the tesselated output on left side and the rough mesh with the quads on right side.

 

Other option would be to just pre-tesselate the mesh and use that for picking and rendering.

 

In the end, it's up to you, how much control you want to have over the physical mesh vs the post-tesselated look.

 

 

You have to decide, where on the sliding scale, you want to be.




#5059789 Alternatives to singletons for data manager?

Posted by VladR on 06 May 2013 - 12:30 PM

Few practical personal observations:
 

1. End user of your game does not give a damn about how your engine classes are structured. Really.

 

2. If you are the only coder on the project, do not over-engineer for the sake of some higher principle / book / pattern / <insert random bullsh*t reason>. Refactor, so that you, as a coder, have to spend minimum (preferably zero) time on that class you wrote 18 months ago.

 

3. Prefer "Ugly" code [that works] to a "Beautiful" code that hides/obfuscates dependencies [and suddenly stops working].




#5058384 What programming language should i go with? (C++,C# or java?)

Posted by VladR on 01 May 2013 - 01:20 PM

For game coding purposes, at this day and age,  do not even think about going the C++ route and go for C# right away.

 

 

The productivity gains I got when I switched to C# from C++ are enormous. In fact, they should be illegal, if anything.

 

And I'm writing it as a competent C++ 3D coder who gets paid because he is versatile in C++ and 3D.

I did my first few games and 3D engines in C++. It was a lot of pain. When I made the switch to C#/XNA 3 yrs ago at home, I could not believe how productive it is, either.

 

I am working on a new game at home and I spent about 3 hrs on adding a new gameplay feature in last 2 evenings. I can guarantee you could not, repeat, could not, write it:  1. so soon, and 2. so short , and 3. so stable in C++ in such a short timeframe. In C#, it's just boom.boom.boom and the sh*t just works right out of the box. You don't have to understand the compiler complexity 7 layers deep - as in C++  and certainly do not have to make compromises in design just due to the "greater good" as is often the case in C++. Yes, I know that C++11 made a lot of things better, but it's not and will not be a C#.  It's close - but for me it came two years too late.

The fact that you don't compile the code (as in C++) every single time means tremendous time savings. Your brain does not switch out of the context, as in C++ and by the time it si compiled you long forgot what the hell were you trying to accomplish in the first place.

 

Your brain IS THE CONTEXT 100% of the time. It is a different paradigm.

 

 

Your free time is very limited. It's not some huge company that has money to throw around. Spend it wisely - i.e. writing code that works right the first time and not on debugging...

 

The argument that C# is slow for 3d games is nonsene. My engine runs on cell phones, tablets, 10-year old XBOX and certainly a 10-yr old PC.

Those few C# performance quirks, on those particular platforms, are easy to fix.

 

Besides, it's not like it is impossible to write a slow code in C++ either ...




#5058361 Light on Terrain

Posted by VladR on 01 May 2013 - 12:12 PM

Another problem is that the shader files are much easier to change than binary files, while in the fixed function, it's much harder to change the binary, so that could be a problem since others can easily modify the scene if I'm relaying on shader files by simply changing the shader files.

Well, it looks like you missed the train by, about, ....counting...., a decade.

 

These days, since you haven't noticed, you don't wow the crowd with some shaders, internet is full of, anyway.

 

 

You wow them with a content adhering to a unique art style and that is very expensive to produce.

 

 

In short, worrying that someone could "steal" your shaders is least of your worries. If anything, that would be flattering...




#5058166 why stuck when drawing a lot of triangles

Posted by VladR on 30 April 2013 - 02:39 PM

for example, drawing 100 * 100 triangles

 

when using D3DCREATE_SOFTWARE_VERTEXPROCESSING, the program is stuck and its cpu usage is high

 

when using D3DCREATE_HARDWARE_VERTEXPROCESSING, the program is ok and its cpu usage is alomost 0

And this is exactly the behaviour you should be experiencing, since You are explicitly forcing DX runtime use CPU to do the transformations instead of GPU.

 

so what can i do to make the program ok when using D3DCREATE_SOFTWARE_VERTEXPROCESSING

Easy. Buy a Faster CPU.


#5058161 Drawing on different graphiccards

Posted by VladR on 30 April 2013 - 02:29 PM

the question i actually wanted to ask: how would i start to debug this issue?

This is an order of magnitude easier task under  DirectX - since when you run the game in Visual Studio you can see the Debug output being printed into the Output Pane where you will see lots of info why the rendering is broken. Even in XNA, you would get an exception, if your indices were broken, or there was a mismatch about some obscure, low-level stuff.

 

You chose OpenGL, so you just have to suck it up now and check each call manually if there is some error smile.png

 

Of course, since we are talking about ATI, it is expected that they will not return the error code at all times - you wouldn't expect ATI drivers to be as good as nVidia drivers now, would you smile.png

 

I've seen this behaviour on multiple ATI cards under multiple sets of official drivers. Basically, the renderer worked flawlesly on everything, Intel GMA950 not excluding, just the ATI cards were unpredictable. (and that was taking into account all info there was on their issues).

 

 

If I were you, I would just display a message along the lines of "Warning ! ATI card detected. Please insert a reliable gfx card." smile.png

 

As you probably guessed, ATI cards gave me a hell, some time ago...

 

 

BTW, if I had to guess, I'd check if that card of yours supports 32-bit Indices first (Yes, you'd be surprised. No, just because the gfx caps tell you it is supposed to support 32bit Indices , it does not , necessarily, have to. You are welcome smile.png ).

 

Do you have an access to the machine ? Can you step through the code, line by line, and see where it crashes ? Most probably, some resource (VB, IB, texture, RT, ...) didn't get created for whatever reason - majority of them, of course, unjustifiable - based on gfx Caps the drivers expose...




#5058134 XNA 4.0 , AI Library

Posted by VladR on 30 April 2013 - 12:45 PM

I forgot to mention one thing.

 

It is immensely helpful, if you can bring up (upon some keypress) an overlay with debug info on current enemy, especially the current state and other important variables.

 

Once you start testing whether the code behaves, you don't want to browse through logs figuring out and guessing what hapenned when.

 

You wanna see it right there when it happens, that exact frame, when enemy switched from Idle into Attack (or other) state.

 

It will be helpful when you expect him to switch to other state, yet you can see right away that his state didn't change - this helps during debugging the state machine a lot.




#5057796 XNA 4.0 , AI Library

Posted by VladR on 29 April 2013 - 10:48 AM

yeah I know what you mean and I have all the status {Attak , Run , Idel ........ } , but for example can you provide me some code on how can enemy follow me or chase me ?? ( if you know SharpSteer can you give example ) if you don'e know sharp steer , can you give some code for attacking or chasing ??

Well, if you want some up&running, I'd start with the Attack State - e.g. approach the enemy who is in Idle state and let him switch to Attack state automatically when is close enough to attack you and reduce your health.

 

For the Searching/Chasing State - well this is the realm of Pathfinding and there are quite a lot of different ways how you can tackle it. It all depends on your internal representation of the walkable area in your level - do you use artist-made navigation meshes ? Or perhaps your level structure can be represented as lots of quads - in this case you can look into the A* algorithm.

 

Do a search on pathfinding and figure out what would work best for your game.




#5057630 How much time would this take?

Posted by VladR on 28 April 2013 - 09:36 PM

Guys, just because Square Enix is insanely maniacal about the quality and detail doesn't mean a similar game can't be reproduced on 1/10th of their budget with ~30% lesser quality.

 

It's been proven many times that indies can produce a very similar game under less than 1% of the original budget. Budget doesn't really mean anything other than an investor having a money to burn/launder/invest.

 

 

We are talking about pre-Z-Brush era - e.g. low-poly characters with ~few thousands polygons.

 

- Drop the FMVs.

- Drop the 237 different enemies - instead let him find 3-4 artists that will produce 3-4 enemies each in their free time (totalling about 12-16 different meshes). Just like majority of other RPGs do - the variability comes from procedural changes to colors/scale factors, and in-game parameters/characteristics. Drop the unique animations for each enemy - instead use the same few animations (still/walk/run/attack1/attack2/dead) on all enemies

- Instead of rendering towns and handling a different control scheme, just change the camera to top-down and still keep the same outdoor engine component

- Grab some pre-made art asset sets from internet. For couple hundred dollars you can get a lot of different environments without having to spend months/years creating the art assets yourself.

- Use as much procedural level design (e.g. through code, not human effort in an editor) as possible

- Audio - enormous amounts of audio assets can be found for free (or few bucks) on internet

 

How much work it is really depends on the engine used. If he goes for Unity (and doesn't spend 2 years creating some engine from scratch), he just needs to script the gameplay, AI and interface.

 


I am totally confident, he can come up with the basic gameplay and few hrs of gameplay within first 6 months of the work in his free time, assuming using something like Unity and getting characters done by some external artists. And, of course, assuming he has some prior experience with creating complex games on his own from start to end...

Sure it will be a pretty different game, yet still pretty similar - it is the gameplay that matters (not hours of shiny FMVs, seven thousand pages of text on "story" that almost nobody reads, and three hundred enemies with unique animations/textures/effects)...




#5057590 Microsoft burned down my home, where now?

Posted by VladR on 28 April 2013 - 05:41 PM

No, XNA is not dead. I suspect it will get at least 3-4 more years of life, at least.

 

I, for one, am viewing the lack of updates to the API as a Good Thing (no more broken code for dubious new "features").

 

3 yrs ago, I switched from C++/DirectX into C# / XNA. Yes, I still have the C++/DX engine/game codebase. But I'm not returning back to it.

 

 

I am sticking to XNA, since thanks to MonoGame I have an access to all platforms i could possibly have my games on. Yes, iOs and Android require some investment (Xamarin), but without Mac you can't really test your app anyway (i.e. using remote desktop - virtual macs), so it's not that big of a deal.

 

 

 

It remains to be seen how much of an indie support will the new XBOX get. Let's wait for that first, before burrying XNA...




#5057586 XNA 4.0 , AI Library

Posted by VladR on 28 April 2013 - 05:33 PM

Look into creating your own Finite State Machine.

 

Basically, each enemy has a bunch of possible states (enum EStatus { Standing, Walking, Attacking, Dead, Searching } and you query his state each frame and based on the state apply the logic - e.g. if he is Dead - don't do anything. If he is Standing, you want to check if the distance between him and player is within certain threshold, at which you will switch his state to Seaching (e.g. approaching player until he is within shooting distance - e.g. Attacking state).

 

Just make sure you have all states planned out on the paper beforehand (and especially the transitions between states).




#5056377 Tacking performance degradation

Posted by VladR on 24 April 2013 - 09:22 AM

You might also want to put in debug switches into your game so you can enable/disable certain components while the game is running. This will let you see live how they affect performance.

This.

 

8 yrs ago I spent about 10 minutes putting few boolean flags into my engine (bRenderTerrain, bRenderEnvironment, bRenderCharacters, bProcessAI, bProcessInput, ...) and those have been the best spent 10 minutes on the engine. Ever.

 

Because to this day, if performance is suddenly taking a hit, in the middle of testing, it takes me 10 seconds to turn on/off certain/all components and figure out which one is the one. No debugging, no breakpoints, no profiling (unless absolutely needed). I worked on multiple games in that timeframe and on multiple platforms, but this Turn On/Off feature is especially useful on non-PC platforms.

 

So, put few if (bComponentOn) lines into the code, connect the KeyHandlers and enjoy !






PARTNERS