Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 04 Jul 2003
Offline Last Active Yesterday, 11:12 PM

Posts I've Made

In Topic: the dreaded "escort" quest

29 August 2016 - 01:09 PM

An early prototype of goblinson crusoe was "Goblin Wizard: The Escort Quest". In fact, my original vision for GC was as a game centered fully around escort quests. GC was to be an apprentice wizard whose master is suffering from rapidly advancing dementia, charging from adventure to adventure while his hapless student frantically tries to keep him out of danger.

Something I have noticed about escort quests as a result of this experiment is that, in the context of a different game they kinda suck. If I'm raiding a bandit camp, thrashing dudes and looting corpses, then I spring a captive from a cage and have to follow her at snail's pace through a string of scripted ambushes, it's a change of context that is actually kinda painful. But I don't think that really speaks to the escort quest itself being bad, just the juxtaposition of a slower-paced string of ambushes against the gore-splattered free-for-all that preceded it. It's jarring.

What I found in that early prototype of GC is that when approached with the right assumptions and frame of mind, an escort quest (even one of the traditionally 'bad' ones like a slow walker) isn't as bad as you might think. Certainly, my test audience (consisting of friends and family) found it enjoyable. The things such as slow pace and tendency to careen crazily into obvious ambushes were part of the core gameplay rather than a distraction from the core gameplay.

In Topic: Perlin Noise - seamless cube maps

17 August 2016 - 08:48 PM

Your code isn't doing exactly what you expect it to. You'd probably get better results if you divide x and y by dim before you subtract the centroid.

Any box in 3D space is going to map from the coords (x1,y1,z1) to (x2,y2,z2). The mapping ranges for each of the faces will derive from these extents. For example, the back face will map from (x1,y1,z2) to (x2,y2,z2) while the right face will map from (x2,y1,z1) to (x2,y2,z2). And thus, the back and the right faces will share an edge, delineated by the line segment from (x2,y1,z2) to (x2,y2,z2). So, say you have a cube of dim=512. You want to center it at 0, so your cube extents would be (-256,-256,-256) to (256,256,256). However, in your case (assuming image dim=512) you would be mapping from (0,0,1) to (512,512,1) on the back face (before the centroid is subtracted). But the right face maps from (1,0,0) to (1,512,512). The back and right faces in this case don't share an edge.

So you could either divide x and y by dim before subtracting the centroid, so that your cube extents become (0,0,0)->(1,1,1), or you could use dim for the extents so that your cube becomes (0,0,0)->(dim,dim,dim). It doesn't really matter, since you simply normalize the coordinates to unit length.

In Topic: How to make 2D ground more alive/dynamic?

17 August 2016 - 06:10 PM

Fireflies swooping around. Little windblown dust clouds and leaves. Critters in the underbrush. Butterflies. Mice. Even if these things are non interactive, them just being there to add motion to the scene can make a big difference. Also a strong agreement with Prototype on the sound suggestion.

In Topic: Pseudo 3D And Eye Of The Beholder Or Bard's Tale

06 August 2016 - 08:05 PM

I was using C++. Yes the document is confusing, just stick the the part where the author builds the pseudo-3D view. How he slice the images and fit them together to achieve reusability.
While I agree with the comments that "in this day and age, keeping it simple involves using modern hardware, api and engine capabilities", if you just want a simple dungeon crawler, many 3D Engines will overwhelm you with their unnecessary overhead and some 2D libraries such as SFML are quite modern and straightforward to use.

Drawing a view like this essentially requires 2 tasks: determining what to draw and where to draw it. The old methods (as detailed in that document linked earlier) perform the transformations by hand, using obtuse and kludgy rules, in order to determine where on the screen to draw a particular sprite. I've written such systems before, a long time ago. It was confusing, filled with weird edge cases and hacks, and the result was inflexible. The other way to do it is to feed some geometry and a view transformation matrix to a 3D API, and let the hardware perform the translation according to well-understood and well-defined math. It's far simpler that way. I read the document, and even taking into account the fact the author is clearly not a native English speaker, the algorithm outlined is the very definition of obtuse. I would be hard-pressed to recommend such a method to anyone at all. Although breaking the ice with 3D engines can take a bit of a learning curve, it has the advantages of: far better performance than the outlined technique, with a potentially far greater field of view; more flexibility in camera positioning; more flexibility in wall shape, structure and placement without compounding the complexity of the rendering loop (ie, curved walls, half walls, animated walls, etc.); fewer constraints on the view (ie, can look up, down, etc...), again without compounding the complexity of the rendering loop; 3 dimensional movement and level layout; and so on. The benefits of using a full 3D API are myriad; I am at a loss to think of a single benefit stemming from faking it.

If it is a question of style, you can still use the cartoony, hand-drawn sprite style. It's just that using a modern API VASTLY simplifies the math involved in drawing the view.

In Topic: Pseudo 3D And Eye Of The Beholder Or Bard's Tale

05 August 2016 - 01:11 AM

Just go 3D. In this day and age, "keeping it simple" involves using modern hardware, api and engine capabilities, rather than revisiting old hacks that were originally intended to circumvent hardware limitations. You can use modern 3d apis and still mimic the old visual style.