powershellin a command prompt window.
Banner advertising on our site currently available from just $5!
LorenzoGattiMember Since 25 Nov 2005
Offline Last Active Today, 03:24 AM
- Group Crossbones+
- Active Posts 1,707
- Profile Views 10,284
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by LorenzoGatti on 25 November 2013 - 08:20 AM
Posted by LorenzoGatti on 22 November 2013 - 05:30 AM
This approach throws away deterministic simulation; in many game types the slightest variations in numerical values (unavoidable after a single increased timestep update, even with the best computation quality) can lead to large differences in game state later on.
If its a single player game and its constantly very slow, I think the way out would be to switch down to a fixed number of less logical ticks with comparably bigger steps, when the game estimates it will not catch up. Though that would require the foresight to have the logic programmed for variable timesteps, even if in normal case on fast computer it would always do same fixed timestep.
Posted by LorenzoGatti on 20 November 2013 - 02:59 AM
I hope I don't understand what you mean to do, because all I can see in asymmetrical and nontrivial starting conditions is a world of pain without discernible benefits.
On that track, I do still think it holds true that in a battlefield/combat based game, a varied or dynamic start is something that can help balance certain deck-and-play styles without affecting others that might be in less compromising positions. Altering the base stats of a certain commander (or granting indirect nerfs to certain cards in a commander's deck) as needed to ensure that the deck is still fun to play, without being overwhelming.
Apart from difficult self-inflicted balance problems (e.g. X units on the battlefield at the beginning are worth Y extra cards in the starting hand: find X and Y and ensure they are a balanced choice in all conditions), starting with something on the battlefield helps highly noninteractive rush strategies of various types: play a large horde and exploit numerical superiority to engage all enemy units allowing others to attack some objective undisturbed, play some kind of "artillery" and exploit long range attacks to exterminate arbitrary enemy units before they become a threat, play wizards and exploit early and excessive buffing to do something ordinarily impossible, and so on.
Can you give some examples of how varying setups can be an adaptation to the enemy Commander? What do you gain by letting players have their appropriate responses on the battlefield from the beginning instead of playing them gradually? Given a choice between deploying the specialized pieces of a rush attack or deploying things that are useful in a long game, what makes the latter more appealing? What makes adapting to the enemy Commander more useful than exploiting synergies with your own Commander?
Posted by LorenzoGatti on 19 November 2013 - 11:41 AM
No, the effectiveness of "non-interactive" decks in Magic: the Gathering is a consequence of being able to win by directly messing with the opponent rather than by grinding through creatures and other permanents (as would be the case in any seriously battle-oriented CCG).
An Issue I have with MtG's 20-life 7-card start in eternal formats is that it doesn't encourage player interaction. It's not as much of an issue in the ever-expensive T2 format, but if you look at even modern decks with great winrates (zoo, UW Control, RDW) you begin to see a pattern - none of the decks actually care about what your opponent does.
The less they care about their opponent's actions, the better chance they have of getting some wincon on the field. This is because, as you mentioned, each deck can be tailored to a specific goal: getting 20 damage out; dealing with 7+turns cards (no cards = no options); decking an opponent; gaining 40 life with a creature on the field.
Varied starting condition would only make some of the boring strategies more effective. More life? You can pay more life as a cost. More cards? You might be able to run the opponent out of cards, or to rush a lot of spells in unusually few turns. Free lands? Cards with higher casting costs become practical. Scrying or the like? Less copies of certain cards can be enough. Strategies would change a bit and remain equally aggressive.
In particular, suppose Magic: the Gathering rules were changed to begin the first turn with, say, 20 permanents on the battlefield: the game would become even less interactive, with an ample choice of disgustingly bulletproof overkill combos (likely guaranteeing victory for the starting player during the upkeep phase, without even attacking; figure out how, it's fun but off topic).
Decks that minimize player interaction severely limit the amount of fun your opponents get out of the game, and definitely detract from the social aspect. I'm hoping to mitigate this by using a dynamic battlefield, with win conditions you can affect without having direct counters for them. An example could be Dul'Nam, the Dark Lich, has a ritual that will turn all living creatures that die into undead under his control. His opponent could disrupt the Ritual with a fast harrying unit, or power through his losses and stab at Dul'Nam directly, forcing him to divert resources from the ritual into faster sorceries.This example is representative of critical aspects in which a battle-oriented card game should do the opposite of a magic duel card game like M:tG. Major actions (like the necromantic ritual) take many turns (as opposed to be a single spell, ability or attack that must be dealt with immediately), and just about any unit can easily attack the Commander or troublesome targets in general (as opposed to the general inability of M:tG permanents to hurt each other).
There should be enough time to obtain more units after the ritual begins and get them to attack the necromancer before the ritual is completed (provided they fight their way beyond enemy lines).
Posted by LorenzoGatti on 19 November 2013 - 03:46 AM
Posted by LorenzoGatti on 19 November 2013 - 03:18 AM
No, it's just a vector pointing north that you want to use to find a plane and then compute projections and angles.
The magnetic vector is effectively the sensor's own world axis.
If I understand correctly, you want a cartesian coordinate system tied to a certain point of the surface, in which axis z points "up" along the direction of gravity at that point (or more simply along the surface normal, treating Earth as a sphere).
I need to be able to get the local yaw of the sensor regardless of its orientation. To do that I felt I needed to go into the sensor's local coordinate space but now I'm not so sure.
Choice of x and y axes in the tangent plane at that point has one degree of freedom, which can be used either to place axis y in the plane spanned by the z axis and the north vector (so that it points towards the magnetic north) or to place axis y along a geographical meridian (so that the projection of the magnetometer reading on the xy plane work like a compass).
All angles you mention are measured between the x,y or z axes and the north vector or its projections on the xy, yz or xz planes, all of which are easy to find.
Posted by LorenzoGatti on 18 November 2013 - 05:03 AM
A potentially grim setting: political parties, with leaders, elected officers and groups of activists and supporters as "units", electoral districts within one country as map sectors, player moves that don't include assassination or civil war (e.g. bribery, blackmail, aggressions, essays against leaders, public speeches and propaganda, lawmaking, terrorism against the masses) and relevant events (e.g. elections and important parliamentary votes).
A more lighthearted setting: tribes of clams colonizing some rocks, who try to persuade larval-stage mobile clams to join their tribe and settle on a certain rock, try to persuade "enemy" clams to leave rocks and go elsewhere by appropriately silly means like team-based insult duels, and win by "controlling" rocks.
Posted by LorenzoGatti on 18 November 2013 - 04:13 AM
The overall outline for the game is that you've got a commander or leader of some kind that determines a lot of
your base stats for the game - health, toughness, strength, resource income, certain spells or abilities, etc. The
rest of your deck then gives you the ability to 'cast' various allies or creatures, spells, equipment, castles, and
battlefield terrain. Battles would be fought on a grid reminiscent of Heroes of Might and Magic, with your Leader
beginning on the field somewhere on your side, and your opponent's leader on his side.
This seems extremely incoherent.
- If you want a card game in which the Commander deploys units and does useful things by playing cards, both sides should start out on an equal footing, with nothing on the battlefield but identical Commanders differing only in the contents of their card deck. Commander experience should give only cards, not troublesome advantages.
This is the Magic: the Gathering approach: everybody begins with 20 life, 7 cards and nothing else, any difference between players would be an almost unheard of handicap match, and a disadvantage of 1 or 2 cards often means defeat regardless of decks and player skill.
Fixed starting conditions allow players to optimize decks for a single scenario, rather than being forced to do everything (badly). For example, suppose you want to make an all-in aggressive deck (i.e. one that forfeits defense and runs out of resources to kill the opponent with cheap cards before he does much): should it reliably do 15 damage by turn 2, 20 damage by turn 3 or 30 damage by turn 4? Starting at 20 life means that the first deck is too weak, the second is the right target, and the latter is too slow; starting anywhere between 15 and 30 life means that all-in aggressive decks cannot operate properly against most opponents.
- If you want a grid-based, turn-based tactical combat game in which "health, toughness, strength, resource income, certain spells or abilities" of the Commander matter, the Commander is only one unit in the player's army and there's no reason not to begin the battle with more units, their equipments, already cast spells, etc. Cards could still have a role, for example to determine which special combat actions are available, but the CCG aspect would be limited.
A recent particularly pure example: Chaos in the Old World, a strategic game in which Chaos Gods conquer and corrupt regions of the Old World. Every turn, each player spends resources to place units in some region and to play cards from a god-specific deck, which have local effects (one region, or even specific units in that region) and are aligned with that god's specialty and victory conditions (e.g. Khorne, god of slaughter, who scores points for killing others' minions, has many cards to fight more or to win fights).
There is no "commander" (major demons are merely middle-late game expensive units, not leaders) and no deckbuilding (the four gods are already very specialized, while selection and placement of units is the backbone of strategy); cards cause uncertainty and offer an opportunity to make the difference with dirty tricks, putting the right amount of Chaos into what would otherwise be a small scale hybrid of Risk and Diplomacy.
Posted by LorenzoGatti on 18 November 2013 - 02:57 AM
- Why don't you like downscaled normal maps? If the 8K ones are normalized, why should they be normalized again?
- What's a cavity map? Are you sure it's directly related to the normal map?
- If you don't like a specular or roughness map, what prevents you from retouching it with an image editor?
Posted by LorenzoGatti on 13 November 2013 - 05:28 AM
Wouldn't the size problem be reduced if you avoid putting continuously updated precompiled binary files into git/mercurial and dont add all kinds of external stuff you depend on into a single repository but instead have some sub-repositories?
You could also split it up to put the source art files, the compiled art files, the compiled code into 3 svn repositories, to reduce the load in the dvcs further by only having source code inside. Or add some custom merge tool for some binary files or convert them when storing into the repository to make them mergeable.
Maybe on bigger projects people have some buildserver already that compiles everything for testing commits, that could also update the separate svn repositories for compiled things, for the artists to avoid having to compile code and the programmers avoiding to convert art files themself?
Compiled binary files have no reason to be in SOURCE control. Important ones, such as public packages of release or beta test versions, should be archived to Dropbox, network shared drives, or other types of "dumb" storage by build managers to let others download them as needed.
Old compiled binary files, as opposed to compiling the game by themselves, are needed by developers only for unusual reference purposes (e.g. testing that building the appropriate revision of the sources reproduces what's been released), not to be routinely updated, compared, and be copied to or from their personal workspaces like sources.
Correctly managed binary source assets are unlikely to be troublesome: they should be available to everybody (enabling all developers to build the game), which is a good reason to make all revisions easily available, and they should change only rarely and in meaningful fine-grained increments (for example, repainting a 3D model should change that model's texture maps, not a big texture atlas containing lots of unrelated images; the big texture atlas can be kept outside source control and rebuilt automatically).
A sane organization of assets and build tools is an opportunity, not a cost incurred because of source control; setting up an easy, automated and effective workflow using source control should be compared to skipping the initial effort, sinking into progressive complication and confusion, and throwing the towel (or wasting a lot of time) because of errors in manual builds.
Posted by LorenzoGatti on 13 November 2013 - 04:45 AM
Posted by LorenzoGatti on 13 November 2013 - 04:27 AM
Don't guess, measure. Run benchmarks with both versions of the shader applied to a set of computationally heavy cases of your game (e.g. multisampling and unusual amounts of overdraw to stress fragment processing, lots of geometry to stress vertex processing, artificially inflated texture number and sizes, etc.)
But is it really faster to use real time calculations instead of a pre-rendered texture for the distortion offsets? I always thought it was the other way around - texture sampling should be faster than these calculations, at least. You're doing the calculations every frame, whereas for the texture - it is only filled with the distortion offsets once.
Posted by LorenzoGatti on 12 November 2013 - 04:20 AM
The program counter and the accompanying notions of current and next instructions are abstractions, very useful to define what the various jump instructions do (choose the next instruction to execute, overriding the default of the one after the current instruction) but not necessarily related to how a processor actually works. Instructions can be executed out of order and simultaneously, making these concepts something that is merely emulated from the point of view of the program.
From what I read the Program Counter can hold the address of the current instruction or the next instruction.
1) Does that mean it can only hold one of the two at one time? If so, why is this?
You can trust a processor to hold the address of an instruction it's fetching for as long as it's needed and then forget it, but there can be a queue of instruction addresses to fetch (possibly shared by multiple hardware threads or multiple cores) or something even more different from a program counter register.
Fetching data from memory is the job of specialized hardware, including the instruction cache. Registers simply hold addresses, which are sent to the appropriate parts of the microprocessor.
I also read an instruction needs to get fetched, is the program counter doing the fetching too? I thought it was its job is to hold address of an instruction.
If you pretend the program is a sequence of instructions, you go to the next one; at the abstraction level of memory addresses you need to account for the length of encoded instructions, which is often variable.
2) When an instruction gets fetched: what does it mean for a program counter to increased its stored value by 1? Is it as easy as adding the number 1 to this value?
Circuits and registers count in binary (high/low voltage); hexadecimal is only a human-friendly representation of binary numbers that, unlike decimal numbers, doesn't involve carry. But actually it's none of your business, the only addresses you need to read and write correctly are the ones in your program (which can have a far more complex structure with segments, offsets, implicit or discarded bits, etc.).
3) Is the address of the instruction binary or hexadecimal? Is it encoded beforehand before the program counter fetches it?
The IR is an abstraction (what's the processor doing?) that doesn't correspond directly to microprocessor operation; the instructions being executed are represented implicitly in the configuration of what each register and execution unit do at each clock cycle. Moreover, what's executed is usually a sequence of low-level operations, not the complex instructions in the program.
4) If the program counter is holding the address of the next instruction, is the instruction register holding the address of the current instruction?
Usually, dedicated address decoding units (hence the famous historical repurposing of the x86 LEA instruction to do arithmetic); on the cheap, the same ALUs used for general arithmetic (a lot slower). The result is the same, so it doesn't matter for the programmer.
5) Who does the decoding of any of the two addresses of the instructions?
Posted by LorenzoGatti on 12 November 2013 - 03:35 AM
You imply that managing nobles in a bureaucratic empire is inappropriate, but you can focus gameplay on handling specific important people (as opposed to giving abstract orders to faceless organizations) in any social structure.
On a more serious note, just managing nobles seems meh to me. As King of Men said, if you want to manage nobles go and play CK2, it portrayed it very good. I don't think I woulod be able to do it much better than they. Plus, I lean more towards a bureaucratic empire, like there is this emperor and organizations, guilds, corporations, social struggle, spreaders of dangerous ideas. Less feudal and more modern (not that they can't be nobles there, I don't have anything agains them, but just limiting it to nobles seems not so great to me).
If nobles have a limited importance for the Empire and the Emperor (e.g. as sources of succession by assassination plots, as marriage fodder and as trusted diplomats), the game can bring to the forefront other types of important people: generals and heads of bureaucracies, political or religious leaders, scientists and artists, entrepreneurs and managers, and all other relevant types of powerful or influential special persons (e.g. fairies or alien visitors, artificial intelligences, superheroes of all sorts, wizards...).
Posted by LorenzoGatti on 04 November 2013 - 04:25 AM
I prefer the opposite perspective: use the latest Python 3 version because the language and standard library are improved, and you don't want to depend on third party libraries that are demonstrating obsolescence and lack of maintenance by not having a Python 3 version.
I would recommend the latest version of Python 2 (currently 2.7.6) rather than Python 3, simply because most of the libraries you might be likely to use still support the older version, and because there are still currently more resources available for learning 2.7.
Enough time has passed since the introduction of Python 3 to give library maintainers a fair chance, and important libraries like Numpy and PyOpenGL have been ported without trouble: libraries without a Python 3 version are either abandoned, developed by someone too clueless to care, or legacy software that should only be used for maintenance of projects from the Python 2 era.