Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


LorenzoGatti

Member Since 25 Nov 2005
Offline Last Active Today, 02:21 AM

#5241477 guns, ships and space combat :)

Posted by LorenzoGatti on 20 July 2015 - 02:54 AM

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.




#5238135 Why platform games now focus on unlimited lives?

Posted by LorenzoGatti on 03 July 2015 - 01:41 AM

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.  




#5237092 Roguelike game with static map

Posted by LorenzoGatti on 27 June 2015 - 08:08 AM


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).




#5236281 Level design of a "Roguelike" set in outer space

Posted by LorenzoGatti on 23 June 2015 - 01:38 AM

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.




#5235140 Easy source control for educational uses?

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.




#5234600 C# becoming obsolete ?

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.




#5233497 Engine design, global interfaces

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.



#5226933 Equipment/modules for ships

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?




#5224495 Equipment/modules for ships

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.




#5223904 Is C++ RTTI good or bad?

Posted by LorenzoGatti on 17 April 2015 - 03:37 AM


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.
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.


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.




#5223641 Can i do this using the fourier transform?

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.




#5223638 RPG Mechanics

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.



#5221842 Procedural maps, building interiors

Posted by LorenzoGatti on 07 April 2015 - 08:16 AM

An article from Siggraph 2014 discusses adaptable building templates (fitted to slightly irregular and non-rectilinear quad meshes). Doing the same on a tile-based map wouldn't be trivial, but it's a starting point.




#5221662 Procedural maps, building interiors

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.




#5220123 tcg card design method validation question

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.






PARTNERS