Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Online Last Active Today, 05:58 PM

#5260539 Handling an open world

Posted by Norman Barrows on 04 November 2015 - 12:33 PM

you may want to consider data structures tailored to each task, such as 2d collision maps for movement physics, and some other structure such as an indexed renedrables list for a terrain chunk.


they idea is you store the same data two different ways for two different types of lookups, so both lookups run fast.

#5260535 Game opening

Posted by Norman Barrows on 04 November 2015 - 12:15 PM

The guy you choose will later be the father of the character you play...


the choice of father and mother must be meaningful. IE affects stats and skills, not just appearance. in other words, they should affect game play, not just graphics.


now for the problem...


how does the player figure out which ones to choose?, which ones yield which stats? 


maybe have the ability to talk to them all, with dialog trees, that reveals what type of person they are.


OTOH, when all is said and done, its just a fancy character creation screen. a more straight-forward character creation screen may be a better option than a "pick you parents" mini-game.  is the game so close to completion that you're adding the mini-game cause you have nothing better to do?  is it vital to gameplay? or simply an over engineered UI design for what is essentially just a character creation screen? 


note that there's nothing wrong with interactive novels as an intro method. but there's a fine line between "too much", and "just enough".


i'm doing a similar game (rpg/person sim hybrid) in a paleo-world setting. i'd probably just use a single charater creation screen until the rest of the game was done first. then add the mini game intro.

#5260527 Best design for "dynamic configuration"?

Posted by Norman Barrows on 04 November 2015 - 11:40 AM

For example, I might create a ScreenResolution module that holds the width, height, and fullscreen values while a Graphics module might hold information about AO and shadows. This way each module can get the piece of the ConfigurationManager it needs without having access to the whole module itself.


the thing to do is to FIRST define the APIs that will need the data such as width,height. this will then tell you exactly what kinds of chunks of data you need to pass around.


"this method needs w,h. so do a lot of other ones. but some need w,h plus another variable, and some need entirely different stuff...."


look for repeating patterns of different methods using the same set of "global" variables. this will tell you which variables you want in the structs you pass to the methods. with luck you can get by with perhaps just two or three struct types for passing parameters.


my in-house game library uses a drawinfo struct for drawing calls, and Caveman uses a location struct for setting (indoor,outdoor,etc) + world coordinates + rotation.


note that structs just for passing parameters is how a lot of directx code works.

#5260524 RPGs: strength, health, and hit points

Posted by Norman Barrows on 04 November 2015 - 11:19 AM

whats the difference between strength and health?


if we take strength as an indicator of body size, and it governs encumbrance, then what is health when it governs hit points? is it body size as well?  or how healthy you are? if its how healthy you are, most characters ought to be 100% health, with only a few having some chronic condition which permanently reduces their hit points (less health = less hit points).


hit points as a function of body size makes pretty good sense.  a 3/4" deep laceration across the shoulder on a petite 110 lb female would be a more serious wound than it would be on an Arnold Schwarzenegger type, just based on arm size.


but "strength" based on body size also makes sense, unless you model "getting fit" to increase your base strength. then body size would determine your base strength.


so instead of strength, health, encumbrance and hit points, maybe it it should be body size, strength, encumbrance and hit points.


body size governs base strength, you can "workout" to increase strength, but it goes back down over time. strength governs encumbrance and damage done, body size governs hit points.


but maybe strength should affect hit points as well. someone in better shape can survive things a less fit person might not - such as six pack abs vs dagger or claw attacks.


so that would mean you have a base strength, which goes up through use, and you can also train up, but its goes back down over time. and encumbrance, hit points, and damage done are all governed by/affected by strength. and the health stat goes away - assuming everyone is relatively healthy. in most RPGs your character doesn't have some crippling disease that leaves you with just a handful of hit points the whole game.


caveman currently uses strength and health. strength is fixed and governs encumbrance and damage done. health is also fixed and governs hit points, and perhaps healing rate, disease recovery chance, chance to get sick, that kind of stuff.


maybe strength should be variable as described above, and govern hit points, with health just affecting healing and sickness? IE health would be an indicator of the strength of your immune system.


thoughts? comments? suggestions?

#5260386 Best design for "dynamic configuration"?

Posted by Norman Barrows on 03 November 2015 - 03:54 PM

