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 Today, 08:46 AM

#5200804 Am I overengineering

Posted by Norman Barrows on 30 December 2014 - 08:47 AM

Here is one of the design mantras I always try to follow:  By only adding the code that you need right now, you make it easier to change direction later.  This is hard, only adding the code you need and keeping everything as simple as possible.  




it becomes easier as you develop more coding discipline.




more sprigs of gamedev wisdom:




Time spent moving things around without any positive gains is also wasted time.




If you just add the dumbest code you can, eventually the design will appear.




Eventually you'll have your game, and it will look nothing like your designs from the beginning. 

#5200703 do most games do a lot of dynamic memory allocation?

Posted by Norman Barrows on 29 December 2014 - 07:33 PM

I spent most of the video wondering why he was considering extending a language to have native support for raw pointer based ownership in 2014. I just don't get where he is coming from.



I guess you also have a lot of global state lying around with no restrictions on where you can access it from. I wouldn't like that.

With custom allocators and modern approaches to management, I see solutions to problems that don't really exist around this whole topic. It was an interesting talk from Mr Blow, who I respect enormously, but I was left feeling like he wanted to add to a core language things that are already well solved by libraries.


i get the impression he is of the old school bare bones down to the metal kind of programmer.  take a look at the code he shows for invaders, and how the game is written, and you'll understand better why he wants what he wants in a game language. while its not what i'd want in a game language, my experience with the productivity increase from switching to Cscript makes me understand his enthusiasm.


its not so much the language he's making that impressed me so much as some of the observations, such as "the solution should define the program structure, the program structure should not be mandated a priori". also the fact that Carmack is in-lining a bunch of stuff. etc. but then again, those guys at ID never did give a hoot about all that "high falutin' architecture stuff", all they care about is "does it work? and is it fast?"     might be a lesson to be learned there.  ; )

#5200256 How to model and program in the correct scales?

Posted by Norman Barrows on 27 December 2014 - 09:14 AM

only for rigid body models. for skinned meshes, you typically just have one rigged mesh scaled correctly in max, then exported for loading into the game.


that is, unless you're doing multi-part skinned meshes, where for example the head is a separate skinned mesh from the body.

#5200255 How to model and program in the correct scales?

Posted by Norman Barrows on 27 December 2014 - 09:09 AM

Do I first merge the NPC models into the main scene, and export them as a whole to the game engine.


probably the hard way to do it.


And do we usually use a game editor so that we model each piece individually and put them together in the game editor
and export them to the game engine later?


only for rigid body models. for skinned meshes, you typically just have one rigged mesh scaled correctly in max, then exported for loading into the game.


Do we first merge the NPC models into the scene, then make the correct scales and delete them in turn


by "scene" i assume you mean the static world geometry (ground mesh, buildings, etc).  the method you describe is one way to make sure you get the models scaled correctly.


another is to define a scale, such as 1 unit in max = 1 d3d unit in the game = 1 meter.   you know the size of the desired vehicle: 2.5m wide, 3.5m long, 2m tall let's say. so you just scale it in max until its about that size, then save and export. this is really the way to do it. no code fix ups required. model everything to scale this way, and all you have to do is load and go! everything is already the right size.

#5200140 When is it okay for a player to get "stuck"?

Posted by Norman Barrows on 26 December 2014 - 03:49 PM

With this mechanic, a player could be at a point where they would have to "restart" the level in order to retry if they don't do things in the right order before going through the "one way door".


requiring a specific order of task completion without making the player aware of it (other than by trial and error) is usually considered bad design that leads to player frustration. but this does not necessarily hold true for puzzles, where proper order can be part of the puzzle to be figured out. and indeed, the fact that some specific order is required might also be part of the puzzle to be figured out. so as long as you use it as part of the puzzles, id' say its fine. just don't be TOO cruel! <g>.

#5200094 Warcraft 3 style Collision avoidance

Posted by Norman Barrows on 26 December 2014 - 11:46 AM

I found many answers that refer to pathfinding (it is typically said that clearance based pathfinding HAA* is used) but none of those referring to collision avoidance.




by finding a clear path, you avoid obstacles, thus collisions are avoided.


a game that uses some form of A* will typically re-calculate paths from time to such as when a path is deemed no longer valid. other approaches include only doing A* out to a limited range instead of the entire map, and re-calculating from time to time - used for lots of units and large maps where full blown A* of everything is too slow.


generally speaking, A* is known to be processor intensive, so you want to calculate path only when required.


note that heuristic approaches can also yield good results in your case (many units, not complex environment, no concave obstacles).

#5200087 Do you put code in your engine/game you don't fully understand?

Posted by Norman Barrows on 26 December 2014 - 10:59 AM

from a quick glance  at the code you linked to, it appears they express the two vectors as follows:


a start point, and a unit vector in the desired direction, times a constant magnitude.


they then assume the two vectors intersect, and solve for the two constants when the resulting endpoints are the same:


unit_vector_1 * constant_1 = unit_vector_2 * constant_2


i'd find a book on vector math, use a different better documented algo, black box test thoroughly, or find a math nut who memorizes this kind of stuff.

