77

Now how does the game handle those 30 Projectile and 70 units by handling them on 100 different threads No, never do that. Never create a new thread per resource, this doesn't scale in networking, neither does it in updating entities. (Anyone remember the times when you had one thread for reading per socket in java?) 1 thread that moves all of them ...


51

Go with the second approach, simply due to the fact that you can introduce new resource types or items at any time without having to rewrite or update code (data driven development). Edit: To elaborate a bit more on why this is in general good practice, even if you're 100% sure some value won't ever change. Let's take the console game example mentioned in ...


39

Rule number one of multithreading is: Don't use it unless you need to parallelize on multiple CPU cores for performance or responsiveness. A requirement "x and y should happen simultaneously from the users point of view" is not yet sufficient reason to use multithreading. Why? Multithreading is hard. You have no control over when each thread gets executed ...


29

A rule of thumb is that you use different classes when objects require different code and instances of the same class when the objects only require different values. When the resources have different game mechanics which are unique to them, it might make sense to represent them with classes. For example, when you have Plutonium which has a half-life time ...


27

At first you see that your commands are in the form of a list, so your first instinct might be to recreate that structure, and each dwarf will run through that list in sequence. What I suggest though is to break the list into steps, with each step having prerequisite(s), and then you run the entire command in reverse. Let me demonstrate with an example: ...


26

The other answers have handled the threading and power of modern computers. To address the bigger question though, what you are trying to do here is avoid "n squared" situations. For example if you have 1000 projectiles and 1000 enemies the naive solution is to just check them all against each other. This means you end up with p*e = 1,000*1,000 = 1,000,000 ...


21

The only similar system I know is OGame. In OGame, players are protected from other players until the have a certain amount of points (I think it is 50.000). It makes more sense to protect players based on their score instead of time, as score gives you a better aproximation on how powerful players are. The theory is that with that many points, players are ...


17

Do not create threads per resource/object but per section of your program logic. For example: Thread to update units and projectiles - logic thread Thread for rendering the screen - GUI thread Thread for network (eg. multiplayer) - IO thread The advantage of this is that your GUI (eg. buttons) does not necessarily get stuck if your logic is slow. User can ...


14

I would like to add there are two extra options: Interface: you can consider it if the resource class would be just a "storage" for 5 integers and each other entity would have different logic regarding resources (e.g. player spend/loot, city produces resource). In that case you might not want a class at all - you merely wanted to expose that some entity has ...


13

Rule number one of multithreading: Don't even think about it, unless you really need to use multiple CPU cores for performance reasons*. Multithreading opens up a whole can of worms of obscure and impossible to reproduce bugs: Race conditions! Because you have no control over the thread scheduling of the OS, you have no control over the order in which ...


12

Your goal of synchronizing 50 events per second in real-time sounds to me like it is not realistic. This is why the lock-step approach talked about in the 1500 archers article is, well, talked about! In one sentence: The only way to synchronize too many items in too short time over a too slow network is to NOT synchronize too many items in too short time ...


11

If you can make sequences pretty general, there's not much of a spaghetti code. In case of deliveries e.g.: WorkTask operates with a WorkPlan. Workplan says what kind of resource unit must pick, from what kind of house, using which walk animation, using which work animation, time to work and all such details. So in the end WorkTask might look like: Find %...


10

Reduce progression in your game mechanics. Avoid making players stronger in a game-mechanical sense based on how far they progressed in the game. That way an experienced player has no unfair advantage over an inexperienced player except for their game knowledge, which a new player can also acquire when they do their research. Herd your players. When a player ...


9

Summary: Depict differing world-views and perspectives in a value-neutral, non-judgmental way In order to deal with prejudices, biases, and bigotry, I would focus away from artificial "This is a minority in the galaxy. It's wrong to hurt them!" style methods. It's not that it's inappropriate, but that it would be ineffective at doing anything ...


9

Influence maps are data structures that model various relationships with respect to their locations, and typically assume that the impact of these relationships spread outward across space and/or time. For instance, positions close to cover would be considered safer than those further away. Similarly, regions with recent enemy sightings might be considered ...


9

