Jump to content

  • Log In with Google      Sign In   
  • Create Account

Norman Barrows

Member Since 04 Apr 2012
Offline Last Active Jun 22 2016 05:38 AM

#5295829 are vidgames disrespectful of player's time vs tabletop RPG's?

Posted by Norman Barrows on 09 June 2016 - 11:34 AM

i've recently been noticing ways that video games, such as RPGs and shooters can be disrespectful of the player's time when compared to tabletop RPGs.

 

a quick example: leaving the dungeon cause you can't carry any more loot.....

 

skyrim: manually walk all the way back using continuous move. you can use console cheats to accelerate time. 

 

classic D&D:

players: "we leave the dungeon"

ref: "ok..."  (does some random encounter checks), "you've left the dungeon. now what do you do?"

 

in skyrim, there are no periodic random encounters, so where's my "leave the dungeon" button?  i mean WTF? has nobody ever thought of this?

 

and exploring...

 

skyrim:

continuous move, jog or ride a slow horse across the world in real time - and wait until you run into something.

 

classic D&D:

players: we go west

ref: "ok..."  (does random encounter check)  "you travel one days journey west and see nothing of interest. cross off a day of food. now what do you do?" and just like that you've traversed a distance the equivalent of crossing skyrim 4 times in less time than it takes to jog 100 yards in skyrim. 

 

would we be so enamored of realtime exploration on foot or horseback if it was all greyscale shaded and cubes? 

 

the next time you  play a game, picture it in greyscale and cubes, except for glowing green cubes for the things you can interact with in the world. this is what the game looks like from a gameplay point of view - which is usually much less than what you see drawn on the screen.

 

i suspect that games should really be build that way first, to ensure the fun. then you can put a pretty paint job on them.




#5295790 Parkour Game

Posted by Norman Barrows on 09 June 2016 - 08:33 AM

>> Super Jump Pads (Basically a pad that launches you in the air.)

 

Gian-Reto's got you covered there, just add some extra y velocity to the jump.

 

>> Some sort of support for scenes to be added by other users (A way for you to launch downloaded scenes)

 

its unity, just let them load their own levels.

 

>> Properly licensed Adobe Creative Cloud

 

photoshop looks to be the only truly useful tool there. photoshop's a no-brainer. the rest you can probably live without.




#5295784 Scale entity dynamically

Posted by Norman Barrows on 09 June 2016 - 08:12 AM

sx = desired width / texture width

 

sy = desired height / texture height

 

remember that blits are based on the center, not the upper left corner. you'll have to adjust accordingly.

 

so if the screen is 1020 pixels wide, and you want 8 bricks across the screen, that's 1020/8=127.5 pixels wide for each brick.

 

if your brick texture is 256x256 pixels in size, your sx = 127.5/256 = 0.498046875.

 

checking your math...

 

a 256 pixel wide texture scaled by 0.498046875 would be 256*0.498046875= 127.5 pixels wide (correct).

 

8 bricks at 127.5 pixels each = 8*127.5 = 1020 pixels (correct).

 

note that you can't blit at x=127.5, only at x=127 or x=128. so you may have a bit of overlap or a gap at the right edge depending on how you handle rounding off the x coordinate for the blit. probably better to use an integral size for "brick width in pixels".




#5295771 Feedback on HeliHavoc

Posted by Norman Barrows on 09 June 2016 - 06:29 AM

downloading now.

 

first thing that jumps out at me is model and ground quality. your sky is looking AAA. the rest - far from it.

 

if you think about it, all 3d games are the same, the only difference is the quality of the meshes, textures, and special effects.

 

and out of those, i think i'd have to say that textures probably make the most difference. after that, maybe lighting?

 

ok, checking it out....

 

sidescrolller - like a slow version of defender (1981) with no bad guys and no guns, and a very fragile ship.

 

defender5200Screen.jpg

 

no ESC for ingame menu to quit!

 

no textures at all!

 

seems the only game mechanic is flying - not enough for the player to do - not enough for them to master. i figured out how to fly the thing on the third try, then is just a matter of having patience. if you'd told me what keys did what, i would have only crashed once. and if i had an altimeter with rate of climb (like a real chopper) i wouldn't have crashed at all.

 

it might help if you said W/S/up/down  was ascend / descend. i assumed it was forward / back and i had 6 degrees of translational freedom - not just 4.  otherwise i would have probably only crashed once, to learn how softly you had to land.  

 

altimeter with rate of climb / descent is called for.   a chopper pilot should not have to guess how quickly they are descending and if its outside the safe operational envelope of the vehicle.  of course, that's about the only challenge in the game to begin with. so you add that and then you have a 2d chopper flight sim with a difficult camera angle, no gauges, and basic graphics. and all you can do is fly around. doesn't sound like much fun to me.

 

the plane should not move left or right if they are on the ground. at first it seemed i had 4 degrees of translational freedom (fwd, back, left, right), and the chopper would climb automatically.

 

