Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 25 Nov 2005
Offline Last Active Today, 12:52 AM

#5185621 How to implement curved boomerang ?

Posted by on 07 October 2014 - 02:59 PM

You can also apply an heuristic since the beginning of the flight: slightly different paths depending on the player's expected position after a certain time, when the boomerang comes back. Adjusting the endpoint as others have suggested can then take care of the prediction error.

In the simplest case, you can distinguish between walking and standing still; the player can be expected to, respectively, walk in the same direction for a large fraction of the flight time and for a very small fraction of the flight time. In some kinds of platform game you might be able to predict jumping down a ledge, interacting with an obstacle, and other variations.

#5180092 how to balance my game?

Posted by on 13 September 2014 - 12:15 PM

Assuming you are making a FPS-like game with small battles between a few player-driven or AI tanks, you should consider how stats affect combat.

  • If a tank is slightly faster than normal, is it really better than a baseline tank? In which ways, and in which circumstances?
  • Can the environment or the kind of engagement make the advantage useless? For example, the fast tank could pass the whole battle in the same place in a sniper role or stick behind cover without serious movement.
  • Assuming being fast is good, what can you worsen to make the slightly fast tank fair? For example, slower turning can compensate faster straight movement. There's no reason to assume "power" (by the way, what is it?) is the right choice, only because it's the stat you have already designed 
  • As the fast tank becomes faster, what are the qualitative tactical changes? Are they good variations, or boring easy strategies? For example, a ridiculously fast tank would be able to dodge artillery if there's enough room, which could be a good thing if obstacles make dodging challenging or a bad thing if nobody ever hits.

#5178817 You're a witch/demon hunter/slayer. You're likely to carry...

Posted by on 08 September 2014 - 03:45 AM

I thought the hunter would be more of a crossbow/axe kind of hybrid, but sword may very well be more efficient.

This sort of consideration needs context:

  • what monsters are being hunted?
  • how do they fight back?
  • what other cases of combat deserve an investment of suitable weapons and related resources?

For example, good crossbow targets are hurt seriously enough by one hit to fall down or, at worst, wander away harmlessly to die elsewhere, while bad crossbow targets are likely to just get angry if hit. Since a bow can be reloaded much faster, it's usually better because the range of good targets includes anything that can be brought down with 2,3 or more hits (depending on how long it takes to fight back), leaving only some niches for the higher power crossbows: extremely long range, armored targets, anything that allows only one shot before reacting very effectively. What kind of armor are witches and demons wearing? How fast are they with magical attacks and movement?


Another example: melee weapons and defensive equipment. An axe might be good to decapitate a vampire in combat, but worse than a wooden staff if the vampire is fast and armed with a rapier. Long polearms might keep creatures of the night at a distance, but not among thick trees and bushes. Heavy steel armor is effective, unless "heat metal" spells like in D&D are common enough to become a standard tactic.

#5177114 How to clearly highlight GUI object regardless of its color

Posted by on 30 August 2014 - 03:00 PM

There is a trick in, I think, one of the Graphics Gems books: drawing an high-contrast overlay on any background by flipping the most significant bit of each colour component of the current frame buffer colour. (Yes, it could be done in OpenGL.1.0/2.0 without shaders.) Increasing or decreasing each colour component by half the maximum value provides more than enough contrast with adjacent unaltered pixels.


This technique might look bad with unpleasant frontiers between high and low values (slightly noisy backgrounds with components around half amplitude explode into spotted patterns) or simply because the overlay echoes the same texture as the background.


If you can afford to prepare graphics more carefully you might simply draw something normally, fully opaque, with a double outline: one dark and one light. The contrasting outlines can't both be confused with the background, and they form a high-contrast edge between them. A double outline can often be simplified to a dark outline with a light fill or vice versa, particularly in the case of text in solid colours.

#5176611 4x space combat with low loses and control of territory

Posted by on 28 August 2014 - 01:21 AM

I'm not sure what you meant by "you simply don't have many void map sectors because nobody goes too far from planets"?

A sector without planets or stations is only important as an intermediate location along the path between important places, and if you have "starlanes" most travel will not involve the empty space between planets or stars, so adding huge numbers of empty map sectors to represent it is a confusing and pointless complication. The only empty sectors should be the ones that can be reasonably travelled through and the ones that adjust the topology of the sector graph (for example, what sectors need to be occupied to blockade what other sectors).

#5176374 4x space combat with low loses and control of territory

Posted by on 27 August 2014 - 01:31 AM

I can't use it for my project (no sectors, just planets with starlanes) but I can't resist pursuing this concept biggrin.png I always loved sectors.
Each planet neighbourhood can be a map sector; if they are too complex they can be split into a few parts (Solar system example: assuming extensive colonization making Moon interesting, treat Earth and Moon as two adjacent sectors rather than one).

With a setup of planets and "starlanes" you simply don't have many void map sectors because nobody goes too far from planets; void sectors might be present in strategically important locations within a star system (e.g. the Solar System could have sectors for each planet, important satellites and asteroids, the sun and two empty ones "above" and "below" the orbital planes).

