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!


Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Yesterday, 11:12 PM

#5226971 Looking for some sample Direct3D Worlds/Scenes?

Posted by Norman Barrows on 03 May 2015 - 10:22 AM

i usually go someplace like:

 

http://tf3dm.com/

 

then use truespace 7.6 and 7.61 to convert to .x

 

a quick count reveals i actually have 39 bookmarked web pages for free 3d models in my browser at the moment, that's just the first one on the list.




#5226968 How To Make An RPG

Posted by Norman Barrows on 03 May 2015 - 10:06 AM


it's RPG (mostly), but i don't know how to make one and how the upgrade tree works and how should i make it fun and other things in RPG games.

 

i've been a player for 38 years, and a ref and DM for 37 years. statements like this make me want to cry.

 

lemme see if i can keep this brief...  i've been thinking of posting a blog entry on the topic....

 

a rpg lets the human player play some role other than themselves. the setting as to location and time period can be anything. real world, or fantasy or imaginary, or the far future or distant past.  as creator of the rpg, its your job to define the rules of the "universe" you're going to simulate for the player to role play in.  thus the reference to paper and pencil rules and a d20. levels, power ups, storyline, queist, and all those other stereotypes associated with rpg's are different designers takes on the "rules" for their universes. IE its how they model and simulate their game world. or at least it supposed to be. nowadays, folks don't undertsnd this, and think RPG rules are a well defined set f game mechanics, the way RTS's have "build building and units and destroy the other guys building and units", and side scrollers have "jump and shoot". unlike RTSs, side scrollers, tetris, etc, RPGs are not a set of game mechanics that it has been discovered makes for good entertainment. they are various attempts to model a game world. think in terms of how rpgs you are familiar with model this or that in the game. how do they model combat? experience? skills? and so on. don't think you can just pick game mechanics x,y,z,and w, and boom, i've got a fun RPG.




#5224193 What language is this made in?

Posted by Norman Barrows on 18 April 2015 - 11:43 AM


I'm comfortable in c and c++

...

but I wasn't sure if that was possible using these languages.

 

any game can be made with C++.  its probably the only language that can claim that (other than assembly perhaps). other languages tend to have issues that make them unsuitable for particular types of games.




#5224163 Equipment/modules for ships

Posted by Norman Barrows on 18 April 2015 - 08:03 AM


Actually that's not a bad mechanic for the game? You could forcibly jerry-rig a new type of equipment into an old frame (e.g. field modification without proper retrofit at the shipyard) but there is an increasing chance of catastrophic failure on use, destroying both the ship and all its components (probability dependent on age gap between the component and it's ship)... Ouch.

 

your talking about the modeling the ability to tell "Scotty" to jury rig something.

 

of course "repairs at sea" should be modeled! and of course your engineer's skill should affect outcome!

 

Don't think in terms of game mechanics, think in terms of what you want to simulate in your game world.




#5223957 Equipment/modules for ships

Posted by Norman Barrows on 17 April 2015 - 07:25 AM

be careful how much you sacrifice realism for simplicity.

 

an un-realistic game mechanic can be just as much of a turnoff as an overly complex game mechanic. perhaps even moreso: with a complex mechanic, it might be kludgey yet realistic. with an oversimplified mechanic it might turn out to just be silly or stupid.

 

in the real world, ships have space (slots). pretty much anything can go in any hull, assuming there is enough free space (unused slots). 

 

