Jump to content

  • Log In with Google      Sign In   
  • Create Account


Ravyne

Member Since 26 Feb 2007
Offline Last Active Jul 30 2014 10:27 AM
****-

Posts I've Made

In Topic: Textures tear at distance

23 July 2014 - 03:39 PM

Its more detailed than what I can adequately explain in the limited time I have, but you would be wise to go find an article that talks about the distribution of depth values that results from the near and far values you choose. The naive assumption most people make is that you want near to be as near to 0 as possible, and far to be as far away as practical, but IIRC, that generally gives less than optimal results.

 

Also, as vstrakh said, you can change them on the fly as you render different parts of your scene. For example, some games render very far-away objects as a means to enhance the "skybox" (perhaps because the objects are animated, dynamically lit, or are far away but near enough for perspective to matter) and those would probably benefit from a different distribution of depth values. Its also a handy technique in space games, where the distances are great and the space is sparsely populated. In general, the maxim seems to be that this is helpful when you mix very large objects at great distances together in a scene with relatively smaller objects at much smaller distances. I imagine that the borders between level-of-detail transitions might also make a good candidate, but it probably depends on how near or far the borders are.


In Topic: Interactions between game objects in a RPG

23 July 2014 - 02:54 AM

The general solution is that you have events tied to regions of your map -- in a tile-based game with tile-based movement (as opposed to tile-based game with sub-tile or pixel-by-pixel movement) its very easy to just attach events to tiles. Then, depending on the event, when a player "touches" a tile (e.g. tests whether he can enter it), or when a player occupies that tile, the event is triggered. The event could be anything -- it could cause the player damage, it could cause the map to change (e.g. cause a door to open), teleport the player to a different place on the map, cause damage to the player, or kick off a cinematic cut-scene.

 

Often times, the effects of these kinds of events are defined by a script, although its reasonable to implement event functions in normal program code too, if you think its best to avoid the complexity of integrating a scripting solution.

 

If you have sub-tile or pixel-by-pixel movement, or a non-tile-based game, its basically the same concept except you have to define the trigger regions differently and/or think a bit harder about what constitutes "touching" or occupying a region? For example, you might decide that occupying a region means that a single point under the players feet is inside the region (or, effectively, this means that the player is more than 50% inside the region).


In Topic: How to invent names (theory)?

22 July 2014 - 03:58 PM

Also, keep in mind that with things like names of people or places, you're thinking in terms of lineange and legacy, not today. It seems obvious, I suppose, but at least in modern times, the actual people in question are removed from where their name might have come from -- A character might be Sam Baker because his great-great grandfather was a baker, not because he is. If everyone in your world carried the name of their profession that's going to start seeming lame very quickly.

 

Lots of places are named after important people or religious figures -- for example, Columbus Ohio, or San Francisco. Places are also sometimes given names to make their importance clear -- King's Landing in a Song of Ice and Fire, or historically to confuse in some cases -- Greenland is icy and inhospitable, Iceland is nicer, because the Vikings were trying to trick their enemies.

 

Most important though, is being consistent. In A Song of Ice and Fire, Bravos has a sort of Spanish flair, The Dolthraki (Spelling) are sort of Mongols.


In Topic: Patenting an Algorithm?

22 July 2014 - 02:05 PM

Thinking on this a little more -- I think the two primary distinctions between being able to patent a machine and being able to patent software are these: Firstly, a machine is almost always an embodiment of a particular application and therefore meets a sort of minimum bar for specificity, and secondly, at the time patent law was first written, it was clear even to non-technical people that machines could be easily reverse-engineered and duplicated.

 

When software patents began to take root, people who didn't know software tried to draw an analogy to machines and failed to see key differences. The main thing they failed to see is that an algorithm is not like a machine because an algorithm can be used broadly, essentially without modification. In other words, it is decoupled from an application, and therefore loses that necessary specificity.


In Topic: Patenting an Algorithm?

21 July 2014 - 11:35 AM

My own opinion is that 'pure' software patents ought to go away. I would define a 'pure' software patent as one which encodes an algorithm that follows strictly from the intersection of math and of the computer it executes on, and also it would not allow for patents to be granted on the basis of application -- in other words a patent "using X for Y" would not be valid, either X is sufficiently pattentable on its own, or it is not -- whether or not X was applied to a novel problem wouldn't constitute uniqueness.

 

As an example, I don't personally believe that a compression algorithm that follows strictly from math should be patentable, even despite their exceeding cleverness. I see this simply as a side effect of the exploration of math, and I believe that math, once discovered, should not be owned by anyone. However, I believe that a theoretical video compression algorithm that achieved higher perceived visual quality because the algorithm specifically took into account the human visual system should be pattentable. For me, the difference is that integrating a further, specific constraint (rather than opportunity) into the algorithm itself elevates it beyond simple math. There's an additional. non-mechanical observation that's been studied, quantified, and integrated.

 

 

That sort of segues into an example of "using X for Y" that I would prefer to be disallowed. One of the dating websites has a patent on using standard data-mining techniques to find potential matches. Essentially, they claim a patent by labeling the rows and columns of their matrix with things like "likes dogs", instead of using an abstract variable. They would claim that their patent doesn't cover just their specific columns, their weights and their inter-relatedness, but indeed the very idea of labeling the rows and columns with personality traits for the purpose of determining compatibility.

 

Ironically, they have tons of secret sauce -- the additional, non-mechanical observation that's been studied, quantified, and integrated into their algorithm, and that's what I'd have them protect -- via patent, possibly, but perhaps copyright would be sufficient. That's the real value that they've discovered -- relationships like "straight women who like beer, dogs, and movies, statistically, find bearded men more attractive." or whatever. Its the ability to find and integrate those kinds of observations that from the pile of data that gives one dating site and edge over another, not the mechanical process of extracting it using well-known mathematics. To be clear, I don't mean to say that this dating site should instead claim ownership of particular, granular observations, but on the whole. I would probably prefer that this was more of a trade-secret, rather than a patent though.


PARTNERS