#5200085 Do you put code in your engine/game you don't fully understand?

Posted by Norman Barrows on 26 December 2014 - 10:50 AM

Its "Intersection of two lines", I already posted it here,


it actually appears to be intersection of two vectors in 2d space, using parametric expressions.


a good book on vector math seems to be called for.   don't have mine anymore unfortunately...

#5200084 Do you put code in your engine/game you don't fully understand?

Posted by Norman Barrows on 26 December 2014 - 10:38 AM

So as the title suggest, do you copy code from the internet and put it in your game/engine without fully understanding it?


never, or only in the distant past.


so today I gave up and just copied the code from the internet and put it in my engine.


i may have done that once or twice in my early days.


just do good black box testing to make sure you can depend on it - even if you don't fully understand its internal workings.


even better - as suggested above - use the gamdev.net, community to help you figure out the code!  : )

#5199878 Stuck with which approach to take (architecture)

Posted by Norman Barrows on 24 December 2014 - 01:29 PM

How do you guys typically architect a rendering engine?


custom rolled for the game its designed for.  the custom render engine in turn calls the Direct3D api.


how to render is a function of what to render, which is a function of game type.

#5199876 Visual studio 2013 (exe release) runs slower compare to VS2010

Posted by Norman Barrows on 24 December 2014 - 01:16 PM

Hello, I convert a project that was in VS 2010 to VS2013, everything went smoothly, but the performance (for the release exe, with same exact code, and optimization settings) drop almost in half compared to VS2010.


Is this comparison fair? By that I mean same CPU, same GPU and same drivers?


for a fair test, only the compiler/linker/ide can change, and you must replicate compiler and linker settings as best as possible. no hardware or drivers on the PC used for speed  tests can change.


is this the case? if so, the difference is of interest, but probably due to some difference in compiler or linker settings etc that you didn't notice yet.


if not, then comparisons are meaningless. apples and oranges.

#5199465 How can I create an installer for my game?

Posted by Norman Barrows on 21 December 2014 - 07:42 PM

i found inno setup to be an excellent turnkey solution for windows games

#5198767 first person camera rotations to 2d sprite rotation

Posted by Norman Barrows on 17 December 2014 - 08:39 AM

it depends on how you store the camera's rotation.


what you want is the camera's y rotation (Euler angle). that's the rotation to apply to the sprite, assuming you want to draw the player from a top down view in the middle of the radar facing in the direction of the camera.


if you store the camera's rotation as Euler angles (Xrot, Yrot, Zrot), just use Yrot.


if you use a matrix, use the "matrix to Eulers" algo to get Yrot.


if you use forward (look at), up, and right vectors, you already have the first step of "matrix to Eulers" done, just use the rest of it to get Yrot.


if you use quats, convert to matrix, then use "matrix to Eulers" to get Yrot.


been a while, off the top of my head, the "matrix to Eulers" algo is:


start with a vector 0,0,1.


rotate it by the matrix. this gets you your forward or look-at vector.


project the forward vector onto the X-Z plane. 


the angle between the z axis and the projection is  Yrot. how you handle the degenerative cases of forward / look-at vectors of 0,1,0 and 0,-1,0 is up to you.


now, unrotate the forward vector by Yrot, so it lies in the X-Y plane.


at this point, the angle between the forward vector and the Z axis is Xrot


but the algo does not give you Zrot. just an Xrot and Yrot that points a vector 0,0,1 in the same direction as the matrix.


odds are you could do the same sort of thing with up or right vectors to get Zrot.


note that nested rotations are not commutative, so the above assumes a rotation order of Xrot, then Yrot, Then Zrot for transform, and -Zrot, then -Yrot, then -Xrot for untransform. That's why you unrotate by Yrot before you project to get Xrot. If your rotation order is different, you'll need to adjust accordingly.


a couple calls to rotate point by matrix, and a little trig, and you've got it.


the projection of a vector onto an axis (the i,j,or k component) is a vector along the axis with a magnitude equal to the the magnitude of the original vector times the cosine of the angle between the vector and the axis.


as i recall, atan is used to compute the angles between the vectors and the axes.


note that this is just one way to do it. there may be some slick way to do it with vectors or something as well.

#5198449 Do i have to make basic games again after break in gamedev?

Posted by Norman Barrows on 15 December 2014 - 06:39 PM

Tl ; DR
I took long break from gamedev but not programming in general.
So I am wondering if I need to recreate these simple games or I can start with more advanced concepts like AI, side scrolling, more physics etc.?


i've taken multiple breaks of multiple years in the 25 years i've been doing games. its just like riding a bike, you never forget. sure you get rusty, but you pick it up again pretty quick. just pick up again where you last left off, and you'll be back up to speed in no time.

#5197666 How to model and program in the correct scales?

Posted by Norman Barrows on 11 December 2014 - 03:46 PM

but it could be done in realtime to create the incredible shrinking (or growing) man.


but its not the best way to it - forgot to mention that. for real time user scaling of a skinned mesh you can just use the scale part of your transform matrix and add in the user correction factor.


in my case i was dealing with multi-mesh rigid body models that you couldn't simply scale using just the scale part of the model's transformation matrix.