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!


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

Posts I've Made

In Topic: Design pattern for linking UI events to editor code?

28 July 2015 - 02:49 AM

You might be able to consolidate multiple command objects into the same class (or the same function, using techniques like Julean's template), initialized in different ways.

For example, a AlterBrushCommand class containing all brush parameters as members could be equipped with with chainable setters or something of the sort and used to change any combination (usually only one) of radius, strength, type etc.(e.g. executing new AlterBrushCommand(currentBrush).radius(brushRadiusSlider.currentValue()), new AlterBrushCommand(currentBrush).type(brushTypeSelector.currentValue()), and so on),

In Topic: guns, ships and space combat :)

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.

In Topic: How can L-system detect intersections between two lines

14 July 2015 - 02:46 AM

As kitman20022002 suggests, the problem is finding all intersections between a bunch of line segments faster than the trivial quadratic-time algorithm. You might be able to take advantage of the L-system organization of your line segments by testing intersections hierarchically, between the bounding boxes of L-system pieces, in order to exclude large parts of the search space and apply general algorithms to relatively small subsets of the roads.

In Topic: Why use texture splatting?

10 July 2015 - 01:47 AM

But does this technique not demand a lot of memory? Setting up one texture array with say 64 textures for the entire terrain for indexing is a lot isn't it? 512 MB for 1024x1024 textures by my calculations.


64 1024*1024 entries are an awful lot for terrain surface textures, because with texture splatting and other marginally clever uses of shaders such textures don't need to be much varied: details come from other sources.

One texture for each terrain type, possibly smaller than 1024*1024, with terrain transitions handled by blending and masking without baking special-case textures, is a more reasonable estimate.

In Topic: MIDI in games

07 July 2015 - 08:19 AM

In the Euterpea for Haskell documentation it mentions that you're still using virtual instrument suites to sample the music, which brings you right back to size vs. quality. Also you would be working in Haskell which isn't exactly the most popular language,  that will limit the number of resources available to you.

I mentioned Euterpea because it's a fairly straightforward example of the architecture I would use for a score manipulation system, but the same concepts can be (and have been) easily implemented in any language. For example Python has Mingus, Java has JFugue, and so on. Most of these systems generate or export MIDI because it's useful for a musician, but better integration with a synthesizer is certainly possible.