much probably has to do with the fact that you're using a true 3d engine to do a 2d side scroller. if i see something that looks like a flight sim, i expect it to act like a flight sim, not mario.

 

in general, non-chase-cam 3rd person views of flying vehicles are difficult to use.   with Zaxxon (1982) being one of the first examples of such games.

 

"those who do not learn from the past are doomed to repeat it"

 

zaxxon_remake_02.png

 

 

so what you have is a slow version of the movement mechanics of a 35 year old game (but no badguys, combat, weapons, or shields) , and the difficult camera angles of a 34 year old game, and the graphics of a <how ever many> years old game.  Zaxxon is 34 years old and is gourard and phong shaded 3d polys, so <whatever> is at least 34 years maybe more. OTOH, i think the original arcade version was monochrome, and only later ports had color.

 

FYI, in defender you had to fight the badguys WHILE picking up people!

 

right now, what you've got now isn't even SIMCopter (Maxis 1996), which wasn't all that.  but you might want to take a look at it for ideas for additional types of non-combat game play. its a police chopper sim, and expands on the basic pickup / drop stuff without adding weapons (near as i can tell).

 

hqdefault.jpg

 

 

to improve the havok chopper title, i would switch to payer's choice of chasecam or "from the driver's seat" view, adjust the flight model and input controlls accordingly,  kick it up to 6 degrees of translational freedom, and at least one degree of rotational freedom (rotate left/right). add textures, add basic gauges (speed, alt, rate of climb), and add greater challenge - combat or time limited missions are about the only options there. and flying a chopper to "beat the clock" doesn't sound that exciting compared to weapons and combat - especially when you could have combat AND beat the clock AND pickup stuff at the same time. now THAT's a challenge! of course, if you follow that to is logical conclusion you end up making the spiritual successor to the game series Comanche by NovaLogic (1992) - best known for its groundbreaking use of a voxel terrain engine, and its realistic chopper flight model - still considered one of the best ever in the industry.

 

hqdefault.jpg

 

 

nowadays, you want to impress people, you gotta think big dude.

 

 

 

.




#5295765 What to do with extra ideas?

Posted by Norman Barrows on 09 June 2016 - 06:12 AM

>> Should those ideas just be forgotten, should they be translated/ simplified into something smaller and more manageable?

 

they should be added to your list of "possible solutions i'm aware of".

 

but do not pursue them until:

1. you need them for a game. then learn how to implement them.

or