I'd base the system on three basic principles: each unit type has different HP values that affects its mortality rate. all damage done is lethal (otherwise, just multiply by a scaling factor) each squad takes total damage in proportion to the number of individuals. Example: Your starting army army 1400 infantry (ea. 50 HP) 500 cavalry (ea. 100 HP) ...


7

Our life is frittered away by detail . . . simplify, simplify. (Henry David Thoreau) My answer is similar to those that suggest picking a clear role for the player. What they're really saying is to simplify I think. The reason micromanagement happens is because there are very many choices to make during play, and in general they only really matter in ...


7

The first step is to have design goals. Figure out what kind of features your game will have, so you know where to focus your efforts and what designs to look out for. Will it be graph heavy? Will it be minimal and have panels upon panels hidden away? Will most of the action take place in the UI or in the game world? Will it be animated? Does it have a theme ...


6

i don't know about Risk but i had developed a Chinese Chess game few years ago. I think you can try Minimax which the game calculate every possible decisions and each decision will branch out a node for all the players until a certain depths within reasonable time. I think it is suitable for most turn based games. For 'difficulty' your game will randomized ...


6

every action the player takes is deterministic, however, there are events that happen on scheduled intervals I think there's your problem; your game should only have one timeline (for gameplay-affecting things). You say that certain things grow at a rate of X per second; find out how many game steps are in a second and convert that to a rate of X per Y game ...


6

What you've described is the difference between Lanchester's linear and square laws. These are formulas estimating the rate of attrition between a battle between two military forces. The linear law says that the two forces suffer a constant rate of attrition, regardless of the size of the forces. This is used as an approximation of ancient combat, between ...


6

Firstly, I'd try a simple greedy AI strategy that just goes to the nearest unexplored planet and explore it. It could be enough to make the game interesting while not making the AI invincible. With that said, supposing you want to practice ML, or want it just for fun, there are a few options: Store the input-output vectors you mentioned from human game-...


5

float size = 1.0 / NumTiles; float2 Base = UV - fmod(UV, size.xx); float2 Center = Base + (size/2.0).xx; return tex2D(ScreenTexture, Center); Make your render target be a texture called ScreenTexture, render your scene, make the rendertarget be the backbuffer again, draw a fullscreen quad with ScreenTexture and apply this shader on it. It is called Post ...


5

Ok, if you don't care about the graphics, that's simpler. From a high-level pseudocode, what I suggest is like how any other game loop works: while game has not ended yet: keep going // we're out of the while loop; game has ended show results, etc. go back to main menu Thing is, yours is turn-based, so we can do away with the loop part, or keep it and ...


5

So this is basicaly topographical sorting problem. You have a graph, each node is a task that needs to be done, and some nodes depend on some other nodes (this is represented by an edge in the graph from depending node to the node it depends on). You want to do all the tasks, so you need to produce SOME ordering of the nodes that is topographicaly OK (the ...


5

Unity is a game development platform that uses languages, such as C# and JavaScript, to create scripts that provide behaviours for elements within your game. If you're creating a 2D top-down game, you could use tools such as GIMP, Paint.NET or Photoshop to create graphics that you would import into Unity as assets. For your map, you could create a world ...


4

This is known as 3D picking, and usually involves some kind of raycast from a point in screen space (the cursor position) in the camera's forward vector direction. For some Ogre tutorials, check those links: http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Intermediate+Tutorial+3 http://www.ogre3d.org/tikiwiki/ThreeDeeObjectPicking http://www.ogre3d.org/...


4

Instead of click-speed limiting how many orders a player can send, make it an in-game resource. Click too fast and you run our of orders and have to wait to accumulate new ones. Order single units and you can only afford to move a few per minute, but make big group moves and you can keep your entire army moving. There would still be a benefit to micro-manage,...


4

That sounds like a really bad idea. For multithreading to work well you need individual tasks that require significant computation, and can be easily segregated so that they don't work on the same dataset. There is an overhead to each new thread you use, there is in some cases a big overhead for shipping data between threads, and once you have occupied each ...


4

Before you do anything read the first paragraph here First and foremost, running hundreds of threads isn't going to boost performance. It is going to instantly ruin your game. Why ? Because afaik in Windows and Linux the schedulers wakes up every millisecond (possibly more like 3) to check if another process needs to run. So if you have 50 tanks and 100 ...


Only top voted, non community-wiki answers of a minimum length are eligible