To rephrase what you wrote. The map is divided into squares, each consisting of several planets/systems/asteroid belts/satelites/orbital basaes/etc. Fleets are placed in a sector, then they take a position on one spacial body they occupy. There are no disctances within a sector, all fleets can engange any unit within system.

No, not squares. Sector shapes are irrelevant and effectively nonexistent, sector sizes are vague and easily fudged, and particularly with arbitrary long-range links, the graph structure of sector adjacency is going to be arbitrary and likely not planar.

The problem I see is stopping enemies. Like, if you move a fleet to a sector (just moe them into space, no planet targetted), then enemy targets your fleet, but you gave an order to move to the next sector, so at the end of turn the enemy has invalid target (you are not there anymore) and you moved to another sector, effectivelly passing through the enemy lines.

Actually, I suggested that a fleet can only exit a sector if nobody attacks them; I'm afraid I didn't make the assumption of simultaneous turns (orders for each fleet, battles of fleets attacking each other or converging to a location, planetary assaults, and finally splitting and coalescing surviving fleets) sufficiently clear.

If your fleet wants to stop an enemy fleet and they are in the same sector, just attack them every turn and they won't go anywhere, except perhaps taking the battle to planets or stations of that sector they want to conquer or hold.

#5175947 Suggestions in Finding an Interesting Game Ideas

Posted by on 25 August 2014 - 02:00 AM

I believe you should make games you enjoy, if you don't enjoy them then how else will another player like it? I believe every game developer should make games they would enjoy playing and want to play.

This is the right attitude, and there is a further advantage to following your tastes: you are an expert of the kind of games you enjoy playing.

Experience and familiarity put many bad or wrong or too trivial game designs out of the question, saving you a lot of mistakes; on the contrary you might find genres you don't like too unpleasant or too alien to work in.
For example, I understand the graphical principles of aligning and layering images for dress-up doll games, but I'm not enough of a fashion designer to know what to draw. 

#5175672 4x space combat with low loses and control of territory

Posted by on 23 August 2014 - 12:05 PM

A defining feature of space is its vastness: any number of starships, with several orders of magnitudes of margin beyond the expected maximum number of ships in the whole game, should be able to occupy a map sector without being engaged in combat.

Combined with the preference for "starlanes" (suggesting that everyone hangs around their endpoints as much as possible) and the desire for protracted combat, the possibility of coexisting with the enemy in the same location suggests rules in which engaging the enemy is an optional and often deliberately delayed action, and choosing where to put reinforcements and who/what deserves attacking are the main strategic elements.

  • Every map sector contains any number of mobile fleets and stationary planets and stations of any faction. Newly built ships join a fleet in their sector at the end of the turn and can move the following turn.
    Sector size can vary from most empty and a few with one planet or station, to planetary neighbourhoods encompassing satellites and Lagrangian points, to whole solar systems; something important to vary and tweak for tactical and strategic purposes. 
  • Movement speed: In a turn, a fleet can attack any enemy fleet in the same sector (or merge with a friendly one), or go to a planet or station. Fleets can split freely at the end of the turn (to show the resulting new fleets when the enemy selects moves next turn).
  • Fleet combat takes place after movement; it can be assumed that all fleets who go to the same place or approach the same fleet arrive together. With suitable cultural excuses (prudence, chivalry, expending limited fuel or ammo, etc.) the normal outcome is that both factions retreat after modest damage, it doesn't matter where. Next turn they'll go anywhere in the sector all over again.
  • When a fleet goes to an enemy planet or station, they first engage enemy fleets who went there (and those who went after them); if attackers are successful enough, as an exception to the rule of always retreating, they remain, forcing the defenders away, and attack the objective in the same turn.
  • "Long-distance" movement: a fleet shouldn't go further than to an adjacent sector in a turn, and only if no enemy fleet attacks them. On the following turn, they are in the other sector.
    Spending additional turns in wormholes, warp speed, or whatever you want to call states in which the fleet is traveling and cannot attack or be attacked can be an option.
    Slow movement enables bluffs; fast movement wouldn't require a player to commit its forces to a specific place. Slow movement on a large map can be made more agile with some kind of shortcut between ordinarily distant sectors.

#5175427 how to go about implementing sub-region rendering?

Posted by on 22 August 2014 - 01:44 AM

If we are talking about a game, the whole screen is redrawn every frame.

Otherwise you need to be more specific as to your goals.

What remains provably constant between frames is usually a bezel or a background image, and rendering this kind of thing is a large but dirt cheap blitting operation.

Everything else has a chance to remain constant (e.g. entering a pause mode, perfect immobility) but ordinarily there is no reason for optimizations:

  • Your performance target is being able to draw all objects to the whole screen every frame: making a "lucky" case.cheaper is pointless.
    Instead, drawing performance is improved by reducing the worst case number and cost of draw calls regardless of what changes from frame to frame (for instance, limiting the number of game entities in the game rules to limit drawn objects).
  • Tracking regions where you aren't going to draw anything does little good: you are drawing objects, not screen regions, and a small dirty region means that the objects are concentrating the same amount of drawing effort into a smaller part of the frame buffer, which might or might not be good for performance.
    Instead, you should cull objects to do less work, but culling criteria include importance, visibility and the like, not screen-space location.

