Jump to content

  • Log In with Google      Sign In   
  • Create Account


Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Jul 21 2014 06:32 PM
*****

#5160084 Minimum specs for a game dev laptop

Posted by Norman Barrows on 12 June 2014 - 11:23 AM

probably the best thing to do is determine the system requirements of the games you want to make, then buy the best value in a light weight laptop that meets those specs.

 

that way you don't over buy or under buy.

 

as mentioned above, graphics (gpu and monitor) will be the weak link in a laptop, perhaps making a system that meets your specs a bit more pricey for the nice graphics you'll want for higher end game graphics development.




#5156487 Would you play this?

Posted by Norman Barrows on 28 May 2014 - 08:38 AM

i'd have to agree with jbadams and Orymus3, time for a rapid prototype.  

 

try coding one level and see what its like.

 

i find the rapid prototype to be an indispensable tool in the vetting process of what to build.

 

sometimes the results are surprising as to what is fun, and what is less fun that expected..

 

i've actually put sequels of previous hits on hold because the rapid prototype of the "new and improved" version was "not quite right yet" in terms of desired gameplay.

 

 




#5156322 calling function pointer without typedef

Posted by Norman Barrows on 27 May 2014 - 12:59 PM

Here's a real world example from Caveman 3.0....

 

first, the typedefs....

 

//#################################### TYPEDEFS #####################################################
 
 
 
typedef void functiontype1();
 
typedef void functiontype2(int);
 
//#################################### END TYPEDEFS #####################################################



#5155094 when do you kill an idea?

Posted by Norman Barrows on 21 May 2014 - 11:04 AM

>>  It was meant to be a small project I could use to learn game maker studio's scripting language. 

 

And did it accomplish this for you?

 

>> I think maybe the biggest problem is that I generally don't like puzzle games

 

Ah, thats a toughie...

 

That makes it more like app or database development. IE you don't have what YOU consider a fun game when you're done.

 

Given that the scope of the game is relatively small, and you're close to done, i'd say find playtesters and finish it as an exercise in doing the un-fun gruntwork required at the end of a game. but don't spend more than a week or two more on it overall.  Move on to a title that YOU want to play, takes your dev skills to the next level, and perhaps might make a buck or two in the process.

 

 

 

 

 

 

 

 

 




#5154305 Interface project feedback

Posted by Norman Barrows on 17 May 2014 - 12:02 PM

a rapid prototype might be called for to determine if the controls are intuitive or awkward to use.

 




#5154299 Best Way to Structure A Game

Posted by Norman Barrows on 17 May 2014 - 11:26 AM

there are probably almost as many answers as there are coders. Everyone seems to have their own ideas on the subject.

 

technically speaking, most "games" are some sort of modeling and simulation software. the "game loop" is the traditional way to write modeling and simulation software. IE display the scene, get user input, run the simulation, repeat until quit game.

 

event driven is what i refer to as "deferred processing". an event occurs that requires processing. instead of immediately handling the event and continuing, you store the event for later processing. this adds the overhead and complexity of an event storage / message system. but there can be cases where deferred processing is preferred or necessary.

 

data driven means you load data (usually constants) from a data file instead of hard coding it - IE how many hit points a dragon has, etc.   it requires a bit more coding to implement.  it provides two advantages:

1. non-coders can change the data. only useful if you need non-coders to change the data.

2. no re-compile required to change the data. only useful for games with long compile times - like Caveman - 20 seconds to translate, and 55 seconds to link. since i knew Caveman would be big by the end, i probably should have made it more data driven in the first place. if constant values are determined early on and change little thereafter, data driven can be overkill, even with long build times. Also data driven runs a little slower than hard coded, as it must do additional disk reads to load the data. 

 

MVC is a design pattern from business apps (but NOT modeling and simulation apps).  out of all the non-game specific design patterns, it might be closest to what one typically does in games, although i suspect that games and MVC tend to divvy up display and input slightly differently. I became a fulltime gamedev before MVC was invented so i'm not overly familiar with it. perhaps others can expand on the similarities and differences.

 

