Telcontar

Find it Here

 

I'm terrible when it comes to graphics programming but I have delusions of someday becoming competent at least with the concepts. I learned a lot from this blog post by one of the developers of Planetary Annihilation.

 

It's edifying to see that they are doing a lot of work to make their eventual product actually match the look and feel of their demo (which was created without any game tech in place, as far as I understand).

'Newbie designer' comment is a pretty good point.

Also, I'd say that anyone who plays a lot of video games knows about the shortcomings of computer opponents and computer teammates. Having people working both for and against you is more fun and will open up more engrossing interactions.

Lots of good suggestions above, and I'll sum them up with a major thought of my own: in the majority of apocalyptic stories, what prevents the survivors from living in harmony with one another? (hell, in the real world, what prevents us ALL from living in harmony?)

Answer: Resource scarcity.

Without modern technology, we could only sustain about one twentieth of the current world population - and that is without the undead thirsting for our flesh. There won't be enough food, water, fuel, weaponry, etc etc etc, for everyone. Someone is going to have to go without. People will fight for these resources, ESPECIALLY when "going without" basically means "starvation."

Place a lot of pressure on a group and you will get a lot of fractures. People will go off on their own, hoping that they can find more resources away from the giant group of resource-hogs they are currently with. Often, they will be wrong (at least, according to the chances of most zombie survival games).

It is Turing-complete.

Well, you'll find all sorts of neccessities in games programming so my suggestion is learn them all - eventually. Most CS courses will build up from the basics (which archanian listed pretty well).

Really, unless you know what kind of games you are going to be working on, it would be hard to say exactly what you'll need. Problems found in game creation are many and varied - if not just as varied as in any other field, than pretty close to it. Learn a variety of algorithms for a number of different applications (when would you use a stack over a queue? ).

