Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Yesterday, 01:51 AM

#5290919 How do I measure risk?

Posted by Norman Barrows on 09 May 2016 - 10:32 PM

>>  it still might not give a true picture since corners are being cut here and there


then you are not prototyping everything you should or to the depth/degree you should. prototypes should move you from a state of uncertainty to a state of absolute certainty going forward (at least with respect to that which was tested).


>> So rapid prototyping might as well be developing a full draft prototype, which one can then refactor, refine and rewrite algorithms


you want to test only what you must to determine feasibility - no more - no less.  however its not unheard of for a prototype to become the core code of the final game.


ideally, pen and paper analysis and prototyping when necessary will allow you to choose the correct non-optimized algos for the use case in question so refinement or rewriting is unnecessary - unless you must later optimize - as indicated by profiling. note that this applies to selection of existing algos, not inventing new ones.


>>  and this is close to what I'm currently doing... except its taking too much time than estimated


the longest i've ever allotted to a prototype was a week on three occasions: a realistic airship flight model derived from scratch using the laws of chemistry and physics,

hierarchical A* pathfinding for entities of arbitrary size, and skinned meshes.  nothing else has ever been more than 2-3 days max.  the whole idea is to get exactly the answers you need as quick and dirty as you can - and nothing more.  its a prototype - a testbed - it doesn't have to be release grade code. its just has to work well enough to prove or disprove what you're trying to figure out.  never spend more time on a prototype than you must. if it pans out, you can then refactor, or rewrite, or cleanup the code.  sounds to me like your prototype is too big. if you figured it might take more than a week, odds are you're testing too much at once, or perhaps some things you don't have to. if you figured it should take a week or less, and that time has passed, you should have a reasonable idea of how long til you can get it going.  if you find yourself unable to say how long to test something - you've moved past mere prototyping and into the area of research, where there are no clocks. invention knows no schedule but its own. if this is the case, you're probably misleading yourself if you think you can invent according to some schedule or timetable.  its been tried in the past on projects both large and small, and seldom works. the Apollo moonshot being the last case that comes to mind where they actually managed to invent everything new in the time required. a couple military projects by various nations over the years may qualify as well. 



>> I don't have that luxury of time


to do the estimate or to make the game once you adjust you estimate and see how long it may actually take in reality?  multiplying your best guess by two or five or ten takes almost zero time, so you must mean that the result is a game which may in reality take longer than you can afford to spend. so be it. in that case, the scope of the project is simply too big for you to undertake by yourself with the time you have available. you'll need help to proceed (IE a team), or will need to select a smaller scope project to pursue. such is life in the lone wolf lane.  i could build incredible games with unlimited time, resources, and manpower at my disposal, but i don't have those those, so i build what i can than can be competitive in its category.


>> But I prefer long stretches of day job working and long stretches of project development. That way my focus is full and unbroken during project development phase,


understandable. long uninterrupted stretches of time are the most important thing to a gamedev, especially the lone wolf.  until you can quit you day job for real forever, you'll have to suffer life interfering with your development time.  choose your priorities wisely. having a life and being a successful game entrepreneur are often mutually exclusive activities.


>> Still I do run out of savings (and my wife does her bit to help out anyway). Because the stretches project development tends to go longer I do run out, but its a catch 22 situation


like i said before you need to secure a source of income to support yourself during development. IE you have to work a job (or whatever) AND build games AT THE SAME TIME.  otherwise, you'll just keep running out of money. the one thing you can be sure of on any engineering project which is not a repeat (and even sometimes when it is) is that it will take longer than planned. that's life and murphy's law. so you can't work for X amount of time and save Y dollars to fund Z hours of development to accomplish goal A, cause Z is always longer than expected. however, you might save up enough for 2Z, 5Z. or 10Z hours of development, while still estimating only Z hours required, in which case you might not run out of money. if no matter how you juggle the numbers its just takes too long to save up the money to get more than enough time to do the dev work, then your project is simply too big for you to take on alone. i could build a better skyrim than skyrim, but i couldn't do it alone, unless i had about 30 years