right now, i'm starting on my....perhaps my 25th or 30th game, and i'm going game loop and data driven:

 

 
 
 
' player -------------------------------------------------
 
 
st playerrec
orientation o
' playership specific variables: energy, dmg, hp, etc.
i modelID
.st
 
 
 
 
 
'  star map ------------------------------------------
 
st moonrec
i active modelID size orbitrad
.st
 
#d MAXMOONS_PER_PLANET  10
 
st planetrec
i active modelID size orbitrad nummoons
moonrec moon[MAXMOONS_PER_PLANET]
.st
 
#d MAX_PLANETS_PER_STAR  20
 
st starrec
i active modelID size numplanets
planetrec planet[MAXPLANETS_PER_STAR]
orientation o
.st
 
#d MAX_STARS  1200
 
 
fn v drawmap
4 i MAXMAPOBJS
if is_nearby_mapobj(i)
c draw_mapobj(i)
.
.
.
 
 
' starports ---------------------------------------
 
 
st starportrec
i active type
i what_it_orbits  ORBITS_NOTHING. use orientation.
 ORBITS_STAR. use star index and orbit_rad.
 ORBITS_PLANET. use star_index, planet_index, and orbit_rad.
 ORBITS_MOON. use star_index, planet_index, moon_index, and orbit_rad.
i star_index      it orbits star[star_index] or one of its planets or its planets' moons.
i planet_index    it orbits planet[planet_index] or one of its moons. use orbit_rad.
i moon_index      it orbits moon[moon_index]. use orbit_rad.
i orbit_rad
orientation o
.st
 
#d MAX_STARPORTS 100
 
 
 
 
'  target types -----------------------------------
 
st ttyperec
i hp modelID
.st
 
 
#d MAX_TTYPES 20
 
 
ttyperec ttype[MAX_TTYPES];
 
 
 
' targets -------------------------------------
 
st tgtrec
i active type dmg
orientation o
.st
 
#d MAXTGTS   100
 
 
fn v add_tgt i type mat *orientation
i i
i=1st_inactive_tgt
= tgt[i].type type
= tgt[i].orientation *orientation
' init tgt variables like damage=0
.
 
 
 
 
 
 
 
fn v drawtgt i i
' draw tgt i
c drawmodel tgttype[tgt[i].type].model tgt[i].ani_player tgt[i].orientation
.
 
 
 
 
fn v drawtargets
i i
4 i MAXTARGETS
== target[i].active
c drawtgt i
.
.
.
 
 
 
 
fn v update_tgt i
' move tgt
' model energy, damage control, etc
.
 
 
 
 
 
' projectiles --------------------------------
 
 
 
st projectilerec
i active type
orientation o
.st
 
#d MAX_PROJECTILES 100
 
 
 
 
 
 
' particles -------------------------------
 
 
 
st particlerec
i active type
orientation o
.st
 
#d MAX_PARTICLES 500
 
 
 
 
 
 
 
 
 
fn v drawparticle i i
'  draw particle i 
.
 
 
 
 
fn v drawparticles
i i
4 i MAXPARTICLES
c move_particle i
c draw_particle i
.
.
 
 
 
 
 
 
 
 
'  galaxies ---------------------------------------
 
 
st galaxyrec
i texID
orientation o
.st
 
#d MAX_GALAXIES 10
 
 
 
 
fn drawgalaxies
4 i MAXGALXIES
c draw_galaxy i
.
 
 
 
 
' render --------------------------------------------
 
 
 
 
 
 
 
fn v drawbridge_interior
' draw bridge interior using 3d meshes and 2d sprites
.
 
 
 
 
 
fn v drawbridgeview
c Zbeginscene
c drawskybox           
c drawgalaxies
c drawmap 
' (nearby stars, planets, moons, starports, 
'              and other map objects).
c drawtargets 
' (ships etc)
c drawprojectiles (torpedos, laser beams, etc)
c drawparticles 
' (streaming stars, debris, etc)
c drawbridge_interior
c showscene
.
 
 
 
 
 