systems are researched and developed, which takes time and money. and usually a lot more time than modeled in games (that's -1 point for games, for lack of realism: bad designer! no twinkie!).

 

ships are refitted at shipyards.

 

refits take time and money.

 

performance is a function of engine size and ship mass - hull type is irrelevant.

 

 

 

 

all this can be automated.

 

 

 

 

the computer can decide for the player what to research.

 

ships can automatically refit when at a shipyard.

 

the PC can decide what type of ships to build.

 

at that point you have a fully automated realistic system. but with zero user control.

 

 

 

 

so add in a bit of user control, but not so much that things get too complicated.

 

 

 

 

let them decide what general areas to research (offense / defense / surveillance ). or more complex: what systems to research.

 

let them give general guidance as to what type of ships to build. or more complex: specific ship classes and numbers to build.

 

let them turn auto-refits on/off, in case they need a ship right away and can't wait six weeks while its in the yard getting a refit, or in case they are running low on money, and need to hold off on refits for a while.  or more complex: optional refit on a ship by ship basis when they reach a shipyard.

 

 

 

often the best approach is a high level + low level approach. provide both a high level UI  with basic controls, and a low level UI for micro-managing stuff if desired. Total War uses this in may of their titles for settlement management (tax rates, what to build, etc).  A similar concept is the Hearth fire add-on for Skyrim. At the high level you can hire a steward and simply tell them to buy stuff and furnish the house (furnish this room, buy a horse, etc). At the low level you can go hunt the animal yourself, forge the nails, and make your own stuffed head mounted on the wall. 




#5223943 Illumination by a lake of lava

Posted by Norman Barrows on 17 April 2015 - 06:23 AM


if I create random lakes of lava in my voxel game and want them to light their environments, how can I do this?

 

by creating an imaginary world. in the real world, lava lakes don't give off much light (ever been to Kilauea?). try a low emmissive material for a realistic look.




#5223427 The best place to find research papers

Posted by Norman Barrows on 15 April 2015 - 08:40 AM

As a former IEEE SIGGRAPH member, i can definitely say that if its cutting edge, graphics, and published, odds are you'll see it in SIGGRAPH.

 

HOWEVER - as mentioned above, there's a lot of "academic" vs "real world" papers out there with respect to games.  Its usually been my experience that most academic papers have NO CLUE about building games, usually erring on the side of ridiculous amounts of overkill in the algos chosen.

 

white papers are nice, but always remember the K.I.S.S. principle of good engineering design, and read them with a grain of salt.




#5222617 Is this C code using pointers valid?

Posted by Norman Barrows on 11 April 2015 - 10:44 AM


7. document the list generating subroutine so its CLEAR it allocates memory that the coder must track and free manually.

 

you might even want to call your list generating routine something like:

 

create_server_list(*list,*result)

 

and write an explicit matching free routine:

 

free_server_list(*list)

 

which would just call free(*list).

 

that way your API has explicit create() and free() routines, making it more clear that your are creating and destroying a data structure on the heap.




#5222616 Is this C code using pointers valid?

Posted by Norman Barrows on 11 April 2015 - 10:37 AM

i'd suggest the following algo:

 

1. do a pass and get a count of servers

2. malloc the ram for the list

3. do a second pass to populate the list

4. return a pointer to the list

5. perhaps use a separate result parameter for sending back error results (empty list, out of ram, other errors)

6. main() frees the pointer when done.

7. document the list generating subroutine so its CLEAR it allocates memory that the coder must track and free manually.

8. use array notation where possible for clarity.

 

when doing dynamic memory allocations, you want to keep them as simple and infrequent as possible, with either minimum or maximum scope.

 

minimum scope for temporary stuff. never keep ram allocated or a file open any longer than necessary - it cuts down on potential problems.

 

maximum scope for "global" stuff so you are almost always assured that at any point in the code the pointer is valid, and its easy to remember where its not (like program startup and shutdown).  this can cut down on or eliminate the need for runtime checks for valid pointers.

 

things like this can simplify life with pointers.




#5222598 First person wall sliding, what am I missing?

Posted by Norman Barrows on 11 April 2015 - 07:37 AM

http://www.gamedev.net/blog/1729/entry-2260768-simple-sliding-collisions/




#5222387 Frank luna, introduction to 3d game programming with directx 11

Posted by Norman Barrows on 10 April 2015 - 04:56 AM

what _specifically_ don't you understand?

 

what output do you get?

 

can you post a screen shot?

 

can you post a code snippet? (if you've written one).




#5221143 How do you stop your game from being stolen/torrented?

Posted by Norman Barrows on 03 April 2015 - 11:12 AM

FYI one of the entries in one of my dev journals here has a lot of info on DRM and anti-crack technology

 

http://www.gamedev.net/blog/1729/entry-2258666-anti-crack-info/

 

http://www.gamedev.net/blog/1729/entry-2258667-gamedev-tycoon-vs-crackers/




#5221140 How do you stop your game from being stolen/torrented?

Posted by Norman Barrows on 03 April 2015 - 11:00 AM

more thoughts:

 

there's 2 parts to piracy

1. cracking DRM

2. illegal re-distribution of non-DRM protected software - either software that has no DRM to begin with (such as Only if) or has been cracked (like Caveman v1.3) .

 

there exists in the world an engineering hobby / discipline called "cracking". its about reverse-engineering and modifying games.  the payoff for crackers is posting their work so the world can see how awesome they are.

 

if you eliminate the payoff for crackers, you don't get cracked.

 

so open source, free games etc don't get cracked,

 

ALSO - limited DEMOs that don't include the full game don't get cracked!

 

the recurring theme here is "there's nothing to crack - no glory".

 

prior to Caveman v1.3, i only used limited demos, and keydisk DRM.  these was nothing to crack in the online demos, and the keydisk meant any upload was no good, and no cracker will buy a game to crack it, as there are too may free games to play around with. so i was safe.

 

I didn't become a target for piracy until i went to a demo that could be cracked to turn it into the full game.

 

so then they had something to crack - a  challenge!

 

so once your DRM is removed by cracking, then they post the results to get their profs from their peers (other crackers).

 

now comes into play the second part of piracy: illegal re-distribution of non-drm protected software.

 

basically you'll have two types of folks who will download a cracked game:

1. folks who know its a cracked game. they may want to try it but there's no playable demo. they may not be able to afford it in the first place - so they're not a potential customer anyway.

2. folks who don't know its cracked. they just think its a cool game and have no idea they are receiving ":stolen" goods. these are lost sales.

 

at the end of the day, if someone likes the game, they will buy it (if they can afford it), but first they must realize its not free, and second its very difficult to sell something to someone who already has one (such as a full (cracked) version of your game on their hard drive). so don't rely on potential customers playing cracked versions, then buying the legit version as "the right thing to do". 

 

when implementing anti-crack technology, as mentioned above, how you respond to detected cracking can leave the impression that your game is buggy. especially if the player doesn't know its cracked. of course, by then its too late, cause you've already been cracked.

 

in the end it becomes an arms race. you release with drm, they crack it. you release with new drm, and new features to give the users a reason to buy the new version vs DL'ing the cracked current version.  then they crack the new version, and the cycle begins again. the idea with this approach is your drm should hold up long enough for you to get a new version ready. this approach is very common with small business app devs.

 

the only real solution is "nothing to crack - thus no glory - on to the next game"

 

limited demos, free games, DRM on full version to prevent customers from simply posting it, "ET phone home" (server side authentication of users), streaming code from servers - all these approaches leave nothing to crack, or prevent/deter illegal re-distribution of unprotected code.

 

a limited playable demo and some simple DRM on full versions sold is probably the best approach these days.

 

remember its all about the glory - take away their [the cracker's] chance at glory, and you (and more importantly - your game) no longer exist in their universe.




#5221129 for amber waves of grain

Posted by Norman Barrows on 03 April 2015 - 10:02 AM

swaying vegetation - been there done that. sinusoidal based motion. function of wind speed and direction. phase offset based perhaps on a function of world x,z (for global wind sources) etc. etc.

 

now...

 

what about a field of vegetation waving in the breeze, like waves on the ocean?

 

what's a good algo for that?

 

and what about gusty winds? just toss in a little random gusty motion? it _should_ be an area of gusty wind that moves across the game world like in the real world....  coming and going, etc.

 

all this seems to point to modeling swaying vegetation at the individual level, driven by some higher level code that models swaying vegetation/wind effects over large areas.

 

in general, i'm talking about natural wind sources here , not a "wind emitter:" like a helicopter in a game engine.

 

cursory searches here and on google turn up the usual suspects with regard to swaying individual plants, but nothing on area effects of wind on swaying vegetation.

 

as i continue work on Caveman, which is quickly evolving from a RPG into a paleo-world simulation, i'm discovering that good animations are key to bringing the world to life.  to that end, i'd like to try to take my vegetation animations to the next level in this new version of the game, by adding "waves of grain" to simple wind based animation of swaying vegetation.  I suspect the effect would be most dramatic in the game, given the large view distances (i'm now testing at >300 meters at highest LOD), use of high lod at all ranges with no impostors, and the extremely dense vegetation (often > 10K instances visible onscreen at once).

 

how to do that, and how to animate a rigged model in truespace (yes, i'm going to try for skinned meshes!) are about the only two things on the project i haven't figured out yet.

 

 

 

 




#5221119 SetTexture question

Posted by Norman Barrows on 03 April 2015 - 09:33 AM

i use d3d9 fixed function pure device and implement my own state managers for mesh, texture, material, etc.

 

in performance costs, apparently the state changes from most to least expensive are:

1. textures

2. meshes

3. materials

4. projection matrix

5. world matrix

6. other state changes like cull on/off, etc.

 

which means you want sort your render queue on texture, then mesh, then material, then near to far.

 

i use an un-ordered queue supplemented by an indexing system that does an in-order insertion when a renderable is added to the queue.

 

performance from sorting just on texture is so great I don't even bother sorting on mesh, material, or even near to far - at least yet.






PARTNERS