>>  maybe, just maybe if they are way more advanced than me and know the maths and the right algorithm straight out (so don't need to experiment - make mistakes through dead ends like I did several times) then yes, they can do a draft prototype in 1 months )


ok, this explains a bit. you're not inventing new algos. you're trying different ones.  never sit down to the keyboard until you know what to write.  research your algos first.  choose the best, implement it, move on.  if unsure, prototype. this should almost never be necessary for selecting between known algos for a specific use case.  prototyping is most properly used to test that which is untested by all - not just by you personally.   IE to boldly go where no one has gone before, not to reinvent the wheel.   and learn your math and physics before trying to implement.  when you're at the keyboard, its time to type - not time to figure out what to type. you should figure out all that before you decide whether you'll even build the game or not. you can't judge if its worth your time until you know how long it will take -  which means you need to know the algos and math to be used. if you try to estimate with no idea of the math or algos to use, i'd say off by a factor of 10 is a damn lucky guess - i'm surprised you weren't off by more.


obviously you must know the math and algos to be used BEFORE you can get any kind of idea about how long anything is going to take. and LONG before you sit down to code. you have to do that before you can even vet a potential title for feasibility. 


in brief the process should be as follows:

1. RESEARCH!!!!!

2. prototype only as absolutely required.

3. vet for feasibility

4. code.


you seem to have skipped step 1 altogether, are going way overboard on step 2 seeking the answer to step 1, are having difficulty with step 3 due to skipping step 1 and wasting too much time on step 2 trying to get the answers you should have gotten in step 1, and thus you never reach that happy place known as step 4 - where you can code with confidence.


its now obvious your fundamental problem is lack of up front research.


fix that, and everything will become MUCH MUCH  easier.









#5290914 How do I measure risk?

Posted by Norman Barrows on 09 May 2016 - 08:37 PM

>> Like Briandigitalis points out, a small or single person team can't afford to hire all specialists (business, Artists, Extra programmers)  required.  I wish I can hire all the business-risk analyst, but for obvious reasons I can't afford to do that. So the next thing to do is to improvise which is do most aspect - meant for specialist - on my own 


same here. such is the life of the lone wolf developer. but you don't have to be a big or rich studio to be good at estimating - you just have to be good at estimating. although a rich studio might be able to contract such skills.

#5290637 How do I measure risk?

Posted by Norman Barrows on 08 May 2016 - 07:04 AM

from your post it seems you have now learned though trial and error, most of the vetting process for title selection.


i'll just address them as they appear in your post.


"This question is more relevant if the project involves some few untested concepts." 


ok, first off, there really should be no question marks left by the time its time to finally say go or no go.  so as part of the vetting process, you must rapid prototype everything you are unsure of. penciling algo's just ain't gonna cut it.  so your whole problem of the project taking longer because you had to re-design cause your original untested design didn't work goes away.  OTOH, you vetting time goes up, cause you must now rapid prototype everything you've never done before.  you may spend a month protoyping stuff for a game, only to discover its not a good candidate. better to waste a month than a year or 2 or 3 or 4.   so now you know what to do, and you'll never have untested concepts in your projects anymore. cause they won't even become candidates until they've been tested. simple huh? more work? sure.  you didn't think succeeding would be easy did you?




>> it took much much longer than was estimated (~ 9-10 X estimated time) 


easy way to fix that: do your standard estimate like you normally do, then multiply by 10.  for engineering in general the rule of thumb for experienced engineers is "double it", or "add 10%" when its a no-brainer.




>>  some ultimately failed due to flawed business analysis 


the game was not vetted thoroughly enough for sale-ability / potential demand.   either you didn't do your homework, or you came to the wrong conclusion,. either way, you should have learned your lesson by now, and it won't happen again, right?   





>> Only one of my previous projects was a full blown success, a very bad success rate


its about par for the design methodologies you've been using (IE muddling though). don't feel bad, we would all have similar track records under similar circumstances. "muddling through" is a rather hit or miss design methodology.






>> others failed because it was taking too much time and savings couldn't sustain it any longer


business is about making money - not spending it. all you need is a computer, software, and electricity  everything else is just overhead.    and NEVER quit your day job, until you've made at least 100K in games. then, even if you never sell another title, you'll have enough money to find a new career. 




>> But when one factors in other pressures such as available savings (or limited funding), that answer is not so clear cut anymore


hardware, software, electric bills, and supporting yourself are all part of the costs that must be factored into the vetting process, IE "Can i afford to build this?"

and quitting your day job, and betting your savings on a game is a BAD, BAD idea.  secure a source of income that will support you and pay the electric bill for the company, and can buy any required hardware / software.   this factors money out of the equation at least for a while (until marketing time).  then its juts a matter of how much of your time your willing to spend on development.


>> is there a standard way of estimating this kind of risks so as to cut down if its not feasible within certain time?


yes, but in the end they are estimates (educated guesses). you tend to get better at them with experience - IE as you become more educated about what it takes to succeed.   so for your next project, you want to determine market demand, rapid prototype, and do time and budget estimates.   then to adjust your results, divide estimated sales by 2 or 10 and increase time 10X and maybe double costs. and THEN see how viable it looks.   how much to multiply or divide things by depends on how off your estimates have been in the past. you stated you've been off by a factor of 10 on time estimates, but gave no examples for sales or budgets - so i'm guessing divide by 2 or 10 or multiply by 2 or 10 for those. you will have a better idea of what the "correction factor" should be.  this is really how one learns to estimate things in engineering. you do an initial estimate, and from the results determine your error factor. then the next time, you correct for your error factor. every time you do an estimate, your error tends to go down, until you reach the golden rule for engineering which is x10 for safety, x2 in general, and +10% if you know what you're doing.   there are entire semester long courses in engineering on this kind of stuff (especially cost estimates, as opposed to time estimates).

#5290528 Most important principles of game design?

Posted by Norman Barrows on 07 May 2016 - 04:31 AM

Some of the principles people have tossed in from a past thread are:



psychology of fun

building/triggering emotions

level design

emergent game play (what is that anyway?)

building complexity

design modification (perhaps this is simply part of iteration)


Is there a core group of principles in this stuff?


balance - this speak to the concept of difficulty.  a game which is too easy or difficult is not fun.


level design is specific to level based games. and like interior design is largely a matter of opinion.


emergent play is when basic rules of the game combine to produce complex,  unanticipated, beneficial results. 

"attack equal or smaller within 50 feet" + "move to owner if far" makes my pet dire wolf chase small critters and birds just like real dog - and that was totally unplanned.


building emotional momentum really is only related to storylines in games.  not all games are storyline based.







possible core principles:


balance and perceived fair play. all games should have this.


fun - all games should be fun. note that one person's definition of fun differs from the next. what you consider fun, others may not, and vice versa.


pacing - one should not progress too slowly or quickly though the game.  a slow pace is boring. too fast a pace and you run out of content too quickly. you may also become too powerful too quickly, throwing off game balance, especially in later stages of the game.  


not a whole lot else comes to mind offhand. and i have 6 years experience as a table top D&D DM, and 27 years experience as a PC game developer.


Valrus' posting above sums up the situation pretty accurately.

#5290432 how good is rand() ?

Posted by Norman Barrows on 06 May 2016 - 09:49 AM

>> If you're looking at specific applications then you can easily set up tests for them. Just run it like 10k times and see what the results looks like (distribution, unacceptable patterns, etc).

yeah. like i said, haven't done that yet. 
it would be nice if someone here could say from the point of experience that at point X, i'm going to run into trouble. then i just stay below X and don't have to analyze anything.
wonder if anybody's every posted an analysis of the rand() function in MS C+++. probably only in a white paper as a comparison to some other algo they were writing about. not easy to google that.
unless someone here can provide more guidance, or unless my suspicions become worse, i guess i'll just wait and see. fact is, right now, believe it or not, coming up with a way to research the defense skill is the most pressing development issue in the project at the moment. A* is up and running, and everything else is simple and already figured out - its just a lot of grunt work.

#5290427 how good is rand() ?

Posted by Norman Barrows on 06 May 2016 - 09:35 AM

>> Correct.  With N being significantly less than 32767 (like say, a d20 or a pair of percentile dice) you should also not be affected by the striping by using a lerp function.

Hmm..  i usually use a d10000 for everything (percentile dice with 2 decimal places of accuracy, so accurate to 0.01% chance).  might striping be an issue at 10000? i haven't performed any type of analysis of the output of a d10000.
perhaps i should use rand() to generate digits 0 - thru 9 inclusive or 0-99 inclusive (using lerp), then use those to build up a random number of how ever many digits is required.
so how high can i probably go with N (using lerp) and avoid striping?
a d10? a d100? can i get away with a d1000 or the d10000 i'm using now?
the higher i go, the fewer calls to rand to generate a given number of digits.

#5290422 Designing ownership

Posted by Norman Barrows on 06 May 2016 - 09:18 AM

well you have objects, and owners, and entities.


objects have owners.


but not all entity types respect ownership of all object types.


so you're going to need a matrix of which entity types respect the ownership of which object types. some sort of lookup table or 2d matrix is typical for this.


when it time to do the ownership thing, consult the table to see if you even have to worry about the "violates ownership" check, or whether you can simply proceed as though the object had no owner (IE the ownership is not recognized / honored / respected).

#5290418 Most important principles of game design?

Posted by Norman Barrows on 06 May 2016 - 09:08 AM

>> Someone who teaches table top game design said they find the two most important concepts to be conflict and iterative design


conflict = easy drama = easy entertainment.


iterative design is about the only known good way to refine the design of a product or service. its simply good solid design engineering practice, no matter the product or service.


you come up with your best guess as to what will work well in the real world, build it, then throw it out there and see what happens, then you go back to the drawing board, make changes and try it again. eventually you throw the switch and the darn thing doesn't blow up immediately, and instead works as it should , that's life in the engineering, r&d, and invention lane.

#5290417 Most important principles of game design?

Posted by Norman Barrows on 06 May 2016 - 09:00 AM

>> the most important game design fundamentals and/or principles to teach


for design:


you have the vision (the basic game concept) and the audience (potential players for games of that type).


you must know the audience and stay true to the vision.


that's the most important thing.


Aesthetics - Dynamics - Mechanics can be a useful too when analyzing game designs.


there are of course the fundamentals of the other disciplines of game development. such as writing, artwork, music, voice acting, and software engineering. but they are disciplines separate from design.

#5290233 Is WPF 3D Scene Graph or a Non-professional Toy?

Posted by Norman Barrows on 05 May 2016 - 06:21 AM

no mention of shadows





this is the only WPF google image with shadows:





WPF looks to be  wrapper API for DX that implements a subset of Dx functionality for use in .NET business, scientific, and engineering apps.  it does not look like its designed specifically for games - or with game development in mind at all for that matter..


you know you can google this stuff yourself.

#5290225 how good is rand() ?

Posted by Norman Barrows on 05 May 2016 - 05:37 AM

>>  It also has a tendency to have very poor randomness in the least significant bits, in particular it tends to alternate odd and even numbers so dont just use % to constrain the range, try >> it a couple of bits first.


i basically lerp from 0 thru 32767 (inclusive)  to 1 thru N (inclusive) for an N sided die roll.  i don't use mod.  so that low order lack of randomness should not affect me, correct?


maybe its just wishful thinking on my part that rand() is "rolling high" a lot on success checks.  i don't notice a lot of misses in combat, which uses rand in the same manner.

#5290149 GDD/doc, branching storylines, physics behaviours

Posted by Norman Barrows on 04 May 2016 - 04:46 PM

>> But then, if only i can find like, specific 3d math from a particular game title...


post a question in graphics or AI programming (whichever is appropriate), describing the desired effect, and the name of the game you saw it in. odds are someone can identify the algorithm used, and the math formulas behind it. who knows, maybe someone here even worked at the company, or knwe someone that did, or perhaps even worked on that title. its a small world. and veterans of a number of famous titles haunt these forums. (tom being amongst them) <g>

#5290146 3d game library?

Posted by Norman Barrows on 04 May 2016 - 04:39 PM

i find dx9 plus a thin wrapper layer, render queue, frustum cull, and asset pools to be a good combo for a basic graphics system.


but its not cross platform.


same thing should be doable in Ogl, which is a bit more cross-platform.


think long and hard about the platforms you want to support and why. the choice of platforms can severely limit your choices from available tools.

#5290141 how good is rand() ?

Posted by Norman Barrows on 04 May 2016 - 04:17 PM

>> If you need something with cryptographic-style random guarantees you will need a specialized library for that.


you mean something like rand_s() ?


rand() seems fine for procedural content generation and random AI behavior, but success checks for actions - it seems to "roll low" (or is it high?) quite often.   actually i think that would be returning higher than average values more often  - come to think of it. most of the ode is of the form: if dice(10000) <=chance. and dice just lerps rand() from 0 thru 32767 to 1 thru 10000. so frequent failures would be "high rolls".


ok, so the frequency distribution on rand() sucks.


whats fast, low memory, easy to implement, etc, etc, that i can use instead? at least for the success checks and combat dice rolls.

#5289915 Is Making The Player Read Lots of Text Unusual?

Posted by Norman Barrows on 03 May 2016 - 12:47 PM

>>  games that are books of text


(donning my best south park voice)


steve jackson! OMG! dude! he invented CAR WARS!


and they killed kenny!