Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Feb 2012
Offline Last Active Mar 13 2016 10:05 AM

Posts I've Made

In Topic: Game Engine Architecture: what's after that?

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.

In Topic: Game dev theory pointers

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.

In Topic: Pathfinding and Databases

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!

In Topic: Pathfinding and Databases

20 January 2016 - 07:11 AM


I am curious though, where are the other four edges coming from? I only count 16.

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!

In Topic: Pathfinding and Databases

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!