Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Yesterday, 10:31 AM

#5291535 Operating System Questions in Assembly

Posted by Norman Barrows on 14 May 2016 - 05:28 AM



if you want to get into OS development, get a good book on systems programming, and write an emulator, compiler, and relocatable loader. it may take a year in C/C++.  its typically a 3rd year college course in software engineering.

#5291523 Texture Masking for Pseudo-Lens Flares

Posted by Norman Barrows on 14 May 2016 - 04:04 AM

>> I've implemented John Chapman's Pseudo lens-flare in my OpenGL project and the result somewhat looks like this:


you are aware that lens flare is a real world graphic artifact of images viewed though lenses, right?


and that it should not occur unless the image is viewed though a lens, IE on a view screen, and never when as seen by the human eye.


but it does look cool - doesn't it? <g>.


FYI, the characteristics of a lens flare (shape etc) are a function of the geometry of the lens in question.  so two different lenses will produce two different flares under identical conditions.

#5291521 my C++ console 3D fps Game on Windows from scratch

Posted by Norman Barrows on 14 May 2016 - 04:00 AM

>> But yeah, looking up color is implemented by finding the nearest color point in terms of Euclidean distance


3d space color mapping is the standard method. i was using it too back in the mid to late 1990's.

#5291512 Stop the Player or Punish Them

Posted by Norman Barrows on 14 May 2016 - 03:32 AM

punishing that does not make sense in the context of the game world is an immersion breaker and bad design.


if you shoot a goodguy, cops chasing you make sense. you health going down does not. that's a "bad designer! no twinkie!" if i ever saw one.


you should try to make something not possible due to circumstances that seem wholely reasonable and logical in the context of the game world. so you don't break immersion.


so what you want is an EMP gun, which does nothing to humans, except perhaps with repeated exposure at max power for decades on end. (the whole EM fields and cancer thing - IE don't build your house under high voltage power lines).

#5291311 Ways of Buffering Data to be Rendered?

Posted by Norman Barrows on 12 May 2016 - 11:47 AM

>>  All I know is locking an entire thread while another executes is a bad solution


when its time to render, lock required update data, copy it, unlock. then render as usual, using your copy of the current game state.


i don't think anything else is going to be faster.  you need all that required game state data to render.   not doing it all at once just adds more locks.


DOD layout of the data to be copied will minimize lock times.


you have two threads, you want them to both scream. one needs info from the other from time to time. so you lock it as infrequently as possible, and get the info as quickly as possible, then immediately unlock. that's about the best you can do.


the other option is some sort of intermediate buffer, where update places a copy of its data when it changes, and render grabs the current data when it renders. but then update must lock and unlock the buffer, as must render.  but this does mean update wont stall while waiting for render to copy its data. of course you could still gets stalls if update was ready to write to the buffer, but render was still reading.  update will most likely be orders of magnitude faster than render, so update stalled while render reads the buffer is much more likely.


in the end, you go with what has the fewest locks and the fastest data transfer, for lowest overall execution time.


and you'll probably want to do as much on the update side as possible, since render runs slower.  OTOH, render is the one who needs the info, so odds are that's not possible without just slowing things down overall.

#5291110 My game ends up being boring

Posted by Norman Barrows on 11 May 2016 - 06:17 AM

>> Have you tried playing, and analyzing the zigzag game


this should have been done before you even started your game, or the moment zigzag came out, while your game was still under development.


>> Not sure what the factor is...that makes zigzag so fun...

and yet you hope to meet or exceed it?    wow - that a tough prospect.
looks like you've now learned that technical skill in building games (game development skills like coding, artwork and audio) is not the same thing as skills in designing fun games (game design skills). 
looks like you need to brush up on your design skills so you have a project worthy of you technical capabilities.

#5291106 Getting objects within a range (In order, fast)

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

>> and I want them to load from the closest to the player first


why? i would think that you would need:

1. all possibly visible chunks in ram,

2. and then from those you would generate a list of possibly visible objects in those chunks,

3. which you would then frustum cull and draw.


but the order or distance of the possibly visible chunks is irrelevant, as you must check them all for possibly visible objects.


>> Thing is, there's no magic algorithm that could simply retrieve the objects within a range without any iterations.


except bucket sort, and then you still have to deal with empty buckets  and more than one object at the same range (IE more than 1 in a single bucket)


OP:  definitely sounds like the standard container you're using just ain't gonna cut it. i'd fix that first. then if its still not fast enough, check into spatial partitioning methods such as octrees. sometimes you have to break a few eggs to make real mayonnaise, and sometimes you don't. fix your containers first, and wait and see on octrees - you may or may not need them. you won't really know until you fix those containers.

#5290929 My game ends up being boring

Posted by Norman Barrows on 10 May 2016 - 12:27 AM

>>  I took most of unnecessary things out so the games were stripped to basics.


less is not always more.


>> However, my games end up pretty boring, despite having sweet graphics.


not as sweet as zigzag. (personal opinion)


>> Why do all my simple games end up being boring?


perhaps because they are too simple?


>> Why is my game, the upper one, so boring? 


hard to say without playing both games, but it appears to be simpler - perhaps too simple.


>> Who says it boring? Im saying that...any the low download numbers :-)


i'd say they have a better name and the game looks like more fun based just on the screenshots,  that could account in part for your download numbers, with the rest accountable to lack of time since release of your title (IE undiscovered as Nanoha says), and lack of marketing on your part.


never try to go head to head with the competition until you have the superior product. you'll just lose. that's a basic rule of thumb in any business.

#5290924 I aspire to be an app developer

Posted by Norman Barrows on 09 May 2016 - 11:39 PM

odds are you can get father than just python and java in 4 years, with a combo of standard CS associate degree studies + individual study on topics of interest (such as game development).


if you want to be making money in 4 years,it will be easier doing so with apps (non-game programs) than with games.  you say you want to make apps (which to me means business apps - which made me wonder why this thread was even on gamedev at all), but you sound like you want to make games (game apps?). i'll assume you mean you want to make games, not business apps for smartfones.


you'll have three types of useful resources, info on languages/programing in general, such as books on python programming, info on how to write games (often available in a few choices of language), and info on the math and physics used in games.


overall, your plan sounds quite solid. you've secured a position that will maintain you while you learn. you will also be receiving formal training.  free time for individual study may be an issue. a career, school, and learning game development will leave little time for anything else.  and of course there are the hazards of military duty. so do us all a favor and don't get shot, or we'll never get to play any of the cool games you're going to write. Ok? <g>.


exactly what to learn will depend on what kind of games you want to build. the game type(s) will determine your language options. a good basic knowledge of algos and data structures will be required, and should be part of your 2nd year CS courses. you'll also want to know Cartesian coordinates and basic trig (and linear algebra if you want to do 3D). none of that will be covered in a CS degree. on the physics side, you'll want to learn basic physics and mechanics - at least enough to use a physics engine library correctly. this too will not be found in a CS degree. graphics programming may or may not be part of your formal training, if so it may just be 2d vector graphics.   so math, physics, and graphics will be areas for individual study along side your formal CS courses.

#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.