fn v render
sw view
ca bridge
c drawbridgeview
brk
ca mattermover_view
brk
ca transport_bay_view
brk
.
.
 
 
 
 
 
' input ------------------------------------
 
 
 
 
fn v input 
? Zkeypressed(VK_whatever)
' do some shit with player ship
.
c getmouse &x &y &b
? isin x y <some area>
' do whatever with player ship 
.
' etc
.
 
 
 
 
 
 
' update -------------------------------------
 
 
 
 
 
fn v update
4 i MAXTGTS
update_tgt i
.
.
 
 
 
 
 
 
 
 
'  runmission ------------------------------
 
 
 
 
fn v runmission
do !quitmission
render
input
update
.do
 
 
 
 
 
 
' initmission ---------------------------
 
 
 
 
fn v initmission
' choose mission
' show orders
.
 
 
 
 
 
'  rungame -----------------------------
 
 
 
rungame
do !quitgame
initmission
runmission
endmission
.do
 
 
 
 
'   runprog ----------------------------
 
 
 
fn v runprog
menu simspace 8.0...
continue
tutorial
new game
load game
tools
quit
.
 
 
 
 
 
 
 
'   initprog ----------------------------
 
 
initprog
Zinitall
.
 
 
 
 
'  main --------------------------------
 
 
 
void main
initprog
runprog
endprog
 
 
 
' ----------------------------------------------
 
 



#5154292 My sci-fi RPG game design

Posted by Norman Barrows on 17 May 2014 - 10:49 AM

nanotechnology and weaving are two skills that would probably not exist in the same high tech society. IE any society sufficiently advanced to have nanotech would have factories and machines to do weaving. cloth would be a readily available commodity. or perhaps not. maybe only finished products (clothing) would be readily available. hand weaving would be an old/obsolete/lost art.

 

in your quest to replace high fantasy and magic stuff with technology, don't throw away believe-ablity in the process. add RPG elements that make sense, not simply because many RPGs have them.

 

 




#5153791 Level design idea and flow

Posted by Norman Barrows on 15 May 2014 - 09:51 AM

sounds like a traffic driving simulator.

 

that which is pre-planned in real life should be pre-planned, that which is random in real life should be random, for an accurate  / realistic / belivable / immersive simulation.

 

but you know the first thing the player will want to do is run over that old lady in the crosswalk , then see if they can get away from the cops! and just like that, they've turned your driving sim into "the driver" or GTA or Carmageddon.




#5152690 The acceptance of gold loot in RPGs

Posted by Norman Barrows on 10 May 2014 - 09:49 AM

I suspect its a matter of personal preference.

 

the best RPG i ever played was tabletop D&D, original edition rules, refereed by the guy who taught me how to play D&D, and be a ref (GM) and DM.

 

The emphasis was on believably, not realism, combined with a strict "no monty haul" policy.

 

A snake wouldn't even be considered a monster, unless it was giant. And then the only treasure would be perhaps a few items in its gut from its last meal (IE small equipment from a dead adventurer).  So a giant snake might have a few coins, maybe a gem, etc in its gut, but no weapons or armor (too big, or would cut up the snake from inside). The skin might be valuable. There might be the odd dead body in the nest to loot as well. And you'd have to pack it all back to town to sell off.

 

By comparison, many of the monsters and treasures in RPG's today seem almost silly.

 

 

 

 




#5152684 Assassination & game over

Posted by Norman Barrows on 10 May 2014 - 09:13 AM

The implementation of assassins in total war is somewhat similar to what you're talking about. you might want to take a look at it.




#5152553 Camera looking by mouse(smooth)

Posted by Norman Barrows on 09 May 2014 - 10:14 AM

Note:

 

Zresetmouse is hardcoded for 1600x900.

 

you'll want to change Zputmouse(800,450); to Zputmouse(screen_width/2,screen_height/2);

 

 

 




