Perlin noise related

snippet1

As with most terrain generation, noise functions are your friend - Perlin and/or simplex noise in particular. I've implemented some planetary terrain generation algorithms and although they are in 2d, the resulting height / "texture" map could be projected to a sphere rather easily. I assume conversion to hex format is not an issue either.

My technique has been creating multiple noise layers, e.g. temperature and humidity. Temperature is fused with a latitude coordinate, in order to make the equator more hot and poles cold, while the noise makes sure it's not a simple gradient. The final terrain type is selected by rules like "if hot and not humid then pick desert". You can see my JavaScript implementation of this here: https://github.com/tapio/infiniverse/blob/master/js/universe/planet-aerial.js

As for the water percentage, you can just adjust the water level height as noise functions tend to have a constant average. Another option is to apply an exponent filter (useful also when generating clouds, see my implementation here).

Another way to generate spherical terrain that came into mind (haven't tested) is to use 3d noise and sample it from a surface of a sphere, using the resulting value as the ground height at that point. You can then weight that according to amount of water on planet and the latitude coordinate.

I'll end with a link to one practical implementation of 3d planetary terrain generation: http://libnoise.sourceforge.net/tutorials/tutorial8.html

Code organization related

How to organize code of a game engine?

• Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
• Player: AbstractPlayer, Score, Input, Collision, Reaction, Skill, Inventory, ...
• Map: AbstractMap, Area, Town, NPC, ...
• Enemy: AbstractEnemy, Creep, Boss, BaseAI, FuzzyAI, ...
• State: IntroScreen, MainMenu, LoginScreen, Game, PauseMenu, ...
• Interface: Button, Text, InputBox, ...

This is only for the client-side of the game. XML, Lua, Javascript or SQL databases are useful for defining many different things especially different classes of players, maps, NPCs, enemies, items, quests, skills, etc. I like XML though, because of its simplicity, and its data can be parsed by any other language.

Game files are usually stored in a package file like ZIP or similar resource. I have a resource loader that looks for a file in the package, then if it can't be found, it locates the resource in a directory, or some other place. This allows me to develop quickly.

3D games are no different, but they are more complex. They need model loaders, instancing, and must use vertex buffers. They consequently make heavy use of shaders to provide other effects like lightning, bump maps, environment maps, etc.

Most 3D games have a game engine backend to do all this for them. For Java, try jMonkeyEngine. For C++, try Ogre3D. For Python, try Panda3D.

In my experience, it is better to hardcode everything whenever you can, unless the feature is specifically required. This allows you to develop the game faster, and refactor later.

Rendering related

How to create HUDs?

Well... A HUD is basically just a 2D overlay... If you look up opengl tutorials for displaying text... and for 2D placement then you should be able to figure it out. If you like you can draw on the near plane... but this can have an amusing side effect... messiah did this, but it didn't have a near plane clip... this meant that on occasion, if an object was heading for the camera when you brought up the in game menu, the object would appear to pass right through the menu. An obvious way around this is to disable depth testing for the HUD drawing. Hope you get it working,

General

What is the workflow for creating a simple game?

Let's assume I'm a single coder who is the entire engineering team for GTA V, without support libraries, and let's assume I'm stuck in some kind of crazy time dilation field that makes this vaguely plausible because otherwise I'll be at it for decades or centuries. Also I'm immortal.

Here's how I'd approach it:

First, get the main window showing Next, render a hardcoded 3d triangle in the window Get a basic model exported from the 3d program Get that model imported into the game Render that model with a simple flat color Add texture support Add shader support At this point I have a realistic-looking human character standing in an endless black void, and maybe I can move the camera around him. No animations, though.

Add animation loading Set up animation sequencing and mixing code Now I can "walk" around the endless void, at least in the sense that it looks plausible.

Load terrain and world object formats (this should be easy if I wrote my texture and shader support well!) Now I've got a world to walk around in! And by "walk" I mean "swim, without colliding into anything ever", because I don't have collisions in yet.

Load collision meshes Write entire physics engine (unless I can use Havok or Bullet3d or the like) Connect everything to the physics engine so that collisions now exist Connect physics engine output to animation system so the character reacts realistically I now have a static unchanging world with a character walking around in it.

Set up a general dynamic entity system so I can introduce more objects Write a basic "pedestrian" AI that just walks in random directions Link that to the collision system Now I can walk into people, and they can walk into me!

Vehicular physics Damage, entity states for "death" Respawning (for me, at least :V) Substantially more advanced AI that understands "fear" and "driving" and "aggression" Sure, let's toss some guns in here We've got the basic sandbox system rigged up, but it's a very boring sandbox.

Scripting support for designers, including the ability to influence pretty much every part of the game And now we have, approximately, a game. (Without sound - add sound in there somewhere.)

Keep in mind that, the further this goes, the more complicated the features are. "Main window showing" is less than a day's worth of work. "Scripting support" could easily be a year, and for a game the size of GTA, it's probably multiple years.

The key to really big projects is to figure out a sensible small place to start, then just keep building on it.

Also, note that I'm taking this assuming that I already know what game I want to make. If I'm just prototyping something I might put off "model loading" and "shaders" until well after AI is done - I'd have a prototype consisting of cubes and pyramids walking around a box-based world and driving rectangular cars.