Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Feb 2012
Offline Last Active Jul 07 2016 07:07 AM

#5299257 Following the Train Tracks or Plumbing the Depths

Posted by on 05 July 2016 - 09:33 PM

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?

#5277323 Game Engine Architecture: what's after that?

Posted by on 21 February 2016 - 01:47 PM

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.

#5274878 Game dev theory pointers

Posted by on 08 February 2016 - 11:53 AM

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.

#5272046 Pathfinding and Databases

Posted by on 20 January 2016 - 01:52 PM

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!

#5271953 Pathfinding and Databases

Posted by on 19 January 2016 - 11:07 PM


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.

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.

If the room is 3x3 and has 16 edges then just move toward the goal in a straight line. There's no need for any complication. Pathfinding is only necessary when there are obstructions.

Incidentally, four more edges would complete that graph quite nicely.

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!

#5271889 Pathfinding and Databases

Posted by on 19 January 2016 - 02:15 PM

Just to add a bit to the pile-on: a common problem for novices is learning to differentiate what they think is a huge amount of memory usage from what the computer thinks is a huge amount. It sounds like you might be making a text-based MUD. In terms relative to modern RAM capacity, such a thing is extremely light-weight. On modern multi-gigabyte systems, you could likely have hundreds of thousands, if not millions, of rooms resident in RAM. I'd posit that you could at least have as many rooms loaded as you could conceivably create and flesh-out within the next five years or more, barring large-scale procedural generation.

I can remember working on MUDS in the 90s that had hundreds of rooms, took many hours to explore, and could be held entirely within the paltry RAM capacities of the day. Imagine how much you can do now.


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

#5271863 Pathfinding and Databases

Posted by on 19 January 2016 - 11:01 AM

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!

#5271827 Pathfinding and Databases

Posted by on 19 January 2016 - 08:13 AM

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.

#5269628 State Machine in ECS

Posted by on 06 January 2016 - 09:11 AM

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!

#5015990 [MMORPG] A new method of presenting the player a new kind of quest.

Posted by on 31 December 2012 - 12:29 AM

I think one of the main issues with questing in our current incarnation of MMORPGs is the link between questing and the need to gain experience/levels. In WOW, one could theoretically level from 1 to 60/70/80/85 (whatever max is at this point) without ever embarking on a single quest. There are enough monsters of a varied level to provide a constant stream of experience and levels, should you possess the patience to grind, grind, grind your life away.
In truth though, the majority of a character's experience comes from completing quests. Even the experience gained from the monsters killed during a 'kill x amount of ys' quest is paltry in comparison to the amount you get when the quest is done. Add in the randomly useful piece of gear and sum of money rewarded as well, and you suddenly begin to wonder why people look for anything else to do in the game.
It is all tied in together far too tightly, all to support the drive to level up and get better gear. "Gaining experience" quickly replaces the basic reason you started playing in the first place - to "experience the game."
I think we need to work on divorcing experience gain from questing. A player shouldn't be pushed into a series of repetitive, uninteresting quests simply because it provides the swiftest way from level x to level y. The way I see it, while the events encountered while on the quest would naturally provide a character some experience in one form or another, finishing the quest itself should reward said character in any manner other than experience gain. Money, property, reputation, story, more quests...anything but experience. I should want to do quests because of what it brings to my pleasure of playing the game, not so I can do more quests.
In separating the two, we would see the overall design of the MMORPG change dramatically. In order to keep players interested, designers would be forced to create more interesting quests, more worthwhile rewards, and a world worth experiencing.