#5174944 You're a witch/demon hunter/slayer. You're likely to carry...

Posted by on 20 August 2014 - 01:51 AM

Wai gives a good list of equipment functional categories, but most of them should be further broken down into specialist gear for monster hunters and generic adventuring gear everybody uses, because monster hunting is an additional occupation layered on standard adventuring hazards and concerns. For example, in a typical wilderness region everybody's "assault gear" should include a reliable way to hurt (but preferably not kill) a wolf or a bear, while in the appropriate environments basic camping equipment includes locust-proof tents, leech removal tools or air purification systems regardless of what you are doing there.

You might find out that sensible equipment for monster hunters are variants of regular equipment rather than overspecialized gear: for example, a sword with a silvered blade (as general purpose as it gets, and very effective against certain monsters) instead of a clumsy pistol with silver bullets (equally large and expensive, but usually ineffective).

I wouldn't worry about unexciting or unoriginal gear; hunting and meeting monsters should provide all the excitement, and players care about facing such activities with sufficiently effective and complete equipment.

#5170819 Publish - An open source pipeline tool

Posted by on 01 August 2014 - 01:49 AM

The normal way to perform these checks is a tool plugin, e.g. hooked to asset export. Such scripts are going to be very specific to certain asset categories, limited to one project (but possibly easy to recycle and adapt), continually evolving, and integrated with databases and asset pipelines on their own terms: only basic building blocks (e.g. verifying that an alleged manifold mesh has consistent normals) and reporting infrastructure are plausibly useful products.

#5170812 Any interest in reverse engineering .unitypackage files?

Posted by on 01 August 2014 - 01:25 AM

Not much article potential, what can you say about these Unity archives beyond the information in Frob's answer?

#5170271 Exploration in space 4X (boring & tedious)

Posted by on 30 July 2014 - 04:47 AM

Why "scout" ships? Hundreds of Star Trek episodes have proved that even a very powerful flagship like the USS Enterprise can be seriously challenged by "routine" exploration and search missions: a state of the art expensive and very strong ship should be the bare minimum for venturing in unexplored or dangerous space, with powerful groups of ships preferable and cheap small ships completely out of the question except as the numerous payload of an aircraft carrier.


Reasonable (and fun) exploration should consist of going there and kicking ass, conquering new territories and clearing them of threats; probes and instruments are a small addition to a primarily military activity. The difference with a military campaign is that exploration happens in "wild" places rather than in well known places that belong to the enemy.

Long range sensors can give a good indication of where to send the exploration duty fleets (or what important planets are going to be fought over when the enemy reaches them too) without yielding anything concretely useful.

#5170257 How to invent names (theory)?

Posted by on 30 July 2014 - 02:34 AM

Actually what you want is to choose some restrictions for yourself.

Naming is peculiar because restrictions are, more importantly than starting points for creativity as usual, systems that provide important information directly. Spelling and family names tell the ethnic and geographical origin of people, while first names hint at the age of persons and the culture of their parents. For example, the lists of names in film credits are usually sufficient to guess where every special effects firm is located.


Names reflect important social, historical and cultural structures: invent them, and appropriate names will be easy to deduce. For example, using more or less reference languages for the names in a fantasy world depends on the presence of different nations or merely different lords and tribes sharing a common culture, while religious references correspond to the diffusion of different religions (and are absent, or too common to be significant, if nobody cares to make a religious statement).

A distinction should be made between choosing consistent but often arbitrary naming rules (e.g. kingdom A has French names, kingdom B has Dutch names, kingdom C has Swedish names; religion X has personal names from animals and plants and objects, religion Y has a small set of peculiar personal names in a very exotic language) and modulating them according to standard realistic patterns (e.g. in the contested regions around kingdom borders there are substantial numbers of personal names from both languages, while places have one name in each language and the official one is switched according to current ownership).

#5169677 Adding some variation to AI

Posted by on 28 July 2014 - 01:21 AM

What behavioural similarities are considered bad isn't completely clear.


Shooting simultaneously is a consequence of starting synchronized and being able to shoot at any time. Random delays break up the synchronization, but you can experiment with obstacles, concealment and lack of targets to make every unit shoot only when it can hit: when the enemy walks into the line of fire (and simultaneous fire makes sense), when they turn a corner (one at a time), when they randomly decide to pop out of their cover (according to the stochastic criteria suggested in previous posts), etc.


Generally "doing the same thing", on the other hand, should be addressed with multiple-unit coordination. For example, an infantry platoon or the like could, among many other things that can be modeled and executed in relatively simple ways, split into two halves that cover each other's advance or spread into a very long line to minimize the effect of enemy grenades: you would have two clearly different groups even if the constituting soldiers simply walk and shoot like any other soldier.