Yeah, sorry. I know it's a pain in the ass kind of answer, but it's the best and only one I can give. Educate yourself broadly, and know where to go for answers to specific questions (I've forgotten most of what I learned in my CS courses, but I remember where to find it all again!).

Oh, and learn about hashing. Hashing is magical.

It has been said, but I will repeat for emphasis: anything you do has been done before. Maybe you knew, maybe you didn't, who cares. If you write your idea and it ends up being more derivitive than you thought, that is what editing is for.

Besides, sometimes what people want is more of the same. Just look at the state of major movie and book successes.

Barring any other knowledge about your data structure, you are going to need to fully explore all possible paths of production in order to know which is the most efficient. Thus, Dijkstra's algorithm seems like a good bet to start with. Imagine your edge weights as material costs instead of road lengths and it should be easy enough to apply.

I believe (though I'm not sure) that Gopher is referring to keeping a buffer of pre-loaded tiles around your character so they never have to wait for the game to load an area.

Depending on how fast your load/unload code is (which will depend on how much information is contained within each game location, among other things) there could be a non-negligible time from the load call to when the area is actually available in memory. Thus, you want to actually start loading the area a safe amount of time before the player would see it. Gopher seems to be implying a predictive model based on travel direction.

In a current design project, I'm toying with another solution; basically it boils down to loading a larger area. Instead of loading only the immediate surrounding area and possibly having to reload every time the player crosses a certain boundary (imagine a player moving back and forth across that domain boundary, incurring tile loads each time) I add another buffer.

Loaded area (try to imagine it as a square):
XXXXX
X___X
X_P_X
X___X
XXXXX

At any given time the game has a 5x5 supertile area loaded into memory. The player's view is substantially smaller than this. The Player (P) can move to any of the tiles denoted by underscores (within the X boundary, also loaded in memory) without incurring a subsequent load of any new space. When he does move into an X boundary, the loaded area moves so that the X tile moved into becomes the center of the new area - thus the player can return in the direction he came for a ways without the game needing to load again.

Of course, this basically trades larger load volume for lower load frequency, so it may not be optimal for all games and situations. If loading is fast enough, it might not be that big of a deal to just do a lot of it.

Just reading ATC's response scared the everliving shit out of me, and I was not (and never would) consider trying to build a new OS.

Well, I'm off to have nightmares of implementing malloc and free...

I believe this belongs in game math, as this concept is fairly advanced and really doesn't have to do with game programming more as it deals with the actual algorithm  If you need help implementing it then you can give us some code.

Ah, yeah. Probably correct. I don't go in there often because the title scares me.

If you're feeling adventurous, you can try to invent your own fractal method and write an article on how you did it, and thus push the boundaries on human knowledge and techniques.

Waaay over my head. I'm much more a "stand on the shoulder of giants" kind of guy - and not to see farther, but just so they can carry me along...

JTippetts (a member on Gamedev) wrote a procedural noise generation library and has some nice articles on his blog (check out his website too). In particular, this is a really good one.

Thank you!

EDIT: Seriously, thank you a thousand times over, Bacterius. That article is perfect, and I've only scratched the surface.

There are a couple others that may or may not affect your game. From a gunning perspective (not melee combat) shooting at an enemy from above increases the chance of hitting something vital, such as the head or the chest, rather than the legs or butt.

It also partially ameliorates the effects of bullet drop, as the bullet is already traveling downward, making aiming somewhat simpler. (note, it does not actually change bullet drop).

Whether or not you can incorporate these effects depends on the detail level of your game.

I am also very interested in/attempting to create an expansive, procedurally generated, persistant "living" world.

The most important thing to remember is that the player will only ever see a small part of that world, and wasting memory and CPU time on the vast amount of the world that is functionally irrelavent to the game experience is foolish. In the exact same way that a good graphics engine hides - that is, does not render - surfaces that the player cannot see, this kind of game must abstract away anything beyond the player's concern.

It is figuring out the form and function of this abstraction that has taken up most of my design time (concerning this project). The closer you get to the player, the more detailed the model should get, until within a certain distance you have true simulation of all the game elements around the player. For my world so far that includes things right down to plant growth and the rusting of a forgotten sword buried undearneath the ground. Of course, when the player goes far enough away, the plants no longer grow each "tick" nor does that sword rust (in fact, unless it was important in some way, the game will simply forget about it).

I am trying to strike a careful balance between remembering info the player has seen (those plants won't grow, but the game will remember where and what they were so the next time the player comes around they are the same, and it will update their "growth" since the last time they were seen) and what can be safely forgotten, like that sword. If it really is important - it belonged to the player, or it is a quest item, or magical, whatever -  the game will remember, and the next time the player comes around it will be right where it was and continuing to rust away.

If you get far enough away from the player, the entire world becomes an abstracted model, updated only periodically, and those changes will only be simulated again one the player comes closer. Figuring out the specifics is complex, and pretty damn fun.

The first thought I have is that, for this to be a "game" and not an educational simulation, you need a primary mechanic and a goal. If we run with the construction site thing, that gives us the goal - complete the building. It also gives us subgoals in the various jobs that need to be done, which is great.

Primary mechanic? Organizing your construction teams for maximum efficiency. Certain people don't work well around other certain people. Sometimes they rub each other the wrong way. Sometimes pairing up two slackers encourages them to slack off even more. Sometimes their combined experience isn't enough for the task at hand, etc etc etc.

The trick is to balance the information you give the player with the information you withold, I think. Unless you want to completely simulate human emotional behavior, you need to heavily abstract it. That might lead to altogether too much predictabilty, though, unless you get that initial balance correct. My thoughts? "Professional" information should be given: Skills with various tools and tasks, experience and work ethic, etc. "Personal" information is hidden though, and heavily affects how a person works within a team. Thus the job of the player (manager) is to suss out enough of a person's hidden personal characteristics to put them in the best group possible, and THEN balance the combinations of people and groups to make an effective set of teams.

At least, that's the first idea I came up with. Modeling that personal behavior in ways that is at once believable and unpredictable (more problems come out under the stress of close deadlines, for instance, so problems that might not have shown up before suddenly appear) is the meat of the game and needs to be nailed.

What is a good, standard way for the game to respond to actions taken by the player through any particular class?

For instance, in my current project a city can create an army with a few variables set by the player. Right now I have it set up as the City class actually creates the Army object, but passes it to the Game Controller for all the other work (placing it in the army lists for instance). In order to do this I have to have an appropriate function in the Game Controller and pass it to the City object when created (coding in Python). Similarly, I would have to make and pass functions for armies attacking, for trade caravans arriving... Is this overly clunky?

I'm doing my best to enforce seperation and modularity in my code (it being a hobby/learning project, I anticipate ripping it up and rewriting often), and thus I want to keep communication between code layers and objects (game map, playing objects, game controller, etc) as standardized as possible, so I'm looking for a paradigm that can be generalized across the entire project.

It may be helpful to break these up into actual logic problems (pathfinding, learning from experience, etc) and more cosmetic effects, such as gaze tracking. There are many games in which gaze tracking has no meaning. The idle chatter problems mentioned (such as talking about weather when fighting) might fall a bit under both, though.

In fact, as far as the problem goes, I think I would approach it by thinking about it first from action-only perspective. That is, I will not be worrying about immersion-only effects like chatter, gaze tracking, or variable dialogue. Unless we are talking specifically about Skyrim or other Elder Scrolls games!

One of the primary drawbacks of many games for me is when I start seeing discrete "types" in my enemies, and then am able to easily exploit this knowledge. Once I've played enough to be able to tell what AI scheme an enemy has - and thus predict exactly what they'll do under any circumstances - the experience starts to fall apart for me.