• 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.

Theis_Bane

Members
  • Content count

    42
  • Joined

  • Last visited

Community Reputation

448 Neutral

About Theis_Bane

  • Rank
    Member
  1. I think it all depends on the type of player.  The problem I see with many games, especially MMOs of any sort, is that they tend to only shallowly attempt to cater toward different player motivations - Achievers, Socializers, Explorers, and Killers.  I enjoyed WOW immensely for a time, again until I realize how manipulative the exploration aspect of the world was when I attempted to explore beyond the boundaries of my quest line.  Entire zones bereft of any interaction besides aggression simply because I had no quests there.  And the story within quests had little bearing on the quest itself, outside telling you where to go and what to kill.  There was very little to figure out.  I never really EARNED anything.   To answer your point on lore...have you ever played a game so good that you just want to read anything and everything about it?  You keep looking for more and more information and explanations and history because you just can't get enough of the setting?  If not, then you're probably not an Explorer type.  For me, there have been a few games where all I've wanted to do was scour the Internet for theories and lore.  I've continued playing games long past the time when I've beat them because I'm trying better understand the BBEG's motivations or learn more about how the current political climate came about.   As for Google...you are ALWAYS going to have people who aren't interested in figuring it out for themselves, but you also have to have the people that DID.  Also, a lot of the problem with puzzle solving or figuring out tricks to monsters has to do with the fact that they are inherently game constructs, rather than lore constructs; in other words, they were designed simply as a way to change things up for the player, rather than something that appears to grow forth from lore or environment.  I think many players have grown to expect this from a game, especially early on when the game proves it to be that way, so instead of looking for answers within the game to solve the problem, they turn to Google.    Imagine instead, if players were given the ability to pen instructional manuals within the game itself.  This would take some of the strain off of developers by placing some of the responsibility of filling out the lore into player hands.  How To's and Walkthroughs will still get made, but they will be written as part of the game rather than a separate entity.  It's also another way for players to get famous, providing another draw for the Achiever type.  It would give a good outlet for the Explorer type, now that information is even more valuable.  Some lore would require adept Killers and Achievers in order to survive the areas where the information lies, and a good social network would be necessary to provide access to the each of these types.  To be honest, giving incentives to keep info in-game would only make the game itself and the networks within it more valuable and interesting.
  2. I've been playing RPGs and ARPGs and MMOs for years.  I've always been fascinated by a good story, but as I've grown older, the rails of a story can't kept my interest like it used to.  I think it came with the realization that I'm not really working for the story.  The designers created the game in such a way that it's not really an accomplishment to reach a specific mile marker in the game.  The whole game is setup in such a way as to give the illusion of a challenge, that everything is built around a specific pacing that - unless you grind, run from combats, or don't go out of your way to reach necessary treasures - you will almost automatically be just as powerful as you need to be when you reach any given challenge.  Now, this is an over-simplification of course, but not by much.     It was Skyrim, and the hopes I had for it, that finally broke my desire to play any new games.  In Skyrim, I hoped for a game rich in lore and mystery, but I found a relatively shallow experience.  I didn't just want a group of bandits to have taken over a mine; I wanted to know WHY. Who were they?  Why did they choose this place?  Were they actually doing any BANDITING? More and more, rewards felt like they were GIVEN to me, rather than me having earned them.  Sure, there was combat, but it all felt the same.  None of the monster felt like they had reasons.  None of the lore felt like it went anywhere.  I felt like I was just wandering from place to place, killing whatever showed up for whatever random loot was around.  It just all felt so....shallow.   I crave a game where more thought has been put into the HISTORY, the WHY, than the story the devs have laid out before me.  I feel like, with story, most of the time you are the only person who can save the world.  Everything is happening TO you, not BECAUSE of you.  Story makes me feel like I am being PUSHED toward something, rather than advancing willingly.  In most games, nothing really changes in the world unless you advance a story point, but this is a change you are not responsible for.  You are merely a pawn in the game of...well, the game.   I believe the next great incarnation of games, especially multiplayer and especially MMO games, lies in the shift away from story, and the shift towards history and lore. Progress will be earned rather than given.  You don't follow a quest line in order to get the key to the Onyx Gates, you study them, search out old books, sages, perform experiments, and finally, open it based only off the information YOU have discovered and the efforts you have put into to perform the right rituals.  Consulting other players with different skill sets will be required; and not just combat skills.  People will play the game JUST to be a blacksmith.  People will STUDY magic, rather than level up and get new spells.  Some zones will have secrets that may NEVER be revealed, and that's fine.    What do you think?  Do you see the value in a game with reasons, for how things got the way they are?  Or do you believe that the idea of a rail-road story will always reign supreme?  What would you like to see in the way of history/story?
  3. My advice is NOT to focus on one specific book. My advice is to first write an outline of what you want out of your game, then focus on what you need to do to make each part work - put something on screen, make a sound, process input - and then just start coding. There is no better experience than to learn by doing, and failing, and adjusting, and redoing. Seriously, NO BETTER EXPERIENCE. Start looking at different sources of information only when you come across a specific problem you want to solve. Then, when you starting reading, read MANY different peoples' solutions. Best thing I've ever read in the programming book. There is no such thing as a right answer, just many different less wrong answers to choose from.
  4. One of the best things I've ever read in a computer programming book was this: 'There is no one right answer to anything. Just a collection of answers that are each less-wrong.' Or something like that. Alright, stay with me. I'm going somewhere with this. I've been where you are. I'm STILL where you are. There are a lot of voices out there yelling out the proper way to do things, the best way, the most efficient, the cleanest, the least memory intensive... But programming doesn't always work that way. I've found, in most cases, making something work is infinitely better than getting it RIGHT. So I just did what I wanted. I came up with a game concept, and I started working. And I failed. Over. And over. And over. And over. But it's been a few years now, and my massive online text adventure that I'm working on is actually starting to look like a game. I'm still having to learn new concepts every day, but it's easier and easier with each new concept, and I understand them faster and faster. See, what I've learned about learning programming, is there are three stages to really understanding a concept, be that from a book or a forum or a teacher. The first stage is being able to look at some example or some explanation that's given and just being able to understand what the hell they are saying LOL. I'm talking understanding Vocabulary, intent, what the heck a semicolon is for. In the beginning, this takes forever. And when you're done, you're like well I'm never going to use that, not in my game. Why did I need to learn this? Because you don't really get it yet. This is just the first stage. The second stage is when you look at what they're telling you and you're like wow! That really makes sense. I see exactly what he's doing here. You look at it and you're like, I could totally put this in my game and use it. Like, the whole idea just makes sense. This stage is problematic because it gives you a false sense of security. You feel like you really learned something. And then when you try and put it in your code, you can't seem to make what they are doing work for what you want to do, because it doesn't really fit. It's his interpretation of his solution, and it doesn't apply to your problem. For me, I got stuck at this stage for so long because my ego told me I was smarter than I was LOL. Then I finally discovered the third stage. It wasn't until this year that I really understood the third stage. The third stage is when you can look at a problem and not only understand the verbiage and the terms, and not only understand what he's using it for and how it works, but you can understand the underlying theory and the implications of the knowledge. You can literally boil down what is being said to what is happening, and abstract that out to 200 different scenarios. This to me is the beginnings of mastery. Because you can look at their solution, and take that back down to the problem, and work from there toward your solution. When you first begin, the distance between stage two and stage III is massive. Like, you can't even see stage three and understand it even exists at first. Then one day, after going over some example for the 1500th time, you're like holy crap! And it clicks. And then every single time you get to a new concept that distance between stage two and three grows shorter and shorter and shorter. And then you can start seeing how different theories and different concepts tie together and everything just suddenly starts making sense. And it's awesome! You're like holy crap! And it clicks. And then every single time you get to a new concept that distance between stage two and three shorter and shorter and shorter. And then you can start seeing how different theories and different concepts tied to gather and everything just suddenly starts making sense. And it's awesome! My advice to you on that is, when you find a concept that you want to understand and implement, go find about 10 different people doing it their own way. Try to figure out what they're doing and why they're doing it the way they're doing it. And then really the more people you understand the closer and closer you will be to understanding stage III of that topic. But above all? Just get started. Program. There is no better way to learn than to try an idea, and fail at it miserably.
  5. No, no.  It's not problem.  I was a bit tired last night when I wrote that.  Woke up this morning and reread what I and you wrote and was sort of like....eh?  Didn't want to just delete it as I wasn't sure if it had been read.   As for the above, that makes sense.  Didn't realize I wasn't clear about loading my database into memory for calculation purposes.  Sorry about that.   I think I've probably got this figured out now.  Again, thank you for your time.  Apologies again for MY tone.  Back to the grind!
  6. Entries and exits of the room. Ah. I figured that may be what you meant. However, in my game, I would potentially need nine more edges on enclosed rooms, and.... A whole lot more on open terrain. I did that so you could have multiple doors on one wall, allowing players to enter and exit a room from multiple spots. Mad props on that graphic though.   EDIT - Holy crap!  I just found the other four edges INSIDE the room.  Blind as a bat...Thanks!
  7. No serious (read: shipped) MMO would store navmesh data in a relational database format. What you will typically find is some kind of custom binary format that describes a compact data structure. Most of the time that data is just read directly into RAM, potentially with some fixups for pointer addresses, and used from there.MMO servers typically have many GB of RAM available and sometimes even use a good chunk of it for caching and precomputation purposes. RAM is cheap and computers are fast. If you don't have profiling data to prove your performance assumptions, then those assumptions are worthless, period. It doesn't matter if you're new to game programming or have been doing it since the punch card era; I don't care what your intuition says, unless you've benchmarked the exact use case in question, you're probably wrong. There's a good chance you're dramatically wrong.As has also been touched on, some data is not relational by nature and storing it in a relational DB is just unwise at best. It isn't really a performance or efficiency concern in my mind, though. It's an appropriateness of abstraction concern. The more you cram into your DB without reason, the more awkward things are going to get.Trust your gut. Your gut says it would suck to store your navigation data in your database. So listen. EDIT - Reread after I've had some sleep, and now I feel silly.  Leaving the below as a reminder to myself to stop and think.  Thanks to everyone.   Alright, the tone of this response irked me, so I apologize in advance if I come across harsh. I'm not discussing ram. I understand that part. The vast majority of my game runs in ram. The database is only used for persistence. What I'm asking about is persisting navigational data. I can only work with what I know, and what I know is databases. I literally can not speak to any other method of storage when it comes to this because I'm not fully aware how it would work. If you have another suggestion, great. I would love to hear about it and learn. That's why I'm here. Not to mention the fact that I've already admitted to not really knowing the performance outcome, and believing im being overly conservative. I feel like, had you read my posts, you would have seen that. I apologize if I'm reading too much into this, but I read it six times and am having a hard time seeing this any other way.   There will be the possibility for obstructions, so I will need to account for that. I am curious though, where are the other four edges coming from? I only count 16. All this being said, I think I'm going to build a static navigraph class with nodes and edges preloaded, as all the rooms are generically shaped. This will allow me to plan a route with very little extra data needed to be stored. I will use my entities to shape the room how I see fit, like placing a 'hole' entity in a square and making it take up the whole square, so that the square appears blocked when i try to path. Thank you everyone for your time. You've helped more than you know!
  8.   I think this is my issue.  With all the 'quality of life' improvements I feel like I've made, it just seems like SO MUCH, to the point that I'm becoming worried it just won't run fast enough to be playable.  But...I don't know what I'm talking about in this regard so maybe I should just shut up and build it lol
  9.   I've made this discovery myself. I don't access the database directly often.  I separated my MUD out into many specific zones, which are only loaded into memory when a player enters them, and unloaded after a short period of time after the game detects that no players are present within them.  A zone is loaded and unloaded asynchronously so as not to interrupt the game flow.  I had assumed that, as part of that loading process, I would be loading a number of nodes and edges into each room in order to establish a navimap, but upon looking at that problem closely, I felt like the sheer number of nodes and edges necessary would quickly bloat the memory usage of each zone to huge levels, not to mention the absolutely massive table necessary to hold all those nodes and edges.  However, after reading everyone's responses, I think I'm just being too conservative, and my problem really isn't something to worry about.  I could be wrong, but honestly, I don't see how I will REALLY know until I implement it.  I would, however, enjoy seeing how navimeshes and the like are stored in a database for MMORPG's, as that would probably mirror my setup the closest.  Thanks again!
  10. The problem is, when you are learning by doing, it is often impossible to know what you need until you've built a large amount of code that works, and then move on to a new aspect. I wouldn't call it a problem, as for the large majority of my game, my database works perfectly. Unfortunately, I don't know enough about path finding to know how it's handled in large games or games of my type, so finding good solutions aren't quite as obvious to me yet. That being said, I'm slowly learning to adapt my understanding of database design and program design to make the two mesh quite nicely. I will say that I did my research going in, and for my design, at least for the part I could predict I needed, a database was a good solution. Thanks for the feedback!
  11. I guess what the experts think is trivial and what I think is trivial are two completely different things lol! And, to clarify, I am talking about storing edges and nodes for traversing WITHIN rooms, not between. From what I can tell, that's 9 nodes per room, with 16 edges. If I got crazy, I would also need to store directional info for each edge and weights (though I might be able to combine these last two I think). Just thinking about the amount of fields in that relational table makes me cringe hahah. But, mayhap I am overthinking things. As for why I'm using a database question, well, I understand databases and have designed my game around an entity/component structure. This maps quite well to my database. I think, at the root of it, is the lack of any real knowledge of just how much memory I'm going to be using. I've included quite a few little things, call them game experience enhancements, that I'm worried will just bog down the system. Servant, you talk about connections between rooms being quite low in memory usage, but my connections are their own components that store not only the room it connects to, but what feature it goes through, what space in the next room you arrive at, and the description you read from passing into the connection and the description you read from coming out the other side. I do this a lot in different areas to add depth to the game. I think I'm just worried about the capability of my system to perform, and as I've already had to do one complete rebuild when I realized the current design wouldn't fit my needs, I'm dreading getting too deep in a certain design before realizing it won't work. Thanks again for your input. After some napkin math, I realize I'm probably just being over cautious.
  12. I'm working my way through Programming Game AI by Example, and have come upon the section on graphs and pathfinding.  Now, my game has a very simple grid layout for each room: a simple 3 x 3.  I'm looking at this graph node and edge chapter and thinking, 'Cool, this should solve my pathfinding problems fairly well!'  However, as I use a database as the source of all my game info storage, and my MUD has a huge number of rooms, storing all those nodes and edges and such in a database seems like such a HUGE amount of information, and I've come to wonder if this is the proper way to go.  Any thoughts on my room layout and a good, efficient way to store and search the room for adequate paths?
  13. Just wanted to reply to close out this thread. The solution I went with is sort of a combination of your answers, with a few tweaks. Since access to each separate world and all my data was contained within the bulk of my GameManager class, I was concerned about having access to everything from inside my individual state objects without storing excess pointers to my GameManager in every state. Turns out I can just pass a pointer to each Enter, Execute, and Exit state for temporary use... I built a StateComp that controls an entity's current state and its transitions. My update loop just iterates through each StateComp and calls the current and global state's Execute method. It works awesome. Thank you both for your advice!
  14. Allllllllright, so.  I'm programming a server/client MUD in C# using a form of the Entity/Component design paradigm.  I've made a substantial amount of headway, even reaching the point where I can move about the world and interact with simple objects and other players with no problems or glitches.  However, I ran into some issues when I started learning about and implementing a state machine for AI purposes.  From what I can tell, the State Machine design in Programming Game AI by Example will not work for an Entity/Component system, at least, one like mine.  My basic design is as follows:   All of my components are managed separately by their own respective managers.  Each manager is instantiated in a Region object representing a specific area of the game.  I do this so that I don't have to load large amounts of data into memory in order for players to interact with the world.  Only regions with players are active.  Others update the database and are disposed of.  All components are in a dictionary keyed to the ID of the Entity that owns it.   My entities are basics classes containing their ID, their Region ID, a List of ComponentMap objects that describe the type of component and ID for each component it contains.  (this hasn't really been of any use yet, but I'm loathe to remove it until I'm sure).   Most of my 'system' code lies in my Game class.  This class handles the different regions, and has methods for logging in and out, character creation, updating client information, and so on.  I basically just pass around the currently focused Region and Entity, and do work.    I'm having a hard time wrapping my head around state machines though, at least in this context.  Since my entities don't hold any of their own data, a State Machine can't really do much.  I've run into a wall.  Any advice on State Machines in an ECS?
  15. I had an odd thought the other day. Say you had a continent level map, detailing the shape of the land, terrain features, and interesting locations. Now, say you wanted to be able to zoom in and out of that map to get a greater level of detail, but you didn't want to go in and draw out multiple levels of detail for every inch of the landscape. Would it be possible to generate say, beach shape, on the fly as you zoom in by using a seeded randomly generated number to calculate terrain variations based on the main image and previous zoom levels? If so, how would one go about calculating this? Am I even making sense?