conquestor3, on 08 Oct 2015 - 6:42 PM, said:
Can you stockpile resources?
In the current model, no.
Also I'm not so fond of this, it would require displaying these resources on interface, and it has more drastic consequences (you don't see the shortage coming if you are not careful, just one turn you get your production suddenly halved because you used up your reserves and your current mines capacity can meet only 50% of needs), also it is not within the mood of the game (you being the emperor and not dealing with logistics). A lot of drawbacks, for this particular game at least.
Building mines and factories is logistics, unworthy of an emperor. Stockpiling introduces significant elasticity in building mines and factories, easing the burden of logistics micromanagement: it's a negative amount of boring activities. Typically, players would notice they are accumulating resources and build a factory of something useful: always a gratifying moment.
Moreover, knowing the empire's stocks and flows of materials, through a suitable user interface, is part of an emperor's job. It's certainly more important, abstract and strategical than displaying the number of mines and factories.
Resource stocks introduce a valuable strategic opportunity: deliberately delaying production. Obviously plausible reasons include waiting for technological improvements instead of wasting resources on inferior products, waiting to know what's needed before committing to the wrong type of spaceship etc., pretending to be weak (baiting attempts to steal resources).
Explicit material stocks introduce the possibility of running out of them, but it shouldn't be sudden (if the players know what they are doing and user interface keeps them informed) or more troublesome than building too many factories relative to the amount of mines. It's strategy, and you need lots of it in a 4X game. With stocks, the player is going to make "good" decisions: do I want to invest in mines for the long term, or spend my stocks of materials on something urgent? Do I want factories to produce stuff now or mines to produce stuff in the long term? Can I find alternative sources of materials? And so on.
There's also the option of cuckoo hashing, with constant time worst case lookup performance at the expense of worst-case insertion performance, memory use and possibly speed: use two hash functions to compute two places for a key (usually addresses in two separate half-size arrays), look for it in both places when searching (the key cannot be anywhere else), place it in either designated slot when inserting (if empty), displace and insert in its other designed place the stored value if both places are occupied by other keys. This chain of reinsertions can also fail if a displaced value wants the place of the newly inserted key, requiring a rebuild with different hash functions or a different array size. Many obvious variants, like using more hash functions or small fixed-size buckets, can reduce the probability of expensive reorganizations and allow higher load.
Have you tried rendering your opaque rectangular donut as a plain old strip of 8 triangles? I would expect it to be slightly more efficient than using more memory for the stencil buffer and more fragments (ended early, but still processed) for overdrawing the hole region.
There's a fundamental difference between positions (which might or might not include an orientation) and transformations which can be applied to a position to get another position. Transformations have a group structure (they can be composed with one another to get another transformation), in common cases even a vector space structure (e.g. typical 4*4 matrices) while positions don't have useful operations giving other positions (finding the transform which maps one to the other or finding their distance give values of other types).
Even if you represent positions and transformations in an apparently similar way (for example x,y and z coordinates for points in a 3D space and displacement along three coordinate axes for translations) pretending they are the same thing causes only confusion.
A variant of area of effect weapons: severe explosions when ships are destroyed, imposing large safety distances (which the player could ignore to intensify attacks).
In an abstract combat system, just make fleet attack strength proportional to the cubic root of the ship count or similar formulas, to make stacks of not-quite-doom less useful than splitting forces to fight multiple battles fronts.
I'm probably going to be using sprite based animation instead of 3D. I guess I going define bind-points on each frame and use those, right?
You might need different character animations for different weapon strikes, even if you draw the weapon itself separately.
For example, a wide swing from left to right might be suitable for any polearm, but not for two-handed swords (hands are necessarily much closer) or one-handed shorter weapons like swords and axes (the other hand is swinging away for balance, holding a shield, etc.).
A cycle of many days means waiting many days for the right night to do things rather than going forward ASAP with one's plans. This fits well with many roleplaying game situations where the player either takes initiative or has the means to plan and respect an imposed schedule:
You want to attack the evil mad wizard's fortress during the 4 hours window every 1440 days in which the defensive spells turn off. You have five weeks to get there from another country at an expected average travel speed of 16 miles per day. If you travel too slowly, or if you are delayed during the raid, the world is doomed.
You want to seduce a fellow student at the wizards academy, where charm spells, countermeasures and counter-countermeasures are a standard part of courtship. Depending on your magical resources and what you have scouted of theirs, what's the optimal day to ask them out between now and the summer break?
Today we have fire spells, let's torch giant spiders in their webs. On Wednesday we'll have enough ice magic to face the firebreathing dragon.
If the schedule is out of control, the game is going to be unfair.
You discover you should be at the evil mad wizard's fortress tonight. No teleportation? Sorry, you've just lost the war.
You want to seduce a fellow student at the wizards academy. Unfortunately you'd need several months of study to learn enough love magic for a good first impression. Sorry, wrong course plan at the start of the year.
Today we have fire spells, the firebreathing dragon attacking us is laughing with a hint of sarcasm because he knows.
I don't see any difference between "main" and "secondary" weapons: both classes are used to shoot other ships. More meaningful distinctions include:
Weapons that can be mounted arbitrarily vs weapons that require a special position (e.g. gigantic particle accelerators along the middle of the hull of a large and elongated ship)
Weapons that can be aimed autonomously (e.g. typical real-world artillery) vs weapons that require orienting the ship to aim (e.g. said particle accelerators, and launch tubes for missiles and torpedoes)
Dumbfire vs aimed projectiles.
What's available in these different categories and effectiveness of different attack types depend on the needs of your game. For example, the first post shows a bias towards relatively low power and not very fancy weapons (only very large guns against very weak targets are capable of serious overkill, while humble weapons that don't pose a threat to well armored targets are common), accompanied by an expectation of weapons hitting almost always (no dodging or evasion) and, as a consequence, of battles of attrition being decided by imperviousness to damage. It would be appropriate for good armor to be very heavy and bad for maneuvering, to make heavy ships pay for it, but very effective against weak weapons, and for good energy weapons to require so much energy that they can only be used sparingly, with complications like charging times, turning off engines etc.
Even within these parameters, many possible styles of space combat are possible: fleets could routinely ambush each other from good cloaking, hyperspace etc. (making weapon ranges irrelevant), with mere seconds or minutes of engagement as the weaker party frantically escapes with FTL drives or the like, or battles could last for days as fleets chase each other at nearly the same speed, just out of weapon range, or fast ships with long-range weapons could surround and grind down an enemy without fear of retribution.
The problem is not unlimited lives, but restarting from the beginning after dying (or more generally restarting from sparse checkpoints), causing the player to go through a large boring level part before reaching the place where he died and where he can try again.
Limited lives are a means to stop playing: in a coin-op game because you are supposed to pay to play (and play for a time that's strictly proportional to your skill), in a console or computer game because independent successive attempts to beat the game are more meaningful than retrying forever.
I should mention, the main reason I want the map to be static is because I want some sort of storyline/environment in the game, where there are different cities fighting each other and the player has the freedom to choose which cities they want to help and which cities they want to destroy, and quests will adjust according to the choices that the player has made.
My fear is that having randomly generated cities might look bad, and will break immersion.
You can mix procedural and fixed content top down or bottom up; in your case, probably both. Content should be procedural by default, with specific things you need for plot or game balance reasons imposed as an exception.
Top down, you can simply constrain procedural generation: if you can ask for a city around a certain latitude and longitude and containing a certain list or number of buildings, NPCs and other features, your cities will be different every time but sufficiently "the same" to serve the purpose of a standard storyline.
Bottom up, you can integrate something fixed and detailed in the middle of procedural content. For example, a capital can be specified to contain not only, say, 3+3d4 swordsmiths and 4+1d8 luxury inns, but also a royal family of 20 members with names, stats and important possessions specified beforehand.
Both techniques are used all the time in RL games. At the highest level, the two common level structures are a major top-down constraint: both the sparsely connected graphs of small linked dungeon and outdoor locations and the combination of interesting places and vast and boring large-scale outdoor maps containing them determine the plot of the player character's exploration.
Some games have fairly fine-grained bottom-up "islands" of fixed content: Angband has vaults, predefined dungeon sections (with variable treasure and monsters) that can replace plain random rooms, while NetHack has, for example, a suite of levels consisting of Sokoban puzzles (exactly specified and picked randomly from a list of alternatives).
There's an obvious counterpart to the traditional RL level structure of dungeon levels linked by stairs: solar systems where you fly around and some kind of "stargate" (which can require the same kind of searching and strategic combat as dungeon stairs) allows passage to a similar stargate in another system. Already done very well, with free movement rather than a grid, in Transcendence.
I don't think Subversion is going to be practical, because conflicts and locks and inconsistent states in the shared repository can lead to serious frustration and waste of time. Git would be much safer, particularly if you tell your students to do things in a certain standard way without messing with complicated commands, because at worst users can can wipe their own uncommitted working copy changes.
Everyday use of Git requires few reasonably simple commands: pull (with few or no conflicts), log, status, commit, sometimes push. In particular, if you want to deal with merging yourself, you can pull from every pupil's repository at your leisure (presumably in class, while they are working and their computers are on, connected to your LAN and serving their repositories via HTTP) and tell them to never push changes anywhere, which is a significant simplification. You also have the solid fallback solution of backing up and/or sending entire repositories.
You mention Eclipse, which has fairly nice tool support for Git; it is likely to be even nicer than command line tools.
From my business programming experience, I think C# is a fairly good and stable language, but the accompanying libraries less so; it continues the established Microsoft tradition of introducing frameworks (historically database access and web programming, lately also GUI) and keeping around the old ones.
Learning generally applicable C# complications and advanced features (e.g. signed assemblies, using native code, LINQ, extension methods, annotations, DLL hell, how to use Visual Studio, etc.) would be better than falling in love with the latest novelty framework.