#5152551 Camera looking by mouse(smooth)

Posted by Norman Barrows on 09 May 2014 - 10:10 AM

 

 

this is the generic mouse aimed camera code from my Z game library...

 

i THINK i have all the parts cut and pasted into here...

 

the commented out code that refers to intox_mul implements a drunkcam

 

 

 

 
 
 
// mouse position and button state
int mousex,mousey,mouselb,mouserb;
 
 
 
 
 
 
 
 

// gets mouse position and button state as of the last mouse message
void Zgetmouse(int *x,int *y,int *b)
{
*x=mousex;
*y=mousey;
if (mouselb) *b=1; else *b=0;
if (mouserb) *b+=2;
}
 
 
 
 
 
void Zputmouse(int x,int y)
{
SetCursorPos(x,y);
}
 
 
 
 

 
 
// process windows messages
void Zdomessages()
{
MSG Zwinmsg;
mousewheel=0;    // reset mouse wheel delta to zero before processing windows messages.
                 // windows messages may include new wheel delta.
while (PeekMessage(&Zwinmsg,NULL,0,0,PM_REMOVE)) 
    {
    TranslateMessage(&Zwinmsg);
    DispatchMessage(&Zwinmsg);
    }
}
 
 
 


 
 
 
// message handler 
LRESULT WINAPI Zmsgproc(HWND hWnd,UINT msg,WPARAM wParam,LPARAM lParam)
{
switch(msg)
    {
    case WM_DESTROY:        Zshutdown();
                            PostQuitMessage(0);
                            exit(0);
    case WM_MOUSEMOVE:
    case WM_LBUTTONDOWN:
    case WM_RBUTTONDOWN:
    case WM_LBUTTONUP:
    case WM_RBUTTONUP:
/*
Remarks
Use the following code to obtain the horizontal and vertical position:
xPos = GET_X_LPARAM(lParam);
yPos = GET_Y_LPARAM(lParam);
 
Important  Do not use the LOWORD or HIWORD macros to extract the x- and y- coordinates of the 
cursor position because these macros return incorrect results on systems with multiple monitors. 
Systems with multiple monitors can have negative x- and y- coordinates, and LOWORD and HIWORD 
treat the coordinates as unsigned quantities.
 
TODO: change code to support multiple monitors.
*/
mousex=(lParam & 0x0000FFFF);        // mouse x = low order word of lParam
                            mousey=(lParam >> 16);               // mouse y = high order word of lParam
                            if (wParam & MK_LBUTTON) mouselb=1; else mouselb=0;
                            if (wParam & MK_RBUTTON) mouserb=1; else mouserb=0;
                            return(0);
    case WM_MOUSEWHEEL:     mousewheel=(int) GET_WHEEL_DELTA_WPARAM(wParam);
                            // wParam >> 16;     // distance rotated = high order word of wParam
                            // if (mousewheel > 32767) mousewheel = 65536 - mousewheel;
                            return(0);
    }
return(DefWindowProc(hWnd,msg,wParam,lParam));
}
 
 
 
 
 
//######################################### mouse aim camera ##################################################
 
 
 
int old_mousex=0;
int old_mousey=0;
 
 
 