2. you have nothing better to do than learn how to implement them (rather unlikely - there's always something else to learn in game development).

 

 

 

for actual ideas for a type of game, as tom sloper and sun and shadow are referring to, i jot down the game idea on a piece of notebook paper, and toss it in a manila folder with the other 50 or so game ideas i have on file.    

 

but usually, if its a good idea, i'll think about it from time to time for 2-4 weeks, maybe make a few notes and do a little research, then stop my current project for up to a week and do a rapid prototype. it never even makes it into the game ideas file. 

 

so much to build! so little time!




#5295763 What licence allows for artists to transfer their IP to me?

Posted by Norman Barrows on 09 June 2016 - 06:06 AM

>> I hope this would be enough, until I form a real company and get signed contracts from them.

 

unlikely.

 

odds are you'll need a lawyer and a contract for them to sign before they even turn on their PCs start working.   or you could be hating life later.

 

one alternative is a network of sole proprietorships.  every team member is a separate business.  when an artist delivers an asset, they sell it to you outright. you pay them, or owe them money. and now its your bitmap, not theirs.  no contracts. just simple bills of sale and possibly IOU notes. if you want to pay in royalty percentages, or "shares", you'll probably need a contract. but for simple cash and carry transactions between two individuals, a bill of sale is sufficient, just like buying a used car directly from the private owner.




#5295705 creating good quests for games

Posted by Norman Barrows on 08 June 2016 - 06:47 PM

i'm currently working on the quest generators for my Caveman FPSRPG project.

 

I've spent a couple of days checking out the info available online about writing quests for games.

 

i'm not talking about the backstory for a quest.

 

about the only info i've found of use is that you should define a final goal and simply check for possible success and failure conditions and that's it.  the player should be able to meet the success or failure conditions by any means of their choosing which is supported by the game engine.

 

to provide more ways a player can complete a quest, goals should be stated in the most generic terms, as in "stop the wolves from attacking the flock" which includes possibilities like fences, running them off, finding them another food source, casting a sleep spell and relocating them, etc. vs "kill the wolves attacking the flock", which leaves zero player choice when it comes to ways to complete the quest successfully.

 

beyond that, the goal should probably be "epic" - making the quest an "adventure", as opposed to a trivial or mundane goal, which makes the quest a mere "task".

 

everything else seems to be related to writing backstory or "color text".  with nothing much on making quests with good gameplay as opposed to making quests with good backstory.

 

anyone have any other suggestions besides:

1. having just a generic final goal

and

2. making it an epic goal

 

?




#5295603 Need some advice or direction on a Mod friendly data structure.

Posted by Norman Barrows on 08 June 2016 - 06:18 AM

while not directly related to data structures used, one thing i've noticed is it seems the lack of UUIDs can cause conflicts between different mods.

 

i suspect bethesda designed the engine to be moddable from the get go - to the point that the game itself is simply a very big mod. as are each of the expansions. its sort of data driven design taken to the extreme.  with a generic highly data driven engine, modding is easy as the whole thing is driven by "mods".




#5295537 responsiveness of main game loop designs

Posted by Norman Barrows on 07 June 2016 - 04:15 PM

>> On Windows, the Keyboard, Mouse and USB game devices use an event queue

 

do you know off hand if that's hardware driven or polled? hardware driven, id imagine. it can't miss a keypress can it?

 

as i recall, getasynckeystate is a hardware driven "state lookup table".

 

googling...

 

well, looks like its one of those snapshots that returns 2 bits, but its not preemptive multitasking compatible, so you can't count on the 2nd bit (another task might eat it first), you can only count on the current state. so that would seem to imply that it is a hardware driven state lookup table, and is prone to missing keystrokes if not polled frequently enough.

 

and the message pump is a hardware driven event queue, but with no time stamps... 

 

all you can say is "these things occurred at some point between now and the last time i checked the queue."

 

seems there's no easy answer for that.

 

well, at least my original question was answered. nobody came up with an example of a different order at all, much less one that didn't introduce lag. i suppose that makes sense. if you have to do each step A thru E in order, then ABCDE is the shortest path - whether its all on one thread or spread across two (one, then the other).




#5295476 responsiveness of main game loop designs

Posted by Norman Barrows on 07 June 2016 - 06:12 AM

someone here or on another recent thread was mentioning button presses on the order of 10ms. at 60Hz, you'd poll every 16.6ms. and polling would take less than 1ms most likely. so you could poll at t0=0ms, finish polling at t1= 1ms, press the button at t2 = 1.5ms, release at t3=11.5 ms, and the next poll occurs at t4=16.6ms. and just like that you missed an input entirely.




#5295472 Using game graphics from old games

Posted by Norman Barrows on 07 June 2016 - 06:04 AM

>> Ultimately I'm just looking to release something simple with minimal hassle if possible and I don't understand what the bounds of what I am allowed to do are.

 

simple, if there's any question whatsoever about legal to use status, don't use it and find something else. don't even waste your time and money trying to license the stuff, just go download some PD sprites or licence some stock artwork and get it over with.  questionable assets are only useful as in-house only placeholder graphics. and even then there's a risk that copy with illegal content will leak out.

 

right now what you have is 100% illegal and the work to use it legally is almost definitely not worth it.




#5295469 How can i create a Cockpit as first person view

Posted by Norman Barrows on 07 June 2016 - 05:49 AM

>> For practise to implement a cockpit, i will build a new, cleaner and easier ship design

 

you will probably want the ship and cockpit as separate models. draw the cockpit when in first person view from the interior of the ship, and draw the model for exterior views.

 

and you don't have to model the whole cockpit, just what the camera can see. in combat racer i used 3d cockpits with non-slewable view and got away with just a front and two sides for a cockpit.




#5295467 How can i create a Cockpit as first person view

Posted by Norman Barrows on 07 June 2016 - 05:45 AM

>> I would try to implement a 3d cockpit (front view, upper view and both side views) in my spaceship and set up the player view/camera nicely in it. 

 

that's the basic idea.   you'll need to limit the camera rotation to those angles the head could turn, IE 120 degrees left and right, and 90 degrees up and down.

 

>> Additionally i could set up a mouse button (Middle mouse) to enable free view in my cockpit.

 

that might be too easy to accidentally trigger during combat. a keyboard binding might be better.




#5295461 use ID or Pointers

Posted by Norman Barrows on 07 June 2016 - 04:43 AM

i use arrays of structs as memory pools, and use the array indexes for the IDs. to load or save, all i have to do is read or write the array - no pointer fixups required at all - just load'n'go.

 

i use memory pools and IDs for:

static mesh assets, skinned mesh assets, texture assets, material assets, WAV assets, player entity instances, non-player entity instances, NPC instances, action types, object types, skill types, quest types, quest instances, and probably a few other things that don't come to mind at the moment. they all use IDs. quest types are the only thing that doesn't use a memory pool as well - quest types are pretty much 100% code (init, run, get map marker locations, get treasure location, select quest, view quest - that kind of stuff).




#5295240 responsiveness of main game loop designs

Posted by Norman Barrows on 06 June 2016 - 04:15 AM

from the comments here it would seem that polling fast enough to catch short key presses is also an issue.






PARTNERS