Tons of modules in my engine need access to this information. Input, GUI, camera, etc. all need to know things like window width and height, is it fullscreen, are there shadows, etc. In order to accomplish this, right now I'm simply passing a pointer to the ConfigurationManager around like it's a whore to all the modules that need it, and I'm referencing those configuration settings whenever I need to so that if the settings ever change in real time, the modules update correctly.


this is what one might call "inherently global data".


seems there are two basic approaches:


1. just make it global - not recommended for the faint of heart - makes the code less idiot proof. other modules are dependent on the globals, but its not apparent unless you inspect the code. but its does mean you don't have to pass globals into every method that uses them. once an accepted practice, this is now considered a poor practice due to the less idiot proof issues. still a viable option if you know what you're doing and the number of coders is small (like 1). really not recommended for dev teams with more than 1 coder or coders who haven't grown up with globals. seems the key to using globals is to declare global, but only access as though through an API. in the long run, using globals seems to save some typing in exchange for less idiot proof code.


2. wrap it in an API of some sort which other modules must depend upon. nothing has changed, its still data that lots of modules depend on.  but the API makes it more explicit whats going on.  thus more idiot proof code.  and greater readability.   currently considered the "proper" approach.  downside is you have to pass everything into every method.


the typical approach is basically what you're doing now. related data goes in some structure which is passed by reference to all modules dependent on it.

#5260376 The Big List of Good Design Practices

Posted by Norman Barrows on 03 November 2015 - 03:29 PM

Perhaps the correct statement is "don't clone unless it's going to make you money"


yes, that might be more precise. but then again, the same game with better marketing is  sort of "doing it better".


guess it depends on whether you lump production and marketing together. but this thread is about design, not marketing, although both are integral to the financial success of a title.


popular games types with little or no replay value might be a good category for cloning. fans of such games require a never ending supply of new titles to play through.

#5260312 The Big List of Good Design Practices

Posted by Norman Barrows on 03 November 2015 - 08:09 AM

* worry about the stuff you DON"T know how to do, not the stuff you know how to do.


* figure out how to do everything you don't know how to do BEFORE committing to the project. if there's not a clear path from point A (original game idea) to point B (gone gold!), find a clear path before you begin your journey, or you may find yourself going down the garden path.


* always try to think through and think ahead, and extrapolate the ramifications of all design choices, including how they will interact with each other.  i find that good modeling of small systems often leads to realistic dynamics between systems, without intentional design or code to do so.


an example from caveman 3.0:

1. you can butcher a kill, which requires time.

2. wilderness encounters are random.

3. predators will go for a carcass before live game.


combine 1,2 and 3 and you get predator encounters that steal your kills! just like in real life. totally unplanned. never occurred to me that "hey, predators ought to steal kills". some might consider this emergent gameplay. i just consider it good simulation modeling - as this sort of thing happens quite often when developing hard core simulations.


* only clone a game if you can do it better than the original. never make a game that's already been made, unless you can do it better.


* i find there are two good tests for whether to make a given game:

1. "wouldn't it be cool if there was a game where you could <do whatever>...."   if such a game hasn't been done yet, it may be a good candidate.

2. "i could write something better than that!"   if a game has been done, but you know you could do it better, it may be a good candidate (1)


* pay more attention to UI design. many games suffer from "less than best possible" UIs. understandable, easier to use is typically more work to implement, and it gets you no additional gameplay value, its just reduces player frustration when dealing with game UIs that are not "frictionless" (as Johnathan Blow would say).






(1)  this is how i became a gamedev. me and my buddy downloaded and checked out all the star trek games available at the time (1989?). after checking them all out, i said "i could write something better than that!". in six weeks i had. the game was a top 10 download on AOL, and checks started rolling in.

#5260307 The Big List of Good Design Practices

Posted by Norman Barrows on 03 November 2015 - 07:37 AM

Document every issue, as minor as it may seem. Lots of bugs can be forgotten because "I don't have time for that now, will look at it later"




can i +2 that? <g>


Use programmer art for as long as possible so you can concentrate on the gameplay design and core mechanics without getting bogged down in appearance. 


i might even go farther and say use placeholder art until all gameplay code is done, and all that's left is graphics and audio.  i personally try to do final graphics last.  

#5260231 Armour penetration and firearms

Posted by Norman Barrows on 02 November 2015 - 06:28 PM

There is no room in my game for two different kind of amours though...


so decide what kind of armor your armor will be, then use Gian-retro's example as a guideline. i've live fired all the guns on that list except the assault rifle (got the scar from the scope on .30-06 w/ Mauser action to prove it - kickback that first time you ever shoot one can be hell) , and the numbers look pretty good to me. 

