You can reduce your goals: instead of a general purpose toolkit, you can automate some of the work of developing one specific GUI-intensive game.
You can hack together a proof of concept GUI, digest it into simple text-based templates for completely ad-hoc code-generation tools, and push a button to regenerate a high-quality GUI whenever you make changes to your game.
Automated generation of write-only code would also allow you to use ugly and dangerous techniques like small integer unique identifiers, big switch statements and tables, etc.
I am using Boost Serialization to save/load from the filesystem, which up untill now has been absolutely wonderous as it requires almost no code to do it.
However after importing some 3d models and then try to load it up again, the loading times are enormous; it takes almost 30 seconds to load from filesystem and then to deserialize.
This is the code to serialize/deserialize:
iar >> (*pkg.get());
Are you kidding? Your post doesn't not include struct constructors, nor the actual serialization and deserialization code (I assume it is defined in the missing JonsPackagePtr class), the only places where you might be doing something slow. Post a real code sample.
I suggest a realistic simulation: less complications and arbitrary decisions for you, and less surprises and aberrant strategies for the players. Abstractions (like "planets regenerating their pool of recruits" or "switching to a ship from reserve") are a threat to the integrity of your game.
Damaged ships can be reclassified for automation purposes (e.g. large ship with disabled weapons, capable of transporting cargo but in need of some escort) but they are still flying: sending them to a shipyard for repairs or major upgrades is an order like any other.
Reduced-crew ships (e.g. out of redshirts after too many planetary operations) are likewise operating as usual, with reduced capabilities; sending them where new personnel can join the crew should be the player's choice.
Severe cases of damage (e.g. no life support) and crew reduction (too few people to pilot) should be treated as a lost ship. Other ships can rescue crew and other stuff, particularly in the case of inoperative engines.
The crew of destroyed ships can leave in escape pods or the like, which you can treat as other ships or, more simply, as people reappearing in a preassigned or AI-selected destination after a predictable time (with some chance of dying instead of arriving).
Crew assigned to other ships has to travel explicitly (on board a suitable ship) to a base or to a rendez-vous in space, with normal travel time (not "immediately"). Starting such travel on board a damaged ship in the case of recycled crew or on a planet in the case of newly trained officers is a minor detail.
Every ship is located somewhere, including mothballed ones. It takes a crew, either directly assigned or manning a big carrier ship, to move "reserve" ships where a full crew will make them operational again. Is there a large difference of quality and/or quantity between the minimum crew required to fly around and the full crew required for war activities?
The number of ship officers coming from a certain planet can be limited by the rate of training new starship personnel (e.g. each academy begins a 40 cadets five years course every six months, with 75% dropouts: 10 officers every six months at full capacity) and/or by the rate of breeding exceptional people (e.g. if one child in a million has the required psychic powers to be a warp pilot, a population of 1 billion women who have an average of a child every 50 years yields 20 potential warp pilots per year). Neither limit gives rise to a hard cap on personnel coming from a certain planet, as their numbers, their social impact and their cost of living are negligible.
Moreover, anything that happens on the war front has no impact on training replacements for lost crews: qualified starship personnel is supposed to be trained as fast as possible at all times, especially during a war.
Both spare ships and spare personnel can be, and should be, shipped around planets and bases according to strategic predictions: places near the front are appropriate for gathering new officers, new ships, repair parts, and ships in need of repairs and crew.
You can effectively limit available personnel, and active fleet sizes as a natural consequence, by making the duration of a war much shorter than the time needed to get significant numbers of new officers.
If a ship can reach any place on the map in 2 days, and there are (at the beginning) 9 mothballed ships for each active one, about 40 days (slightly more in case of losses) are enough to fly every ship you have into battle. Meanwhile, the number of new officers produced is negligible compared to the merely shuttled around ones.
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?.
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
or similar formulas for more sensible integration schemes. You are doing additional divisions, which are completely unneeded.
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.
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.