void Zresetmouse()
{
int b;
Zputmouse(800,450);
Zdomessages();
Zgetmouse(&old_mousex,&old_mousey,&b);
nobutton();
}
 
 
float cam_xr=0.0f;
float cam_yr=0.0f;
 
 
#define screen_width 1600
#define screen_height 900
 
 
int Zmouse_aim_camera()
{
int x,y,b;
Zdomessages();
Zgetmouse(&x,&y,&b);
if (x != old_mousex)
    {
    //if (intox_mul < 1) 
cam_yr+=(float)(x-old_mousex)/1000.0f;
    //else cm[cm0].vyr+=(float)(x-old_mousex)/1000.0f*9.0f*(float)intox_mul;     // bigger = more acceleration (touchier)
    old_mousex=x;
    // handle edges of screen
    if (x<screen_width/10)
        {
        old_mousex+=screen_width/2;
        Zputmouse(x+screen_width/2,y);
        }
    else if (x>=screen_width*9/10)
        {
        old_mousex-=screen_width/2;
        Zputmouse(x-screen_width/2,y);
        }
    }
//if (intox_mul > 0)
//    {
//    cm[cm0].vyr*=0.98f;          // bigger = less decelleration       (less stable)
//    cm[cm0].yr+=cm[cm0].vyr;
//    }
while (cam_yr>=2*D3DX_PI) cam_yr-=2*D3DX_PI;
while (cam_yr<0) cam_yr+=2*D3DX_PI;
if (y != old_mousey)
    {
    //if (intox_mul < 1) 
cam_xr+=(float)(y-old_mousey)/1000.0f;
    //  else cm[cm0].vxr+=(float)(y-old_mousey)/1000.0f*9.0f*(float)intox_mul;     // bigger = more acceleration      (touchier)
    old_mousey=y;
    // handle edges of screen
    if (y<screen_height/10)
        {
        old_mousey+=screen_height/2;
        Zputmouse(x,y+screen_height/2);
        }
    else if (y>=screen_height*9/10)
        {
        old_mousey-=screen_height/2;
        Zputmouse(x,y-screen_height/2);
        }
    }
//if (intox_mul > 0)
//    {
//    cm[cm0].vxr*=0.98f;          // bigger = less decelleration   (less stable)
//    cm[cm0].xr+=cm[cm0].vxr;
///    }
while (cam_xr >= 2.0f*pi) cam_xr-=2.0f*pi;
while (cam_xr < 0.0f) cam_xr+=2.0f*pi;
if ((cam_xr>pi) && (cam_xr<3.0f*pi/2.0f)) cam_xr=3.0f*pi/2.0f;
if ((cam_xr>pi/2.0f) && (cam_xr<=pi)) cam_xr=pi/2.0f;
return(b);
}
 
 
 
//##################################### end mouse aim camera ##########################################
 
 
 
 
 
 
 



#5151218 Call for opinions: handling player death in a tutorial

Posted by Norman Barrows on 03 May 2014 - 11:21 AM

>> Maybe you should reconsider the design of your tutorial. I've never played a game in which I could die while learning the controls.

 

 

<BG>  Then you've obviously never played a hard core flight simulator.

 

 




#5151211 How would you do frustum culling on sponza?

Posted by Norman Barrows on 03 May 2014 - 10:26 AM

what about merge and cull at the sub mesh level simultaneously? i use something like this to generate terrain chunks on the fly from underlying map data structures. A complex chunk can contain 5,000 meshes. items that pass cull get merged. then the results of the cull-merge get drawn. i also use an approach similar to Hodgman's "radial slicing" of the scene to cull entire chunks. 
 
in general i've found for questions like this, a good approach is:
 
1. try brute force. the Abrash and ID way. if that doesn't cut it....
 
2. reorganize your data into the format the pipeline likes best - then draw. this would include culls, merges, etc.
 
sometimes a middle ground between 1 and 2 is good enough to get the job done.
 
BTW, lots of draw calls is something one can live with. a complex scene in my current title can tip the scales at over 18,000 calls per render - and that's fixed function with no shaders and no instancing. state changes almost seem to be a bigger performance issue than draw calls. but both are still issues.
 
Also, sometimes you'll find that cull helps render times, and sometimes its doesn't that much.  it all depends on what you're drawing. so start with brute force, then try some culling, then get jiggy with it and merge, etc.
 
 
 
 
 
 



#5148881 About fixed points

Posted by Norman Barrows on 22 April 2014 - 09:40 PM


The problem was solved by having multiple coordinate systems -- One that was used to describe the location solar systems themselves, and one local space for every solar system -- basically the suns/stars were in the 'universal' coordinate system, and each sun/star was also the center of its own local coordinate system.

 

this is the precise method used by previous versions of SIMTrek / SIMSpace.






PARTNERS