Jump to content

  • Log In with Google      Sign In   
  • Create Account

LorenzoGatti

Member Since 25 Nov 2005
Offline Last Active Today, 03:35 AM

#5263942 Preventing players leaving the play area where an obvious geographic obstacle...

Posted by LorenzoGatti on 28 November 2015 - 08:08 AM

I second the suggestion of hard and harmless fences (as opposed to venturing into the desert and dying). If players must explore the whole map, they expect it to be not only finite, but not diluted by large amount of useless empty space at the borders.

You just need appropriate warning messages; apart from the previous good suggestions, consider breaking the fourth wall with words (e.g. "Thank God, you have nothing to do in the Desert of Skulls. Maybe in a sequel.") or graphics (e.g. a thick red line on the ground, matching the position of an invisible wall).




#5263695 Randomize small maps for 2D-RPG? Rooms etc

Posted by LorenzoGatti on 26 November 2015 - 08:14 AM

Depending on the environment type, arranging pre-made objects of various sizes in a large empty environment might be simpler and/or more effective than matching edge types of Wang tiles (which are subject to combinatorial explosion, usually causing uncanny regular structures due to not supporting a large part of the plausible edge types). For example:

  • For a JRPG-style village, start with grass and place entrances around the border and prefab houses in the middle, then build pathways between houses, a fence around the whole village, trees or rocks outside the fence, etc.
  • For a city, place horizontal and vertical roads at random positions, then fill each rectangular space between them with a combination of buildings, alleys, empty space, etc. of the appropriate size.
    Irregular slack between buildings can be added to gardens and courtyards and fenced procedurally.
    Adjacent blocks could be merged, removing the intervening road segment, to add variety (very large buildings, parks, squares, etc.) or large blocks could be split into sub-blocks independently, even recursively one road at a time, for a more medieval look.



#5262726 Tower Defence game sans war element

Posted by LorenzoGatti on 19 November 2015 - 04:55 AM

The war theme in tower defense goes hand in hand with the basic TD game mechanic of towers doing something to enemies (mostly shooting them) until they cease to exist, and with the corresponding player feedback of seeing rapidly shrinking health bars and the like. Monitoring enemy health is a necessary performance measure that guides tactical estimates of whether the enemies are being hurt fast enough, tower construction and enhancement and use of special attacks.

 

Destroying enemies wholesale is the key element I'd try replacing, for example with simply stopping or delaying them (which allows player feedback to consist of enemy positions and status markers and timers, without health bars):

  • Perimeter defense against mosquitoes or flies in a summer evening. Towers that create soft forbidden zones (e.g. perfumed candles), directional air blowing to push insects back, lamps to attract them, various types of barriers, and of course many lethal options like spider nets, automated laser arrays, zapping or sucking traps, insect-eating birds and insects, etc.
  • A rather full-contact fantasy sport in which the offense team tries to have one of them go from A to B as fast as possible and the defense team tries to slow them down. Towers and attacks would hurt or daze or knock over enemies to disrupt movement, stop them into place, make them slide (into obstacles or off the road if possible), directly push or teleport them away, etc. Strategy would be about optimizing obstacles and making the enemy team pile up at choke points; a sub-game of attacking and repairing the towers would fit well with a team sport setting (the offense team fields specialists to support a few runners that are meant to reach the goal).



#5261883 Skill point curve

Posted by LorenzoGatti on 13 November 2015 - 05:56 AM

I recommend interpolation between design objectives: at certain points of the game, some reference character "builds" should be both equally strong (unless there's a good reason) and equally expensive. First balance how valuable the stats are; costs will follow. Using a computer allows unlimited complexity of the cost model, without the compromises of tabletop roleplaying games.

For example, suppose character stats are brutality, spellslinging, dexterity and toughness and expected character types are wizard (very high spellslinging, very low brutality), dumb fighter (high brutality and toughness, no spellslinging), technical fighter (high brutality and dexterity, low spellslinging) and ninja/sniper (very high dexterity, medium toughness, low spellslinging). The expected stats (B/S/D/T) of a starting character with 100 character points could be 2/12/4/4 for a wizard, 9/0/6/8 for a dumb fighter, 8/2/7/5 for a technical fighter, 5/2/12/5 for a ninja. Obviously, these values need to be validated by playtesting (including playtesting that weird character types are either as good as standard ones, or inferior for obvious reasons, e.g. insisting on average stats and getting neither a bonus melee attack for high brutality like a fighter or an extra spell package for high spellslinging like a wizard)..

After a while, the characters are supposed to have 600 character points and "normal" characters are expected to improve their stats: 4/18/6/6 for a wizard, 15/0/8/9 for a dumb fighter, 12/3/9/9 for a technical fighter, 7/4/16/7 for a ninja. If, like in this case, the sum of the stats of every character type is almost equal, the cost curve could apply to the total of a character's stats: the first 23 stat points cost 100 character points, the next 10 stat points cost 500 character points. (for example, assuming a quadratic curve, a*SP*SP+b*SP= CP, gives a linear system: a*529+b*23=100 and a*1089+b*33=600).




#5261095 Help with specs for laptop

Posted by LorenzoGatti on 09 November 2015 - 02:50 AM

The choice of 4,8 or 16 GB of memory is a straightforward budgeting problem: what do you plan to run simultaneously?

Real example:

  • 1.5 -2 GB various web browsers (including always open web mail)
  • 1 - 1.5 GB odds and ends
  • C# work:
    • 2-4 GB: one virtual machine with an old Windows version
    • negligible: assorted remote desktop sessions
  • OR Java work:
    • 3.5 GB Eclipse
    • 1 GB Websphere
    • 1 GB (transient) Maven

Clearly, my workload fits tightly in 8 GB. With 16 GB  I could allow Eclipse to use more memory, or run a second separate VM with a different C# development environment in case of need.




#5260483 Need advice on creating a tileset in Game Maker

Posted by LorenzoGatti on 04 November 2015 - 05:48 AM

Super Mario World offers a nice example of the sort of ramps Servant explained. Ripped graphics:

http://www.mfgg.net/index.php?act=resdb&param=02&c=1&id=4226

http://www.spriters-resource.com/snes/smarioworld/sheet/4598/

 

EDIT: Also, an in-depth guide on editing a tileset. http://wayofthepixel.net/index.php?action=profile;area=showposts;u=2826




#5259439 Relation between mines & factories

Posted by LorenzoGatti on 28 October 2015 - 12:03 PM


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.



#5258049 Dealing with collision in hash tables

Posted by LorenzoGatti on 20 October 2015 - 01:31 AM

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.




#5257179 2D Graphics Stencil Buffer

Posted by LorenzoGatti on 14 October 2015 - 02:02 AM

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.




#5257001 Translation and Position terms

Posted by LorenzoGatti on 13 October 2015 - 03:30 AM

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.




#5249136 How to avoid "stacks of doom" in 4X? (Part 2)

Posted by LorenzoGatti on 27 August 2015 - 03:32 AM

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.




#5247637 Turning the ship around...

Posted by LorenzoGatti on 19 August 2015 - 06:10 AM

Common sense suggests studying mechanical engineering (without overly specializing in the oil sector) or something closely related and in demand, and making games as a side project.




#5246154 Isometric combat system suggestions

Posted by LorenzoGatti on 13 August 2015 - 01:31 AM


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




#5245396 Neat Magic System

Posted by LorenzoGatti on 10 August 2015 - 01:59 AM

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.



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






PARTNERS