Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 10 Nov 2006
Offline Last Active Yesterday, 04:04 AM

#5315142 Stronger versions of enemies?

Posted by on 14 October 2016 - 05:32 AM

It depends on the context. Just scaling a npc is not really satisfying. You should add something which requires a new strategy to approach the enemies other then hitting the attack button more often.


E.g. an elite version of a npc should have some extra feature/skill the standard version does not have.


Taking your example, a standard goblin has almost no armor, whereas a champion is armored (choice of other attack spells) and an elite goblin is able to call reinforces.

#5313819 Critique of my Art

Posted by on 04 October 2016 - 01:20 AM

A good start, but you should reconsider the overall design. Currently the gun is taking up all attention, leaving your bot as simple weapon holder. Here are some rough guidelines:


1. As humans, we look at the face of other humans or animals for identification, we focus on it. The face of the robot is hard to read.

2. The attention of your model should shift from less interesting (legs) to most interesting (face). Use size, details and choice of color to create more or less interest.

3. The gun can be big, but if it hides most of the torso, it takes away all of the attention from the bot.

4. If you want to have a humanoid bot, you should consider humanoid proportions. Currently the long legs are good for the next miss-robot competition ;-), but for a more menacing look you should consider a more extreme upper body proportions (larger torso,broad shoulders, small waist).

5. The human brain works with relations. It decides that the human in front of it is a child/dwarf (big head on small shoulders) or a giant (small head on broad shoulders) by setting the point of focus (head/face) in relation to the body (shoulders).

#5310714 Spine: TopDown Characters?

Posted by on 14 September 2016 - 03:13 AM

I stumple over this, maybe it is of some use.

#5309751 Complex Health System. Let's review my concept

Posted by on 06 September 2016 - 10:50 PM

I reading this and I see that you're advising me to avoid randomness however I feel this is your own bias against games with random nature due to bad experiences.

Randomness per se is not bad, but it is a difference if you hit your enemy for 10-15 hp or if you can suddenly die "randomly" from a single hit.




tenaciousness health is a background mechanic that the player does not see

The point is, that it is pointless to add a complex mechanism which is hidden from the player. Even if the player will not be able to grasp the mechanism completely, he should be able to rougly understand the underlying mechanism.


The acceptance of the game mechanism depends heavily on transparency. Read some post-mortems about AI. Some observations are, that players accept a AI as more intelligent when the AI agent speak out loud its intentions (ie. "Fire in the hole" when throwing a grenade at the hidden player or "Requesting reinforcements" to warn the player), even if this is more unrealistic. If you dont do it, players feel cheated and have a bad game experience.

#5309604 Complex Health System. Let's review my concept

Posted by on 06 September 2016 - 12:11 AM

Well, this sounds somewhat complex, maybe too complex ?


In general you should avoid randomness. Games are about decisions and planing your decisions upfront is heavily hindered by randomness. Additionally to that, players want to understand the underlying mechanism to master them. Complexity will obscure them.


After all, you should put the complexity in relation to the game context. Is your game fast paces (action game) or really slow paced (turn based). Complex mechanism requires complex decision making which requires time.


My personal opinion is, that your mechanism is by far too complex, even for a turn based game. If this is not a game solely about hp regeneration, then you players will have a hard time to unterstand what is going on. The most common reaction will 'It is bugged like hell, I suddenly died from a single hit' or 'Health regeneration is totally bugged, I lost a game because it was suddenly slowed down.' smile.png

#5286809 DX11 Update textures every frame

Posted by on 13 April 2016 - 11:58 PM