#5260216 The Big List of Good Design Practices

Posted by Norman Barrows on 02 November 2015 - 05:24 PM

here's some i would put on the list:


* begin with the end in mind.   


* don't dilute the vision / remain true to the vision. if you have no "vision" or don't know what the "vision" is, then just what the heck are you building?  a bunch of mechanics is no more a game than a pile of bricks is a house. ref: "a pile of bricks is not a house".


* don't make arbitrary design choices.  be adaptable.  goes for both design and implementation.


* don't be afraid to stop work on a concept that's not working out - whether its a design or an implementation.


* when all else fails, go back to the drawing board.

#5260213 The Big List of Good Design Practices

Posted by Norman Barrows on 02 November 2015 - 04:49 PM

- implement the victory condition as quickly as you can


this assumes a victory condition. not valid in all cases.




- is the game fun? If not, redesign. Assure it at the early stage of the prototype.


if the core aesthetic is not fun, messing with the "mechanics" seems to me to be a somewhat haphazard way of trying to stumble on something that's fun.

if it were me, i would not redesign. i'd move on to the next game concept to see if it holds more promise. only if i were out of ideas and were desperate to release something for cashflow would i return to a less than promising project to see what i could do with it.




- make one game at a time (throw away all other games in progress)


working on one project day in and day out for long periods of time can lead to burnout. having a second project (IE the next title) to work on gives you a break, yet keeps you productive. 




- do not add new features to fix things, it almost never works!


new features by definition can't fix broken existing features - IE it NEVER works.  they are a workaround at best.




- removing things can do miracles


don't experience that one myself much at all.  i might counter with "don't add things until obviously necessary", then you never need to remove things, unless design changes make them obsolete. i'm lazy, so even the thought of having to type even one keystroke of code i don't know i need is very against my religion.



- KISS! Do you remember one game you made that was not too complex? Just one? No! In the end you always end up throwing away the code and finished features anyway because these didn't fit or were not fun, give yourself a break and don't implement these in the first place.


never happened to me. and i'm on my 35th game or so (that's all of Rockland's titles, all major versions). like i said, i'm lazy. i don't put stuff in unless i have to.  and i always try to do things as simply as possible. but there was this one time in Caveman 1.0 i spent a few days figuring out how to make a top down camera zoom all the way out to space, only to realize that with top down view you couldn't see the sun to tell what time it was. so i shelved the feature and got on with it. some ideas work, some ideas don't. that's what whitepapers and rapid prototyping are for - to figure stuff out before it ever gets on the todo list, much less implemented. but i have shelved an entire project once - armies of steel II. not sure whats wrong. i think its a play balance issue. but i have many other titles on the drawing board or in the pipeline that show more promise, so i'm not desperate enough yet to revisit it.




