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

Posts I've Made

In Topic: Bricking up the exit: Denying completion of the Hero's Journey

Yesterday, 01:50 AM

>> - Is it a good idea to make sure that when players do exit (which is inevitable), it's a satisfying exit?


no harm in it.



>> - How can we determine when a player is ready to exit, so we can present the exit, before she continues playing beyond her point of enjoyment? (ideally, we want to encourage use of the exit before the game gets boring, but after he's had as much enjoyment as can be mined out of it)


nigh on impossible. its hard to say when they will get bored.  you might assume they won't get bored until they run out of content, but that's not even a safe bet. they may not be into the content that remains, or they may not have even found it.


- How can we present the exit in a way that players comprehend well?


shouldn't be that hard. reminds me of Sol (Edward G Robinson in his last film) "going home" in the movie Soylent Green with Charelton Heston.

just be sure to make it obvious. i accidentally ended fallout 3 twice by completing the rather short main quest line. and the second time it was unintentional. i found myself at the final quest without ever actively pursuing it.


- Is this actually beneficial for the developer? 


for the developer, no. its more work. and its not enough of selling point to significantly impact sales.



it seems you like closure. there's no harm in adding optional "closure" features to a game. but then again, in real life - the ultimate rpg - there's no closure, no exit for the bored (if there was i would have left this god forsaken rock long ago - i'm just doing time on planet earth).  the only exit is suicide.  so you keep playing til you drop or you're so bored / disgusted / without hope you cap yourself.

In Topic: responsiveness of main game loop designs

Yesterday, 01:02 AM

>> If you accept the argument that there's no need to poll faster than the drawing rate


assuming you update no faster than you poll or render.


just cause you can only draw the screen once every 8 games turns doesn't mean you should let the computer move every turn and only let the user move every 8 game turns.


you have to preserve the fair play of "its my turn, ok, now its your turn, ok now its my turn again."


"i cant draw fast enough to show you whats going on - so you don't get a turn until i can" - that's just silly.


yet from what you say, it seems folks actually do this. no wonder games are such piles of crap these days.

In Topic: simulate battles - cavalry?

Yesterday, 12:28 AM

>> This could work. Comments? Very abstracted I know but I need something along these lines:)


here are some good rules of thumb for such a system, based on how things tend to go down in realtime total war combats:


ability to conduct flank attacks:

1. having cavalry units

2. lite infantry can be used in a pinch, if you have a lot, and outnumber the enemy


ability to defend against flank attacks:

1. having cavalry units

2. having extra infantry units (more than the enemy), so some can cover the flanks.



how they match up:


flank with lite or heavy cav, or lite inf.   (figure out some numbers - how many and what kind are available).


defend with lite or heavy cav, or inf   (figure out some numbers - how many and what kind are available).


so each side will end up with a score of how well they can flank, and defend again being flanked.you then compare these to see how the "flanking battles" will go. the flanking battles will be fought off to the sides or in the rear areas as separate skirmishes from the main battle line.


you then take a look at the flanking numbers and the main battle odds to determine victory. if an army can win the main battle and not be outflanked, it will win. if it can achieve stalemate in the main battle and can win at flanking it will win.  if it can flank with ease and the main battle is not too lopsided against them, they might win. basically, a great advantage in flanking will tend to counter a great advantage in main battleline forces.


armies with archers will usually lose use of the archers at least temporarily if the enemy succeeds in outflanking them.


you might think of it as two ways to win, the main battle, and flanking. with both contests go on at once.  victory in either usually brings the other to a swift conclusion.

In Topic: Most important principles of game design?

27 May 2016 - 06:45 AM

you should probably make the distinction between design issues (pacing, balance, complexity, etc), and development issues (correct scope for the team size and time available, creeping featuritis, and similar production - as opposed to design - issues).


when bogged down in the trenches, its common for devs to blur this distinction as to what is a design issue and what is a development issue.

In Topic: Looking for a good textbook

27 May 2016 - 06:33 AM

>> I noticed that the printing date is 2006. Does anyone know why there have been no recent additions


looks like they wrote a book

1. as a way to make some more money with gamemaker and...

2. as a way to get more folks using gamemaker.


given that they've dong nothing more in a decade, odds are their attempt was not successful.


i think the last game book i saw that was really useful as opposed to someone just trying to cash in on the gamedev scene was michael abrash's "back art of 3d game programming".


don't get me wrong, there are good books, but there are also a lot of titles that seem to be simply trying to cash in on the gamedev scene, in some way or another, to some degree.