My problem is that even the memcpy() of a 1080p RGBA texture into Map()'d memory takes a really long time (5+ms), so when I get up to 4K it's substantial.  What I could really use, I think, is a way to begin this copy process asynchronously.  Right now the copy blocks the GPU thread (since you must Map()/Unmap() on GPU thread, I'm also generally doing my memcpy there).

To be honest, I am more familiar with OGL, so some DX11 expert should have better tips.


For one, once the memory is mapped, you can access it from any other thread, just avoid calling API functions from multiple threads. The basic setup for memory to buffer copy could be:

  1. GPU thread: map buffer A
  2. Worker thread: decode video frame into buffer A
  3. GPU thread: when decoded, unmap buffer A

This will most likely trigger an asynchronously upload from CPU to GPU memory, or might do nothing if the DX11 decides to keep the texture in CPU memory for now (shared mem on HD4600 ?).


The next issue will be, when accessing the buffer. If you access it too early, e.g. by copying the buffer content to the target texture, then the asynchronously upload will be suddently result in synchronosouly stalling your rendering pipeline. So I would test out to use multple buffers, 3 at least. This kind of delay should be not critical for displaying a video.


An other option would be to look for a codex which can be decoded on the GPU. I'm not familiar with video codex, but there might be a codex which allows you to use the GPU to decode it. In this case I could work like this:

  1. map buffer X
  2. copy delta frame (whatever) to buffer (much smaller than full frame)
  3. unmap buffer X
  4. fence X
  5. ..
  6. if(fence X has been reached) start decode shader (buffer->target texture)
  7. swap target texture with rendered texture

#5286421 DX11 Update textures every frame

Posted by on 11 April 2016 - 10:59 PM

Copying textures every frame from CPU to GPU memory will be bottlenecked by the bus-bandwidth, so, check out your target platform (e.g. PCI-E) bandwidth and do some theo-crafting about how many times you would be theoretically able to transfer your textures from CPU memory to GPU memory. If this would be an issue, try to re-think your approach.


Data transfer will use DMA most of the time, so you can hide this transfer costs (aka avoid stalling your pipeline) if you can get along with one or two frames delay. If this is the case, look into double/triple buffering.


Eventually try to reduce the transfered data, either update only parts, use some compression or do even packing/unpacking.


Why are 2048x2048x2048 limiting ? Do you need larger textures ? I mean, 2k^3 ~ 32GB for an RGBA texture without mipmaps.

#5285048 A* A star vs huge levels

Posted by on 04 April 2016 - 11:26 AM

Create a hierarchy of waypiont graphs, you can even map higher level waypoints to certain points of interest (the cave entry, the big rock, the bridge etc.). Get the closest waypoint off your start and end waypoint and start A* on this level. Then go down the level, on each level execute the A* to the next waypoint of the higher level. The benefit of this  approach is, that you dont need the hi-resolution graph in memory, just the highest level is necessary and the rest on demand, and it is more natural. A human would not take the shortest path, he would most likely take the rout from town to town to travel over long distance.

#5284992 parallel precomputations

Posted by on 04 April 2016 - 03:10 AM

1 hour for 1000 nodes, are you executing A* 1000*1000 times ?


Check out the standard dijkstra which will find the shortest path from one node to all nodes. Yes, it will not find always the ways the A* will find, but it could be enough to estimate your rating.


To further optimize it, you can extend your waypoint data to include the dijkstra data necessary (costs and where it comes from) for multiple workers. This way you will be able to run multiple worker threads on the same waypoint graph concurrently (as long as you do not modify the waypoint graph during processing).

#5284965 Races vs. techtree vs. doctrines - choosing from the start or not...

Posted by on 03 April 2016 - 11:13 PM

The start will be usually the same but with good versatility later



No, the whole game will be always played in the same way. The issues with such an approach is, that you will have always a dominating development path and players are really good at detecting this path. In the end it is a rush for the dominating path, the one who is quicker will win. This 'stick-to-the-best-strategy' way of playing a RTS game has been observed in almost every game out there and it will although apply to games which have multiple different factions, but atleast here you need to change your strategy to counter the faction specific advantages.

#5284962 How beneficial can personal projects be?

Posted by on 03 April 2016 - 11:02 PM

As far as applying for jobs, how beneficial is it to have a long list of personal, playable projects? Should I be aiming to make a large collection of projects that demonstrate a wide range of different genres, styles and mechanics? 


Thanks a lot for any help smile.png

Not genres, styles and mechanism are important but showing understanding, knowledge and skill or just passion. I think , that some demos demonstrating skills in game design, visual rendering or AI behavior would be better. E.g. are you able to write a basic deferred rendering engine, a basic client-server, a balanced eco mini-game, some AI entities do some interesting stuff. On top of this you can try to create some over-the-top demos, implementing a more complex and modern rendering approach, solving some hard AI problems etc.


Game mechanism and genres might be useful for game designers only.

#5284424 Object Space Lightning

Posted by on 30 March 2016 - 10:27 PM


Overdraw is actually less of a problem, because the overdraw-ing shader is cheap as chips.


Sorry I meant the blending cost. Rendering a bunch of overlapping blended objects will still be just as slow.


It doesnt really matter compared to your standard particle system (mass-blended surfaces) or the costs for calculating light or some other complex shaders. It is really simply a alpha-blend copy from one buffer to an other, no magic, just the bandwidth for copying. Compare this to the bandwidth costs of all the other effects, like sampling multiple buffers for some g-buffer magic.

#5284177 Should I start with fixed-function-pipeline OpenGL or the newest possible?

Posted by on 29 March 2016 - 11:53 PM

The philosophy behind the old fixed function pipeline and modern APIs is too different from the developers view, that you should skip fix function pipline OpenGL. They are really two different beasts and learning to master a dead-beast will not help you to understand the new way of doing it, it will most likely only confuse you.


I would sugguest to learn the new way only (>OGL4).

#5284170 Unwrapping similar models to same texture

Posted by on 29 March 2016 - 11:09 PM

I've tried this to some degree. Basically it is often easier to unwrap each model separately (unwrapping a model in decend quality is done in 10 mins, you don't need hi-professional unwrapping for your game project most of the time, leave this to AAA budget games).


Reusing parts of the texture is often harder. What works best for me was to work with two uv -sets, bake the source texture to the target texture and use the target texture as paint base. E.g. you have a standard in-game uv-set (just unwrap the model) and a special uv-set which fits an existing texture (you don't need to cover everything, e.g. no need to fit a female face on a male model). Then bake the source texture with the special uv set to the target texture with the standard uv set. This works most of the time, still you need to rework the target texture.

#5284169 trade marked orc design

Posted by on 29 March 2016 - 11:01 PM

Design is copyrighted, so, basically the orc can be copyrighted too (thought it is not really design). But like a car, which design is copyrighted too, you still have 1000th of different car models with 4 wheels and green color. I'm sure that the modern green orc evolved by several artists, each getting inspired by a former artist and the first orc or goblin or whatever will be much older than blizzards orc.


Try to create your own orc by taking common references (bodybuilder for shape, animal references for certain features like eyes, ears, teeth etc.) and avoid taking other art as reference. The latter bears always the danger of copying design.