LorenzoGatti

Fixed ship designs can still have different crew. Associating ships with their home planet and planets with racial characteristics are two rather traditional patterns: X-Wing pilots from Tatooine could be talented but too aggressive, and X-Wing pilots from Dagobah could be slow but know special tricks.

Strategic conquest of the right planets, placement of shipyards, and breeding astronauts would replace research and ship design; do you think it would be a good thing?.

Yes, do apply correct accelerations.

 

You should use dimensionally correct variables: if positions are measured in pixels, speed is measured in pixels per second, not in pixels. If FrameTime is the variable timestep,  your updates should be

 

x_velocity+=x_acceleration*FrameTime

x+=x_velocity*FrameTime

 

or similar formulas for more sensible integration schemes. You are doing additional divisions, which are completely unneeded.

This is more suspect:

 

velocity.X = MathHelper.Clamp((float)Math.Round(velocity.X, 4, MidpointRounding.ToEven), -MAX_MOVE_SPEED, MAX_MOVE_SPEED);

 

It could round velocity differently for left and right. Log velocities and positions while jittering or not jittering to find out if it is the case.

 

Hello Guys , 
 
I am developing a running game in which player jump overs the obstacles

 
Timing jumps accurately is the main point of such a platform game: you should definitely let the player jump at any time and place, allowing any mistake and simulating crashing into obstacles, falling into pits etc. in the most predictable ways.
Note that a physically correct simulation can be reduced to a fixed animation sequence (or a fixed animation sequence for each state, presumably the combinations of a few horizontal speeds and a few platform slopes plus special cases like jumping from vertical walls).

With an exact time of impact for known colliding features there should be no need for "corrected" positions and other hacks: just apply forces and torques and continue the simulation. If you paid the price of exact CCD calculations, you should reap the benefit of really correct physics.

Random outcomes in turn-based games require appropriate player reactions (e.g. retreating hurt units, concentrating attacks depending on damage needs, placing units depending on how far other units are able to move, abandoning unfortunate units as decoys, etc.): far more interesting than applying a single optimal cookbook tactic. I recommend playing all units of all armies in Battle for Wesnoth for inspiration; it's an example with mostly medium-high damage randomness (depending on unit type; some have very low or very high randomness) mitigated by significant nonrandom defense bonuses.

 

I might be thinking of exporting a new model each frame and then run it through a small tool to work out what has moved and how much but this means I would need another quick 'n dirty step in the pipeline ;)
 
Any ideas? If not I might have to write a plugin for Blender but tbh I am worried that since Blender is a fast evolving open-source project, the maintenance required to keep the plugin in sync with the API could be quite a lot more work than a seperate tool.

 
I'd recommend trying a Blender plugin first: the API is stable enough and a separate "small tool" is likely to be complex.

 You really do. Which features of Roman numerals are better than Arabic? Is it best for computers to use binary, and does mathematics really support such reasons? Of course you can reason with mathematics to support the validity of your reasons, but the math is likely second-hand reasoning. I feel like everyone likes to pick up all the arbitrary and normative reasons handed to their ass and perceives them as inherent features of mathematics. You like to claim that's not true... whatever. This also occurs in... everything else. It has a lot of stupid side-effects, but it's just how humans build things. Human nature, though awesome, can often be annoying.

Setting aside the vaguely mathematical angst about human nature, I know a couple of things about computer implementations of number systems, and I can tell you are confusing a number of different levels:

• Formally right or wrong. All number systems "work" in the sense that they can represent numbers and be used for computation, but some are better than others.
• Special good and bad properties. Properties are formal, but what makes them a feature or a problem are technological factors. For example, number systems with only 2 symbols are a good match for electronic circuits, but not for many types of mechanical calculator. Inventing different representations using 2 symbols is an interesting mathematical challenge driven from concrete applications; nobody thinks "inherent features of mathematics" are involved.
• Fitness for a purpose. Nobody in their right mind thinks there is a "best" number system; it depends on what has to be computed and on a number of budgets and constraints; all applications require trading off representation size and/or electronic circuit size against computation speed (e.g. avoiding carry propagation in addition by storing 2 bits per digit) or initial and final conversion effort against computation effort (e.g. enduring BCD arithmetic because for few calculations it might cost less than converting to and from binary). Normal people don't have any particular "arbitrary and normative reasons" affecting these engineering choices; using bad technology (e.g. most arithmetic with Roman numerals) is usually the result of honest ignorance, not of epistemological biases.

The fences look quite good but they misleadingly appear to be foreground objects; consider replacing them with obviously soft decorations, like flowers and tall grass.

Only formal mathematics exists. Informal mathematics is just wrong and useless.

Maybe you are actually contrasting CS "practical" mathematics (readily applicable to writing software) and pure "impractical" mathematics (useful only for pure knowledge or further research), but even this dichotomy is quite meaningless.

I'm not convinced about the combination of unit-level turns and two actions per turn. One action only would be conceptually simpler and increase the importance of turn order and speed (e.g. allowing a fast unit to retreat after seeing the enemy advance, instead of letting it act only after the enemy has completed a move+attack turn).
Note that special combinations like shooting while moving can be treated as single actions.
 
The same applies to multiple attacks and counterattacks: compared to the possibility of attacking once and retreating if fast enough or staying in combat only long enough to kill the opponent or until the number of received attacks is safe, commitment to an extended exchange seems highly and needlessly inflexible.

Regarding the apparent disagreement in previous answers, filtering and mipmapping reduce aliasing in texture lookups (approximate sampling from wrong texture coordinates) which is separate from aliasing in rendering (approximate drawing to wrong frame buffer positions) but conceptually similar. They are addressed in different ways for technological reasons; for example, filtering texture lookups has been a cheap commoditized basic feature since the period of fixed function pipelines, while the same kind of filtering applied to rendering is a luxury because it would need expensive additional fragments as input.

From the strictly physical side, as already noted by others, nothing beats cards for presenting detailed information about an individual object; in fact most displays of information about one of many similar objects turn into pseudo-cards in videogame user interfaces, even if they aren't used as such. Therefore using cards or not depends only on having objects that are suitable for a card metaphor because they behave like cards: accessing sequentially the elements of random permutations of a large set, using them as a discrete and coarse-grained resource that can be accumulated (usually to offer the players the option of doing more or better moves when they matter in exchange for doing little in other turns), exchanging them for other cards or comparable objects, hiding and showing them, etc.

The benefit of hashing is being able to use a practically infinite grid with an arbitrarily small cell size, with negligible performance costs (computing hashes of positions instead of quantizing them, discarding the rare aliased objects). With a directly addressed grid you would have to compromise because you cannot afford the memory for enough grid cells, making your universe smaller and/or grid cells larger than they should be.

 

I recommend Bruce Eckel's free-to-download "Thinking in C++" books. Great content, good explanations - deep enough to clarify but not enough to lose focus - and good exercises. Sure, a bit old, but all code works (I ran most examples and solved most exercises with gcc and clang) and it won't stop you from learning C++11 after you've mastered the basics - actually, it will provide you with a solid base for C++11. Read Vol. 1 and do all exercises. Worth every second you spend on it.

 

It WAS a good book, but C++ has progressed and now it is a good book about an obsolete language that shouldn't be used. There are, of course, common roots, but why learn (and unlearn) old and unpleasant techniques along with the complex enough current state of C++?

A random example of how modern C++ has removed syntactic and conceptual cruft:
http://herbsutter.com/2013/05/09/gotw-1-solution/