• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

1689 Excellent

About wodinoneeye

  • Rank
  1.  Isnt EMO a rejection/disengagement with general/normal society/culture?  The overt violence reaction you're talking about is pretty atypical behavior for them isnt it?      You might be able to make this some kind of psychological representation.  The 'emo kid'  could see thing in his head shown different from what they really are, but bringing this strong reaction (so to not be a pure sociopath out to destroy just for the sake of destroying things).   So maybe with the overhead view you could mutate the things seen on his 'missions' into the symbolic things he recognizes and wants to destroy/negate/deflect (false/artificial/manipulative things).   Even the actions themselves might not be what is being acted out (so they get mutated too into symbolism).   There also would be obstacles that get in the way (similarly symbolic).   Maybe you could transfer the external actions into the emo 'cutting themself' (or similar self damage)  - that way reacting to the 'wrong' things  witnessed (and thereby avoiding showing that overt barbaric destruction you specified that might get general condemnation if done in a game).  
  2. One case of earliest "mining" was of flint  (it can be found as nodules in chalk formations which are easy to dig) Other cases are 'good' flint rock having people coming from well over 100 miles away to obtain it (and work it locally (into cores)  to lighten the load to carry back).   Similar activities for obsidian (a volcanic glass) which was used for weapons (and tools)   Something I only heard within the last few years  --  that one definition of the 'new' versus 'old' stone age was that the stone tools were polished (that the skill had increased enough that significant decoration was possible)   Someone said agriculture wasnt 'stone age', but in many places it WAS before metals were significantly being worked   Consider that in pre-columbian Americas (ie - Mayan civilization) there were virtually no base metal tools (but alot of sophisticated copper/gold decorative objects) . Gold and copper can be found as 'native' (pure) state and be beaten to shape and cut, but were generally too rare/valued to make into tools.
  3. Caveman has an unusually large number of possible situations it responds to  - that's why i use a hierarchical approach to decision making - divide and conquer.  Although in the end, they all result in some combo of turning, moving, and attacking.     you can also use a 'less frequent check'   type of optimization where the lower priorities usually culled out still get run once in a while (particularly if the opportunity search uses ALOT of processing resources)   One of the problems with AI is that  even though you want to follow up on one (the last) decided task, that it is good to process the Current situation fairly frequently to have the behavior reactive to a suddenly changing environment (meaning lots of constant re-detecting/re-classifying/re-evaluating even when it results in no change).   And as the game situation gets more complex that processing increases geometrically.
  4. A mechanism to adjust priorities of different actions is an escalation graph (can also be modal if-then logic) where the priority increases as the needed resource inventory decrease.  Then the available tasks get sorted  under one metric - can be a metric  for this type of task (vs priorities for Immediate threats - which generally trump 'maintenance' by a magnitude.)   Calculating the priority may have additional factors  (like very close proximity making an opportunistic grab viable)   Ive found that trying to develop a  general metric to make these decisions is the hardest part of doing this programming (so you will need to be able to make adjustments while tuning the game, and a modal graph is fairly easy to adjust (versus an equation)
  5.     some kind of see-saw catapult fulcrum&lever   with you jumping on one end (to toss) or pushing something on the end from a higher level and possibly the things that get launched might pile so you have to launch several to fill the gap or load a second catapult to reach the final target.   an escalating set of more intricate combinations multiple   also different forces throw different distances  (the arc path) possibly fired to break a hole in a wall or kill something deadly (or trigger whatever required to advance)   maybe you bring the lever/plank with you and select which fulcrum to use   physics like YOU getting on the catapult and triggering something to fall and propel YOU lots of possibilities for such kinetic puzzles
  6.   Perhaps having a difficulty level control that allows the player a wide range to adjust as they move up in ability ?? Best play for the most players is a major goal, and that includes wanting them to do alot or replay, instead of giving up quickly due to too steep a learning curve and always facing too hard an NPC opponent. Trying to auto-determine a players performance to give 'Forgiveness' can be alot of difficult work if its to be more than just some simple progress metric system.  Making the NPC play less optimal is usually not hard (while making optimal NPC play with multiple strategies or adaptive strategy is the much harder task ).   Flexibility for play style also is good - some players (at times)  just want to have fun and not a challenge and cranking down the difficulty to survive to GET to the endgame can be a feature to please more players.
  7. Think of it as a pipeline where the game turn/time-increment gets passed through different phases and work is started on the next time increment once the current one is completed- all to keep as many CPUs/cores doing as much useful work as possible.   Some like the network threat are also for timely responses.  Another is 'divide and conquer' -  spliting up a processing type to be on multiple cores to speed that processing's completion.   Some processing like AI doesnt have to be restricted to a framerate/render schedule and can use longer independant processing to reach the decisions then used by whatever entities take action in the game.   How the data sets get handed off between the threads is a key part of the whole system  (data locks a key subject to understand)   The rule usually is one thread per core to avoid processing jobs fighting each other.  breaking all the processing 'tasks' up so they run at the right time and balancing the work splitup so one chokepoint part isnt causing everything to wait for it  to complete.   CPU affinity is a term you might be interested in looking up.
  8. If you are genericising this logic then you want some table based data to be provided to the if x<nnn then do X else if  x<mmm then do Y else if x < ooo do Z   else do A   decision making.    Then you can have other code adjust the table for nnn,mmm,ooo  to match circumstances/situation for each object making that decision (and even the X Y Z A action options).   The adjustment to the table doesn't have to be made EVERY cycle, only when things change sufficiently (potentially eliminating ALOT of AI situation/criteria calculations being done too frequently).
  9. See if you can apply some LOD (level of detail - by distance or if the object is in the oplayers view) to avoid unneeded processing. Far away or not visible doesnt require finesse, which you want greatly increase for nearby (ssen) movement.   Depending on how remote you might skip any interpolation between large steps BUT be ready for the possible switchover point where more accurate positioning IS needed.   The enemy AI system may be doing LOS (Line of Sight) determinations which might be useful to control a LOD mechanism.
  10. You might want to familiarize yourself with  Art Deco architecture   (has 800 pages of pictures of art deco from around the world)   and for the big city  aspect   :  look into how LA Noire did their cityscape  (a mix of unique landmarks and street layouts with alot of generic filler)
  11. How often is your server to be  sending the snapshot state sync msgs and the deltas in between them ??   IF the full snapshots are sent close enough  in time (like ~1 seconds apart) you might be able to make the delta transmissions truely  'Fire And Forget' (which I think commonly means : that they dont even need to be ACK'd or cached) and can be lost as they just smooth the movements  (they are deltas off the last (reliably sent) state sync msg and independant of each other).    
  12. 1)  rock paper scissors type   contest to vary more than the simpler     attack vs defense  mechanisms   2) sufficient randomness to mess up 'perfect tactics' and put a player on 'the wrong foot',  but leave open the ability to compensate to minimize the loss   3) modal situations where 'night turns to day' and vice versa, and reverses the advantages and disadvantages of the players resources   4) some way to make turns become 'terrain' for subsequent turns (where what you lay out know becomes a staging for future moves)
  13. You might want to convert  the 'native' type into something more like   mob/rabble -   and    light infantry  (troops trained for bad terrain)   and 'irregulars' - often fairly well equipt but with poorer 'morale' who fall apart faster when faced with casualties (and other control problems)   'militia' varies too much to have as a separate classification   'natives' can give a pretty good accounting when in the right terrain and situation     If you want sufficient complication you might also want engineers/sappers
  14. If you have sequence (index) numbers for the transmits (both directions) you can use the 'sliding window' method and reply with a Bit Array indicating  multiple ACKs in one msg    (you send back the highest complete ACK msg (base) index and then a bit array from that point - say sized 32 bits - marking '1' all the recv'd msgs .... NOTE --- the first bit is ALWAYS a '0' (miss) or the base index would advance to gobble a '1')  The originator then knows it can advance its sliding window upto that base index.   This is for single state sends (I used such as this on a generic low-level Reliable UDP Protocol).   The problem with piggy backing (the multiple state resend) is what to do when the compounded msg  grows too large (too many unACKd) and another strategy has to kick in (too much is being lost).   One method Ive heard of (that was use long ago) was to always send the   current state data  N   and include the  N-1  data for every transmission which generally gets rid of alot of losses automatically  (more loss than that you still need a way to handle).   Of course the delta compress  scheme is to cut back on data size transmitted and these mutlisends run counter to that. -   You then need a stepped escalation strategy to handle  communication degredation which requires lots of tracking on both sides and detection of the degredation to make the protocol  shift down  and later  back up  when it detects improvement.   At what point are these lost deltas irrelevant ??  The network Sender needs info to tell it what of the data is discardable (like position minutiae) and what isn't (like critical mode or activation events).   So the high level protocol needs 'Dont Care' status transmits to inform the other side about discards and 'quality shift'  in the protocol.     The Sender  also needs to have available alternate substitution data like position sync points (to send repeatedly instead of deltas) when 'jerky' is prefered to over-rubberbanding or resend packet storms.   This is the kind of stuff  about   needing the low level network protocol having to have more complex interactions with App level operations That also could include quality monitoring to do the degredation/capacity detection which then is signalled upto the Game App to make appropriate compensating adjustments at THAT level.    
  15. What youve described is the basic workings of the Neural Net system.   Usually the bigger effort is matching it to the game mechanism and the AI problem(s) you are seeking the NN to solve for you.   That fisrt includes  processing/interpretting of the game state (or sequence of game states) to classify and encode it in a form that works with a NN (as its Input)   Next is  what is to be decided by the AI, and what outputs (actions directives)  it needs to produce. (decode what the NN produces)   Those things can get quite complex depending on the game specifics   (like having inputs for 3+ turns back in a game so that the NN can detect a Trend instead of just a static single-situational analysis  (if thats the type of game it is....)   Next, you may have your training system, but what about how you acquire all the training data for that game (which again in complex games can be a monumental task)   You may have to adjust (fiddle with/trial and error) the particular solution NNs (the neuron counts, the layers, even breaking into seperate NNS for different sub problems).  You then need some method that PROVES the NN created  does (sufficiently) what you want it to.   Then the packaging into an operating game  - and testing it with real people (if they are the opponents) who dont always do what you expect . You may have to revise the capabilities of the AI upward to compete with the opponents (and modify and restart the whole proceess)   One consideration may be optimization - HOW the NN AI is used in the game. Ex- does it need to be run every cycle or can its results be allowed to work for a while - and then part of the logic might be to determine HOW often/when  the AI needs to be rerun . Some optimization methods may make use of cached partial analysis (the encoding part) to cut down on the total AI processing the NN will make use of.