- if something is not working try to remove some originality/uniqueness (especially for non primary features) and try to clone it (yes, it sounds bad, but it WORKS!), your game does not need to be 100% original (actually, it shouldn't, it will be unfun, overly complex and confusing)


i tend to design games from the top down, starting with a vision of a core aesthetic. this vision then naturally leads to the definition of "mechanics" necessary to implement the vision.  since the vision defines the mechanics, all the mechanics, original or tried and true, tend to be necessary and proper.   i have never come up with an original mechanic then tried to make a game of it.  i suspect one couldn't get much further than some kind of arcade BS that way (no offense to the arcade gamedevs out there).  not that such a thing might not sell well. in a universe where things like flappy birds can happen, anything is possible. 


here's how i do it:


i start with a vision.


had one just the other day: bulldozers vs dinosaurs. FPS.  arena combat, or better yet maybe branching storyline mission based.  your crew is dropped on an island to start work on a new beach resort. but there's dino's in the jungle. then its front loaders, back hoes, and bull dozers, vs t-rex etc.


or make it a squad of mechs. dropped in from air transport to secure a supposedly deserted island for a new base. very first night, the raptors or some other critter takes or destroys the long range communications gear.  either scenario, its days, or weeks til help arrives. the player must complete the missions, with best success leading to rescue. i'm thinking single player, with a crew of followers, and some character development, to give greater meaning if  one of your crew dies in some branch of the story line. i have this vision of this huge dino bursting through the trees and ripping the cockpit of a mech clean off in its jaws. probably a cut scene where you lose your number 2.


 so you need an island, and mechs or bulldozers, and dinos, and missions. i have terrain chunk generation and render code i can use. and skinned meshes are now part of rockland's Z game library. turn the crank - out comes another game. stuff like that's easy to do. its not historical simulation, so no in-depth research required, no stringent realism requirements. indoor outdoor shooter levels, branching storyline mission based, nothing new there. if one had assets ready to go, one could probably rough out something like that in a week in unity i would imagine - assuming one was familiar with unity of course.  i could definitely do it in a week with rockland's Z game library if i already had assets. 


you see how designing a game this way pretty much precludes the inclusion of contrived mechanics in the design. its not about mechanics. odds are no game more sophisticated than breakout is about the mechanics. in this case its all about the coolness factor of dinos vs mechs in realtime 3d combat. mechanics is just a means to an end. odds are mechanics should not BE the end, and odds are they should not be what a game is about / built around. once you get past stuff like tetris, mechanics are not what the game is about. they are just how it works.


i can't even think of a game built around a mechanic with no aesthetic. wolf3d:  shooting nazis, pacman: eating fruit and chasing ghosts.


tetris - that's a pretty "purely game mechanics" game.  but that kind of stuff (design around a mechanic) only gets you as far as arcade type stuff it seems - and no farther along the evolutionary scale of game types.


unless you use the "mixing bowl" approach to game design: throw in every cool mechanic you can think of, stir (perhaps vigorously) , and surely it'll be fun.  reminds me of grabbing random ingredients from the kitchen, mixing them up, and thinking it'll automatically taste good. when we all know from real life that a random sample of ingredients in the average kitchen seldom go together - such as dry breakfast cereal and tomato ketchup, for example.


[edit]  FYI two random foods that DO go together although you might not think so: of all things - believe it or not - Budweiser and cheesecake - no lie! <g>.

#5260018 Which is the more complicated mechanic: Set-in-stone, or build it yourself eq...

Posted by Norman Barrows on 01 November 2015 - 01:39 PM

Yes, that I understand, but would it be more costly and require more resources that hard-coded weapons?


depends on your definition of costly:


1. a weapons design system will require more design time to come up with the rules, than it would to come up with the rules for a set number of hard coded weapon types. balanced rules that make sense and work with the rest of the game are vital.

2. additional weapon design UI screens are required, this requires additional UI design time. a well thought out and thoroughly tested weapon design UI is required.

3. more code required to implement. both the rules and UI screens.


graphics can use a shared pool of resources to draw weapons using a CSG type approach. you might actually end up with more weapon combos possible for a given amount of graphics assets than with hard coded weapon types and graphics for each type.


audio can use a shared pool, but doesn't "CSG" as nicely as 2D sprites or 3D meshes. realtime mixing can be used to expand the number of sounds you get from a given number of wavs, but results may not be impressive. so the total number of sound effects can be a limiting factor. and thus an area where you may want more assets to work with, which means creating more assets, which is more work.

#5259990 Need help with where to start for a game idea

Posted by Norman Barrows on 01 November 2015 - 09:20 AM

I don't even know what engine I would start with for the grand scale portion of the game, which is kind of my issue,


try googling "wargame engine"


info on the gem3 engine:


#5259988 Which is the more complicated mechanic: Set-in-stone, or build it yourself eq...

Posted by Norman Barrows on 01 November 2015 - 09:08 AM

obviously, variable weapons (IE weapon design) is going to be more complex to implement that hard coded weapon types.

#5259987 Armour penetration and firearms

Posted by Norman Barrows on 01 November 2015 - 09:00 AM

with just two types of armor (none or have some), and perhaps a dozen weapon types, a lookup table is probably the way to go, IE the good old fashioned wpn vs AC table concept from classic D&D.


the table should probably show % dmg done, from 100% to 0%, depending on the particular wpn vs armor combo in question.


the trick is setting the percentages in the table to believable values.


a list of the exact weapon and armor types would be required to come up with believable percentages. - along with some knowledge of munitions and armor.


percentages would be better than fixed DP values. that way no base DP value is assumed.  IE a -10dp penalty assumes a 100dp weapon, whereas a -10%dp penalty works with any weapon, irregardless of its base DP.


FYI, to this day, the only weapon that can penetrate any body armor is the arbalest firing a bodkin point bolt






youtube has videos of modern 200lb draw force xbows almost doing it. imagine what a 5000lb draw force xbow would do!