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.
LorenzoGattiMember Since 25 Nov 2005
Offline Last Active Today, 06:12 AM
- Group Crossbones+
- Active Posts 1,846
- Profile Views 14,496
- Submitted Links 0
- Member Title Member
- Age Age Unknown
- Birthday Birthday Unknown
Posted by LorenzoGatti on 16 June 2015 - 10:11 AM
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.
Posted by LorenzoGatti on 13 June 2015 - 08:40 AM
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.
Posted by LorenzoGatti on 08 June 2015 - 03:16 AM
A nice advantage of passing around pointers is that you can improve encapsulation by using pointers to the right thing instead of giving excessive access to global data structures and unneeded dangerous functions. For example:
- A piece of a scene graph, without access to its parent(s), rather than the whole world.
- When visiting game entities in order to render them you can pass around, and append to, passive collections of things to draw (e.g. managed vertex buffers) rather than a "Graphics API interface that makes draw calls"
- When loading resources, you might be able to use objects that represent one resource and bury in their inaccessible implementation references to global variables representing a registry of what resources are loaded or not and other delicate mechanisms like spawning threads to load resources and concurrency control.
Posted by LorenzoGatti on 03 May 2015 - 06:02 AM
Maybe like this: you research (progress) better lasers and all ships are auto upgraded with these (+1, +2, +3), same for armour, reactor, shields, scanners, basic computers.
Not so fast. Upgrading all ships can be too expensive because resources are insufficient, not the best way to spend resources (for example, the player might prefer to build more ships) and even wasteful (for example, some ship classes might already have excessive firepower). Individual ships or fleets might also have a higher priority (closer to going into battle, outclassed by enemy fleets, etc.)
Asking the player what ships should be upgraded seems a good idea.
Assuming upgrades are desired, being able to perform them isn't trivial: some might be within the means of on-board workshops and maintenance crews (which only large enough ships would have), some would require transport from distant factories and/or dismantling major ship systems in a dry dock, causing a lot of travel. What sort of upgrade logistics complications could be fun?
Posted by LorenzoGatti on 20 April 2015 - 08:42 AM
If your "hulls" are a combination of useful payload space, engines and main weapons, they are still a bit complex, and having 20 or more is not surprising. Maybe some more differences could become upgrades and optional systems rather than intrinsic hull features; upgrades drastically reduce hull obsolescence.
On the other hand, multiple "designs" (e.g. low-performance inexpensive cruiser for blockades and incredibly well armed fast cruiser for planetary assault) would share the same hull.
Example: Star Trek Federation large ships, with their traditional saucer and warp nacelles design.
Constitution class (the TOS Enterprise) and the much newer Intrepid class (the Voyager) are about the same size and shape and they could therefore be the same "hull", even if the latter has more advanced engines, weapons, computers and everything else. Different hull shapes and arrangements are likely to be insignificant, and other classes of similar size and role, like those that are similar to the Enterprise with 1, 3 or 4 warp nacelles, are presumably similar enough too.
On the other hand the Galaxy class (the main TNG Enterprise) is about twice as large, enough to be treated as a different hull with more cargo capacity.
Important Star Trek ships tend to be destroyed or fade into oblivion, but rebuilding would allow them to be updated to new technology; typical Star trek rebuilds would include experimental weapons, faster warp drives, fancy computers, better sensors.
Posted by LorenzoGatti on 17 April 2015 - 03:37 AM
You don't need casting, because you don't actually need access to AndroidImage internals: you need a more complete separation between the generic and Android-specific parts of your code. Only Android-specific classes should be allowed to have variables with Android-specific types, while generic code like an uploadImage() function should be restricted to using Image, GIContext, etc. You probably need to add something to the abstract interfaces like Image.
The sort of situation where I would use dynamic_cast is where I'm using abstract classes for portability. For example I might have an abstract class called Image and a GlContext class with a pure virtual method uploadImage(Image *), and subclasses with implementations for SDL2 and Android (not using SDL2 for Android is another story). In the Android build all Image objects would be DroidImage and GlContext would always be AndroidGlContext. The implementation of uploadImage needs access to members of AndroidImage which aren't available in the abstract base, so it has to cast.
I've implemented it in a base class Connectable, with derived classes Room and Region. The vectors of neighbours are of type std::vector. However, both Room and Region also need to do other Room-specific and Region-specific things with their neighbours, and it's better to reuse the vectors available in the base class and cast the members from Connectable to Rom or Region as appropriate than to maintain separate vectors of the subclass.
This is just a bad design; a Connectable interface doesn't make sense, because you are always connecting regions, which are aggregates of rooms, and some regions are allowed more than one outgoing door.
Posted by LorenzoGatti on 16 April 2015 - 05:18 AM
What periodic signal or function are you trying to interpolate or resample in a mesh processing tool? Vertices, edges and faces are discrete; even if you want to subdivide the mesh the appropriate techniques involve interpolation schemes from a local neighbourhood of vertices, with no concern for symmetry.
Posted by LorenzoGatti on 16 April 2015 - 04:55 AM
However, I'm making a game that is about using strategic gambits to win a worldwide competition. That would require role-playing.
We're coming to a point. If this is the main feature of your design, focus on it.
- What about the worldwide competition itself? is it a form of ritualized war, a very important sport (like ancient Olympics), something that important characters do but isn't really important itself (like the martial arts tournaments in Dragonball), a "gamification" of a real quest to fetch actually important objects, or something else? One way or the other, it has to matter, or it won't be the equal of more commonplace character-growth or save-the-world heroic plots.
- What are "strategic gambits"? Start from elementary player moves, and find ways to build clever plans out of them.
- Choosing the right answers in a dialogue tree is a puzzle, not role-playing. Indeed, Building a fairly arbitrary party of contestants, as opposed to being given some specific plot-ingrained characters, makes the characters generic and faceless.
- Look at game mechanics from the point of view of the competition. For example, do you have combat (presumably not at all lethal) against the other contestants, which are the PC party's equals, or combat (presumably unequal and lethal) against a variety of enemies and guardians? Very different combat rules are needed in each case.
Posted by LorenzoGatti on 06 April 2015 - 12:14 PM
I suggest aiming the procedural generation significantly above the level of single rooms, defining building types with a standard layout. Assuming that you have good rules to decide what building type should go into each vacant lot, you need to adapt buildings to the available surroundings:
- stretch standard rooms which have a flexible size
- add extra rooms to fill large spaces (usually making other rooms smaller)
- merge walls with adjacent buildings
- surround the exterior with alleys, courtyards, gardens etc. when this building or adjacent ones need some space
- choose basic floorplans of room clusters according to multiple choices to add variety
Respecting very strict building structure rules ensures that the building makes sense: no room is too large or too small for its purpose, you know what rooms are (allowing for easy procedural furniture generation), every building has the rooms it needs in a reasonable arrangement.
For example, a traditional Roman domus would have a flexible but almost square aspect ratio (let's say below 3:1), a rectangular shape (possibly, but rarely, with small indentations), a street-facing short side with an entrance in the middle, a passage into a rectangular half-covered atrium with an impluvium in the middle, pretty arbitrary arrangements of wall-to-wall rooms around the courtyard, normally a cloister and small garden in the back surrounded by other rooms, few or no corridors, few outward-facing windows and even fewer back and side doors, some traditional room types, etc.
Posted by LorenzoGatti on 30 March 2015 - 01:54 AM
The idea of giving each card "100 stat points" implies that all cards have the same type: for example, all cards are creatures that can be sent into battle with other creatures.
This should not be the case: a more complex game should have vastly different and incommensurable card types. For example, along with minor types, Yu-Gi-Oh has monsters and "traps", Magic: the Gathering has permanents (including creatures and other types of useful things) and two (formerly three) types of one-shot spells, and many games have "resource" cards that are necessary but usually don't do much, like lands in M:tG, energy in Pokémon, stones in Force of Will, etc.
Varied cards allow for more complex strategies, which would be compared against each other on more abstract grounds: how many turns and how many cards to win, how easily can the plan be disrupted, what popular/likely deck types are strong or weak against this deck, and so on.
Even within a single card type there's ample room for strong and weak cards.
A typical pattern, common in M:tG, is that powerful cards cost more to play and there's a tradeoff between playing big spells to amortize the cost of spending a card by having that card do more, and playing cheap spells to make an impact in the early turns; M:tG deck design usually consists of fitting the most suitable cards to a list of how many cards there should be at a given cost.
Another pattern is using weak cards as a stepping stone towards playing strong cards; for example, many great monsters in Yu-Gi-Oh are played faster or exclusively by assembling, replacing, sacrificing etc.the appropriate entry-level monsters.
Posted by LorenzoGatti on 27 March 2015 - 09:02 AM
I think, going into direction of "even more smart" is pointless... Even if I manage to fix it and make it work, is it really fun? This Spock like strategy
Maybe go somewhere into realm of emotions? AI being afraid, hating someone, wanting to take revenge...
As a quick fix I guess I will make some sort of "tired" counter, it increases each turn you fight over that planet (and decreases slowly over time). If you are too tired fighting over a certain planet (reach certain thereshold) it gets desirablity halved/nullified. With exceptions, like you never will get tired defending your homeworld
Smart & cowardly races would have that thereshold lower (quicker to back off), which adds personality to aliens I guess.
An alternative approach, which depends strongly on game rules (fleet movement has to take enough turns): send a reasonably sized fleet to the very good planet, but reroute it to another nearby objective (or to retreat in extreme cases) if the good planet is too well defended, or expected to be when the fleet arrives. This way every fleet fights against appropriately small defenses, or retreats with little harm, instead of suffering unusual losses.
In case two large invasion forces meet, instead of mutually annihilating for the benefit of all other factions they would stop, conquer what they can from neutral parties and other sides, and gradually send away excess ships from places they don't want to fight at.
Posted by LorenzoGatti on 26 March 2015 - 02:58 AM
The AI should consider the expected cost of conquering planets and the expected loss of leaving planets undefended and use, for example, a randomized strategy. If planet A is worth 50 and, being under attack by someone else, costs 40 to conquer right now, undefended planet B that is worth 20 and costs 10 to conquer is equally good and it should be chosen as an invasion attempt target with the same probability as planet A, or more often (possibly always) because planet A is an excessive commitment of limited armed forces.
Posted by LorenzoGatti on 25 March 2015 - 07:44 AM
With the premise of a teenager who's particularly gifted with some special power and leaves family to be trained and/or to use it, the most important element is the teenager's attitude, for which there are many traditional patterns:
- Harry Potter has inherited a war, and he prepares for ending it with an heroic, self-destructive showdown; given his low power level he needs many allies and intermediate steps, and he doesn't make any significant plans about growing up and fitting into society.
- The male protagonist in Infinite Stratos is just an idiot; although much more exceptional than Harry Potter, his only discernible purpose is being a decent student, which only incidentally involves fighting in earnest during a few emergencies. (Compare and contrast with Harry Potter's many genuine enemies, duels, murder attempts, etc.)
What's "special" is the school itself: an academy for gifted pilots of T&A combat mecha is certainly more spectacular than, say, an academy for gifted fashion designers.
- Naruto appears focused on developing into a powerful and mature ninja, and caring for his companions and his quests and missions is a large part of this lifestyle.
How much he's gifted and exceptional has only a relative importance, since most of his challenges are about insight and force of will, not about power.
- In Kill la Kill the main characters are very powerful from the outset, the protagonist begins as a lonely transhuman orphan with a mission and becomes progressively more normal, and plot advances mostly by revealing secrets, increasing power and raising the stakes.
There's so little training and so little character formation compared to the development of strong ties between characters that it should be considered a borderline example of the genre.
- In Gunbuster, Mobile Suit Gundam and many other similar series, protagonists aren't particularly special, but merely skilled; they are placed in tough responsibility positions by necessity or by coincidence, which naturally leads to themes like disgust for war and violence, accepting risks and sacrifices, occasionally drifting into madness, etc.