Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

461 Neutral

About tim_shea

  • Rank
  1. tim_shea

    Quantifying insanity.

    I think we're sort of talking past each other at this point. In any case, I love survival games and psychology so I look forward to playing whatever you come up with. Best of luck!
  2. tim_shea

    Quantifying insanity.

      So, this is not strictly true. In fact, there are entire genres built around accounting for exactly that. To be sure, game design based on player immersion is much more artistic and subjective than game design based on systems, but it is definitely not out of reach.     Player immersion is not something that the player chooses to engage in. They have to set the conditions for it, but you as the developer have to actually create it, if that's the route you want to take. And keep in mind, it may not be the best option. Immersion and entertainment are orthogonal attributes of game design. Particularly in a sandbox or procedural game, it could be incredibly difficult to construct an immersive experience, and even if you did it might not be as entertaining as a more rule-driven experience.
  3. You should definitely give some thought to dependency inversion. Circular dependencies can very easily become problematic in the future. Unless there is some reason not to abstract out an interface, it would benefit you to do so.
  4. tim_shea

    Quantifying insanity.

    It's fairly clear to me that you've put a lot more thought and [research? personal experience?] into the fine points of this mechanic than the average forum reader, so I'm not sure if you're going to gain much defending your ideas against the superficial criticisms we can provide.   Nevertheless, here is my superficial criticism: it seems like you haven't made a clear distinction between the "real" mental health of the avatar and the perceived mental health of the player.   If I have a lot of concrete statistics to manage and specific rules and interactions to consider, along the lines of a pen and paper rpg, then I expect to be loosely bound to my avatar. I get plenty of information (more than he would reasonably have access to, e.g. his precise level of healthiness) but my means of acting on that information are mediated by the rules of the game and his current state. A crazy avatar, in this sort of game, might do things I don't expect.   On the other hand, if I am forced to perceive things exactly as the avatar does, then I would expect to be more tightly bound to my avatar (there should be relatively few cases where I don't have control) but at the cost of my unrealistic introspection with respect to statistics. In this sort of game, I would not expect my avatar to go crazy, so much as the game to try to convince me that I was crazy.   Both could be enjoyable games. In the past, I've played survival games that hewed towards either side (not with respect to mental health, just in general), and enjoyed them. But a sort of middle ground option might easily get confusing.
  5. tim_shea

    My world driven game idea

    In my game engine architecture course last year, about 3/4 of the teams were unable to get even two-player networked games to work, whereas almost everybody was able to implement the full scene graph structure, physics, spatial sound, animations, etc.   Networking makes every aspect of your game more complicated.   Minecraft was not multiplayer in the early alpha. It was only later (as the game became a sensation and raised many millions of dollars) that a lot of the features you see today were implemented. It's also just generally not a great model for game dev, because it was such an unusual case. Is it possible you will pull off what Notch did? Yes. Is it likely? Definitely not. Much better to set your sights on something firmly achievable and then branch out.   Edit: On a different note, I like the concept. I would say prototype it and see which elements are fun and which aren't.
  6.   Leadwerks 3 supports mobile platforms, but the latest update does not. I don't have much experience with mobile games, so I wouldn't want to make a bad recommendation.   Personally, I would probably go for a more traditional app framework for augmented reality, rather than a game engine. There is a whole lot going on in most engines that you may not have any need for.   Actually, earlier on Saturday I spent a while discussing some geo-gaming ideas with a group of devs, and one of them mentioned that Adobe Air could do a native app camera overlay kind of thing pretty easily, but I don't have any experience with it.
  7.   Thanks for your input. I didn't actually use the words hidden or hiding anywhere. I don't feel like Unity is hiding things, to the contrary, they actually have fantastic docs that do a good job of exposing things.   What I would say is that for me, when a tool recommends and most strongly supports a particular paradigm, impressions are going to be shaped by that paradigm, and I don't think it is unfair of users to do that. For example, it is possible to write procedural server-side scripts in Ruby on Rails, but that doesn't make it unreasonable to say "I'm not going to use Rails because I don't like MVC".   That being said, I appreciate your perspective. Implementing an object-oriented game structure may have been exactly what I needed to get my prototype working, it didn't occur to me try and completely bypass the game management components.
  8. Regarding the issue of player attrition, I think it makes sense to have mechanics that encourage loyalty and discourage disloyalty, but only to an extent. Keep in mind, some of the most disastrous losses and most spectacular victories in human history have been due to political rather than tactical maneuvering. Also, desertion in battle and uncoordinated retreats are primary factors in reducing the total number of casualties. Very rarely has a real battle resulted in 100% casualties, because people will naturally leave when they realize they have no hope for victory. This also introduces very important strategic options. Managing your own troops morale and the enemy's morale can be as important as managing their rations or ammunition. Rather than introduce an artificial mechanic for this, you could let human player's real emotions dictate the morale of their army.
  9. Josh, thanks for the input. CryENGINE is one I haven't tried yet. I keep meaning to, and then forgetting.
  10. No, Leadwerks does not offer a free version, and I am somewhat conflicted about that.   On the one hand, I think the actual cost of the software is incredibly reasonable. If you plan to actually produce any content (games, demos, whatever) $200 is almost negligible.   On the other hand, I got my start with games and programming by downloading free versions, and I enjoyed it so much that I'm now finishing my CS degree, so I think there are peripheral benefits when companies offer those options.
  11. Wings by Daedalus What is it? An artificial intelligence library for use in games. A set of tools to help you incorporate high quality intelligent behavior into your games without the headaches. Who are we? A team of five Computer Science majors at CSU Sacramento sponsored by Josh Klint of Leadwerks Software and advised by Dr. Ahmed Salem, Associate Professor at CSUS. What do we want? Game developers (that's you!) to share your experiences and priorities with respect to gameplay and artificial intelligence. Your feedback will help us shape the Wings library. Please take our six question survey: http://www.surveymonkey.com/s/MTFKQ9G For more information about the team and the project: http://athena.ecs.csus.edu/~daedalus/ If you have any questions or concerns prior to taking the survey, please feel free to post them here.
  12. tim_shea

    Monster thinking in an action rpg

    I don't think I agree with these sentiments, but the advice is good. Neural networks and genetic algorithms are among the most promising subjects in AI research. They are the only techniques with a good likelihood of producing real emergent behavior or machine learning. However, most implementations *are* unpredictable, training intensive, and unlikely to provide a whole lot of benefit in a typical rpg. I would say if you want to look at something more advanced than finite state machines or scripts, the most fertile ground would be production systems. These are kind of (not really) like a large collection of interrelated if-then-else statements. The idea is to build up a collection of productions (sometimes called rules) that represent all of the 'mental' considerations of the AI. In my opinion, this type of representation is much more authentic than a real-time plastic method like a GA or NN. Consider, during the course of a battle, it is pretty unlikely that a monster will be learning and incorporating a whole lot. It seems a bit more realistic to say that a monster or enemy has a lot of knowledge and experience (in the form of productions) that it brings into the battle, but that set of knowledge doesn't necessarily change a whole lot.
  13. tim_shea

    The Importance of Commenting Your Code

    [quote name='Ghosrath' timestamp='1338469974'] I can suggest a very interesting piece of reading material. Clean code by Robert C. Martin. Especially chapter 4 on comments is great reading material [img]http://public.gamedev.net//public/style_emoticons/default/smile.png[/img] Basically it states that every comment placed in code means that the code that is commented is actually bad code. Good code never needs any comments at all! Try this and notice how much easier you can find certain pieces of code, just because you don't need to read through all the comments A little quote: Quote Nothing can be quite so helpfull as a well-placed comment. Nothing can clutter up a module more than frivolous dogmatic comments. Nothing can be quite so damaging as an old crufty comment that propagates lies and misinformation. [/quote] Clean Code is an excellent book. Probably not for beginners, but once you've been coding long enough to groan when you look at your own code, it will help you see how not to. In particular, the concept of self documenting code (and unit tests as documentation) have done wonders for my style. If you can read each line of code aloud without feeling foolish you will almost never need to write a comment.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!