Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Something I've always wondered, especially since it inspired me to start programming when I was a kid, was how video game bots work? I'm sure there are a lot of different methods, but what about automation for MMORPGs? Or even FPS-type bots?
I'm talking about player-made automation bots.
To 'bot' a game, you need to be able to do two things programmatically: detect what's going on in the game, and provide input to the game.
Detecting what's going on in the game tends to be the harder of the two. A few methods for doing this are:
Screen-Scraping This technique captures the image on the screen and parses it, looking for things like enemies, player status, power-ups, game messages, time clocks, etc. This tends to be a particularly difficult method. OCR techniques can be used to process text, but if the text is written on top of the game world (instead of on a UI element with a solid background), the ever-changing backdrop can make it difficult to get accurate and consistent results. Finding non-text objects on the screen can be even more difficult, especially in 3D worlds, because of the many different positions and orientations that a single object may possibly exist in.
Audio Cues In some games, actions and events are accompanied by unique sound effects. It is possible to detect these events by monitoring the audio output of the game and matching it against a recording of the associated sound effect. Some games allow the player to provide their own sound effects for events, which allows the use of sound effects that are designed to be easy to listen for and filter out.
Memory Monitoring If the internal workings of the game are well understood, then you can monitor the state of a game by inspecting the game's memory space. Some cheat tools for console systems (such as the Game Genie) use this method. By detecting what memory the game updates, it is possible to detect what the game is doing. Some games randomize the memory locations they use each time they are launched in an attempt to foil this vulnerability.
Packet Analysis With appropriate drivers, you can intercept the game's data packets as they are sent to or retrieved from your network card (for games played online). Analysis of these packets can reveal what your game client is communicating to the server, which usually revolves around player/enemy actions.
Game Scripting Some games have a built-in scripting interface. If available, this is usually the easiest method because it is something the game software is designed to do (the previous methods would all typically count as "hacks"). Some scripts must be run in-game (through a console or through an add-on system) and some can be run by external programs that communicate through the game via a published API.
Generating input events back into the game is typically the easier task. Some methods include:
Memory "Poking" Similar to the memory monitoring section above, memory poking is the act of writing data directly into the game's memory space. This is the method used by the Game Genie for applying its cheat codes. Given the complexity of modern games, this is a very difficult task and can potentially crash the entire game.
Input Emulation "Fake" keyboard or mouse signals can be generated in lieu of direct human interaction. This can be done in software using tools such as AutoIt. Hardware hacks can also be used, such as devices that connect to the computer's USB or PS/2 port and appear to the system to be a keyboard, but instead generate fake keypress events based on signals received from the computer (for instance, over a serial port). These methods can be harder for games to detect.
Game Scripting As mentioned above, some games provide built-in methods for controlling it programmatically, and taking advantage of those tools is usually the easiest (but perhaps not the most powerful) technique.
Note that running a 'bot' in a game is usually a violation of the game's Terms Of Use and can get you suspended, banned, or worse. In some jurisdictions, this may carry criminal penalties. This is another plus for using a game's built-in scripting capabilities; if it's designed to be a part of the game software, then the game publisher is most likely not going to prohibit you from using it.
Once I wrote a simple MMORPG bot by myself. I used AutoHotkey.
It provides lots of methods to simulate user input -- one will work. It's tedious to program a working one in C++ by oneself (Or look into AutoHotkey's source).
It can directly search the screen for pixel patterns, even game screens (DirectX)
So what I did was to search the screen for the name of an enemy (Stored as a picture with the game's font) and the script clicks a few pixel below it to attack. It also tracks the health bar and pots if it is too low.
Very trival. But I know of an WoW bot that is also made using AutoHotkey. And I see lots of other people had the same idea (Mine was not for WoW, but probably illegal, too).
More advanced techniques do not capture the screen but directly read the game's memory. You have to do a lot of reverse engineering to make this work. And it stops working when the game is updated.
How does an individual person go about their day to day?
This is sort of the problem that AIs in games solve.
What do you want your entity to do? Code your entity to do that. If you want your monster to chase the player's avatar, the monster just needs to face the avatar and then move toward it. When that monster gets within a suitable distance, it can choose to bite the player avatar, and this choice can be as simple as AmICloseEnough(monster, player); or more complex or even random.
Bots in an FPS are tricky to get right because it's easy to make them perfect but not so easy to make them fun. E.g. they always know exactly where the player is (gPlayer.GetPosition()) so it's easy to shoot the player in the head every time. It takes a bit of "art" to make the bot move like a human would.
For FPS-style bots, you could take a look at the Unreal Development Kit. As I understand it, this has got a lot of the actual game source code.
http://udn.epicgames.com/Three/DevelopmentKitHome.html
bta gave a very good reply. I just wanted to add on saying that the different methods are suspectible to different means of detection by the gaming company. Hacking into the game client via memory monitoring or packet analysis generally is more easily detectable. I generally don't recommend it since you can get caught very easily.
Screen-scraping used with input emulation is generally the safest way to bot a game and not get caught. Many people, (myself included) have been doing it for years with no problems.
In addition, to add an additional step between detecting what's going on in the game and providing input, some games require extensive calculation before you can decide what kind of input to provide to the game. For example, there was a game where I had to calculate the number of ships to send when attacking the enemy, and this was based on the number of ships I had, the type of ships, and who and what kind of enemy it was. The calculation is generally the "easy" part since you can do that usually in almost any programming language.
It's called AI (artificial intelligence) and really isn't that hard to replicate, a set of rules and commands in the programming language of your game will do the trick. For example a FPS bot would work by getting the coordinates of your player's body and setting your enemy bot's gun to aim at that coordinate and start shooting when in a certain range.
Related
I'm currently working on a C++/SDL/OpenGL game. I've already made a few small games, but only local ones (no netcode). So I know how to make the engine, but I'm unsure about the netcode.
Can I firstly create the full engine for split-screen play and later on add the netcode or will this make everything complicated? Do I already have to take netcode into consideration while programming the basic game engine or is it also okay to just put it on top of the game after it runs fine on one machine?
It's a 2D shooter type game, if that matters. And no, I don't like to change my choice of programming language/window manager/api because I already implemented the bare bones of the game. I'm just curous how this issue is approached best.
In theory, all you need is a good enough design. Write enough abstract classes and BAM! you can pop out one user interface (i.e. local-only) for another one (networked). I wouldn't believe the theory, though.
It's possible to do what you want, but it involves taking into consideration all of the new issues you address when dealing with networked gameplay - syncing views for multiple users, what to do when one user drops their network link (how to detect when one user drops their network link, of course), network latency in receiving user input, handling lag on one side and not the other. Networked programming is completely different, and some of the aspects (largely ones dealing with synchronization) may impact your core engine itself. Even "just showing two views" gets a lot tougher, because you now have data on two completely different machines, and the data isn't necessarily the same.
My suggestion would be to do the opposite of what you're hoping for. Get the networking code working first with minimal graphics. In fact, console messages will be far more important than pretty graphics. You already have experience with making the graphics of other games - work the most questionable technology first. Get a good feel of all the things the networked code will ask of you, then focus on the graphics afterwards.
Normally for a network oriented game there are five concepts too keep in mind:
events
dispatcher
synchronization
rendering
simulation
Events. A game engine is a event software, that means over a state of each generic object in the game (can be a unit, GUI, etc), you do an action, that means, you call a function or do nothing.
Dispatcher take each event change and dispatch that change to another subsystem.
Synchronization means that over a change of event, all clients in network must be advised throw his dispatcher over that change, in this way all players can see the changes of other players, render and simulate same things at same time.
Rendering The render read parameters and relevant states for each object and draw in screen. For example, is you have a property for each unit named life_points, you can draw a normal unit if life_points>50 and a damage unit if life_point>0 and life_point<50 and a destroyed unit if life_point=0. Render dont make changes in objects, just draw what read from them.
Simulation read every object and perform some task taking on count states and properties, for example, if you have cero point of life, you mark the state of a unit as DEAD (for example) or change de GUI, or if a unit get close to another of a enemy team, you change the state from static to move moving close to that another unit. Plus this, here you make the physics of units, changing positions, rotations, etc etc... as you have all objects synchronized over network, everybody will be watching the same thing.
Best regards.
Add in netcode as soon as you can. If you don't do this you may have to overhaul a lot of the engine later in the dev cycle, so better to do it early.
It also depends on how complex the game is, but the same principles still stand. Best not to tack it on at the last second
Hope this helps!
I am writing a game. it is in c++ an direct x and I think I am making my own engine as I am programming from winproc up.
I have made large amounts of progress such as sound, collision detection, AI specific to my game settings, dynamic graphics creation from tile sheets.
after doing some research on event programming I have been told to "script it". I have researched this and as far as i see scripting is used so non programmers can add to the project.
I an a prety good programmer and I have no intention of having anyone else work on the game except on outside things such as graphics or map design. I already had a function where I can read in maps from csv files. these contain not just the tile layout but the npc data, entrances/exits. other files of the same nature control monster and item data so I can update the contents without a recompile.
So I am asking for the view of experienced programmers and maybe real world examples that relate to my circumstances as to why I should or should not use scripting in my game?
The NPC and monster data need to be able to contain some simple logic like "if the player has this item", "if the player has been to somewhere", "if the player is comming from the right" etc. And for this you'll need ability to define some composed actions and conditionals. That is called scripting and is best done by incorporating some existing script language interpreter like Lua, Python, some variant of JavaScript, whatever.
There are several reasons to use a scripting system in a game, not just as you pointed out, to allow non-programmers to add game content. The first game I worked on professionally used a scripting system and the only people who were writing scripts were the programmers who created the scripting system. There were two reasons they used it:
build times
New data files/script files can be tested quickly. This particular engine didn't support it, but some allow for script files to be reloaded while the game is running. The more times you can iterate through the build-deploy-test cycle, the more you will be able to tweek your game and end up with a much better game.
power of expression
A custimized scripting system can allow you to easily express/code concepts that are cumbersome in traditional programming. For example, the game engine I am working with now allows me to easily control concurrent animations in script.
I don't think scripting is entirely necessary in your case. The bonus behind adding scripting support an engine have been listed up and down this page.
It gives you a simple langue to work with
It is more accessible to someone without training
It can be compiled on the fly, hot
swapped at runtime
For lots of high end games with large teams these items are very important. But it really comes down to the goals for your engine. If you are not considering sharing your engine and plan to work on the game just yourself then scripting does loose some of its benefits. Adding a scripting language also has some down sides.
Add complexity and creation time to your engine
Increase debug time, even if the scripting language has a wonderful debugger, switching between 2 languages is never smooth.
As long as you still have a data driven design (keeping stats and types in separate files which can be swapped out during runtime) you retain the ability to hot-swap out data for rapid iteration.
definitivly add scripting. Its a pita to recompile the whole game, just because your player does 0.8 damage instead of 1.0. Also, If you want to have a door open under certain circumstances, you need it definitfly. I would do most of the game in a scripting language, Its just more flexible.
Big names are using scripting languages. For example Eve Online is written in stackless python. Other examples can be found here: http://wiki.python.org/moin/PythonGames
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I was wondering if somebody could tell me how the game and the game engine fit into game development. Specifically what I mean is, the game engine does not actually have a game. So where I'm unclear about is basically, do game developpers build an engine, then create a new class that inherits from engine which becomes the game?
Ex:
class ShooterGame : public Engine
{
};
So basically i'm unclear on where the game code fits into the engine.
The distinction between the game and the actual game engine is architectural. The game logic is specific for one game whereas the game engine is something that can be reused. Much like an operating system provides utilities for applications the game engine does the same for the game code.
Game engines will typically have different APIs for:
Loading multimedia data like audio, textures, 3d models
Providing a game loop and firing off various events caused by the users input
Networking
Graphics rendering and various techniques to make the game look nice using lighting, particle effects or bump mapping
Audio
Artificial Intelligence
An API to allow for defining game rules, game play, and game logic
Most game developers do not write their own game engine. It would be too much work. Instead they'll reuse a game engine their company has or license one. For first person shooters, id Software, and Unreal are two popular choices.
Once they have the engine they have to start writing code to make their game. This is done using the API provided by the game engine. For example Valve makes developers use C++. If you wanted a monster you would extend off of the Entity class and define how this monster behaves in that base class.
I would recommend reading through the documentation and tutorials provided by the various game engine providers. Keep in mind some games are classified as "mods" and some as "total conversions." Typically, a mod does not change the engine of the game and the total conversion may add or remove significant features to a game engine.
Here are a few sources I would recommend:
http://developer.valvesoftware.com/wiki/SDK_Docs
http://udk.com
id Software releases their game engines as GPL after a few years. Reading through their code you'll learn a lot: ftp://ftp.idsoftware.com/idstuff/source/quake3-1.32b-source.zip. I would also recommend taking a look at Enemy Territory which was a based of quake 3 code: ftp://ftp.idsoftware.com/idstuff/source/ET-GPL.zip.
Actually, I can not tell the difference between engine and framework. It's just two different names.
What really odd is that game engine is all about client side, it seems like you do not need a server framework, whereas pure socket is enough for it.
But the reality is not like this, at least, there should be some framework like rails or django to ease your server development. Not to see game server is harder than web development in scalability, broadcast and other areas.
There is a commercial solution called smartfox server, and a new open source solution called pomelo framework, I've tried both, pomelo is much better. pomelo.netease.com is its home.
It also depends on the "level" of the Engine.
What I mean with that, is how abstract the Engine is from a certain gamestyle. There might be small things like a engine that is focused on a FPS might be built to be optimized for indoor areas, outdoor areas, that you fly at high speed. So even if a Engine might not be locked to a game, certain game types will be easier to implement certain Engines.
But as stated above, the game won't inherit the engine, it will more probably draw on it's functionality, and you will probably attach components to it's existing components. Or expand the components that are part of the engine.
class CoolDiscoLight : public Engine::Light
{
};
...
//and somewhere in the source
"CoolDiscoLight cdl = new CoolDiscoLight etc..."
EngineInstance.AddLight(cdl);
...
Even more probible is the fact that just by extending from light and overloading the correct functions the light will be accessible to a level editor etc so you won't actually create them trough the source at all.
A game engine is generally consider the code that can be pulled out and replaced with out changing the game it self.
Like has been stated already, how exactly you USE the code of an engine depends on the engine it self.
Commonly, you will instance class from the engine library and use them. The way you do this will be dictated by the engine.
Some might provide more features then other, some focus on module-ness.
Often an full game engine, will just tie together various sub engines, such as a graphics engine that handles actually drawing to screen. A physics engine for simulating your game world. a UI engine for the UI and menus. a network engine that handles entowrking things.
The 'game engine' may well have these components built in directly, or it may just be wrapping another engine/library so that you use it in a similar way to the rest of the engine.
do game developers build an engine, then create a new class that
inherits from engine which becomes the game?
It depends. Most of the time developers will make uses of existing game engines but sometimes they won't due to non-existence of wanted effects.
I have tried a number of different game engines. Most of them are behaving like this:
Defining sprites and sound elements by extending the class of it's basic entities
Defining groups for the ease of management
Defining a room or world for interaction between IO and the sprites
Program the logic in common functions like "update()" (the function will be called per frame)
Modify the entrance of the program to get into the first "room" or "world" (it can be a menu)
So a game engine is mainly do jobs of defining how the screen should display in a middle-layer, and the developer no need to worry about issues like will there be too many sprites loading outside the view-port? or When I press a key, where should the callback be located?, `Are they entity collided?" but focus on the higher level logic of the game.
Well I have been searching for game creation help and have found that an engine is the base of the entire game like the player creation is made easier as well custom graphics and physics or similar items. You also need to think of the next couple games that you plan to do and use the engine to build very little into your game which is already built for you.
If you want to learn what a game engine is, how if functions, or want to build one here is how is should go.
GLFW - For opening an OpenGL window. It's a great little C library
that opens windows on pretty much anything. Which is great because
that's one less thing to worry about.
GLEW - Managing OpenGL extensions. If you're gonna do OpenGL, there's really no getting around this one.
Lua - Scripting. Although not yet used in my game, it's pretty much the go-to language for scripting in the industry because of its
fast virtual machine implementation.
Protobuf - Managing external state. You can find a documentation it here. The short of
it is that you could use protobuf wherever you'd normally use XML.
Qt - For standard containers and string manipulation. you don't need to use the entire Qt set of libraries, only the QtCore one. This gives
you access to QList (std::vector), QHash (optimized std::map), QString
(std::string with multiple encoding support) and lots of other
goodies. Part of the reason you should go with it is because the
documentation is superb.
GLM - Math library. If you just want math in your game, this is the library for you.
freetype-gl - Text rendering. It's a very well-written library for rendering text in OpenGL, you could do
a whole lot worse.
libRocket - GUI library based on HTML and CSS. It's great when you just want a UI on the screen, but gets problematic if you want to
add animations.
Find the list here
These are great ideas for an engine just combine the libraries and build the game off of the engine you build from theses although it will take you sometime to finish if you dont have a fine team. Also I have read over this list and many others and this is the best 2d list. Also you don't need to build an engine UI because you only need the basics of the engine and build a separate project for each game. Here is how to do it right.
Engine.h
enginepart1.h
enginepart2.h
enginepart3.h (ect.)
(use .h not .cpp for engine because you can not reference engine.cpp but you can reference engine.h)
after building that
Game.cpp
gameresources.h (resources include referencing Engine.h)
gamepart1.h
gamepart2.h (etc.)
And build the engine in a fashion like this but not 100% like this would be optimal
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, ...
Found this here
Build it like this kind of
Framework: Math, Random, Utility, Asset, Network, Window, Graphics, Audio, ...
Entities/Characters: Player, Enemy NPCs, Friendly NPCs, BaseAI ...
Map: Map/Level Editor (if you want), Map Objects (can be placed here), Special Map Features, ...
State Control: Intro Screen, Main Menu, Logic Screen, Game State, Pause Menu(s), ...
Interface: Button, Text, Input Box, ...
it often likes this
class ShooterGame
{
Engine anEngine;
public void Run();///run the world here
};
Yeah, what they said. I'd add though that game engines are usually designed for a style of game. A flight simulator needs are very different than Quake. Games like Oblivion are merging those needs together though, so this may soon not be the case.
I am immediately placing this as a community wiki thing. I don't want to ask for help in programming yet or have even a specific question about programming, but rather the process and the resources needed to make such a game.
To put it simply: My college friend and I decided to give ourselves a really big challenge to further our skills in programming. In six months time we want to show ourselves a Pac-Man game. Pac-Man will be AI-controlled like the Ghosts and whichever Pac-Man lives the longest after a set of tries wins.
This isn't like anything we've done so far. The goal here, for me, isn't to create a perfect game, but to try and complete it, learn a whole bunch in the process. Even if I don't finish in the time, which is a good possibility, I would want to have at least tried this.
So my question is this: How should I start preparing myself? I already have started vector math, matrices, all that fun stuff. My desired platform would be DirectX 9.0c; is that advisable? Keep in mind that this is not a preference just for this project, but I wish to have some kind of future in graphics development, so I want to pick a platform that is future-safe.
As for the game development in general, what should I take into consideration? I have never done a real game before, so any and all advise to development of mid-scale projects( if this would be a mid-scale project ) is greatly appreciated.
My main concerns are the pit-falls and demotivators.
Sorry if the question is so vague. If it doesn't belong here, then I will remove it. Otherwise, any and all advise regarding making larger projects is greatly appreciated.
Given you've not tried this sort of thing before here's a few things I'd recommend.
Start with something other than DirectX (and presumably C++)
DirectX and C++ expose you to a lot of low-level stuff you can learn later. Keep things simple and perhaps try XNA and C# which is close enough you can port it later but will let you skip a lot of things like memory management and pointers for now.
Start with 2D instead of 3D
The original Pacman is 2D so you won't be needed vector math for now.
So where does that leave you?
Well, a few things to think about are the game loop, keeping things in sync, updating the screen and responding to user input.
These are great principles and will let you get something up and running a lot sooner. Do not underestimate how important it is to keep seeing progress - this is hard if you set the technical bar too high initially.
I'd go down this route (ordered to keep things fun and interesting)
Get a screen displaying - this is highly visual
Get a Pacman responding to user input
Get Pacman constrained to within the walls
Get a ghost responding to secondary user input - you can chase each other
Figure out some collision detection
Get the dots and power pills rendering so you can score and eat ghost
Render some more ghosts and figure out AI
Work out the code for finding when the level is complete
Make the map change and state reset when on a new level
Once you've got this working and running you can then decide if you want to play with better AI, 3D math or switch over to C++.
I had to write a pacman game in Java for an OO class. I found it to be very straightforward, possibly with the exception of figuring out the best way to map walls. After a bit of research, I came across this: http://javaboutique.internet.com/PacMan/source.html which uses bit-shifting to determine walls. It looks like complexity overkill, but I found it to be pretty elegant after I played around with the math a little. Other than that, pacman is a very array-friendly concept, so use an array for the board, some basic sprites, tinker with the speed and refresh, keep track of game data, and toss it in a loop.
As for the AI with the ghosts, there are articles written about them. Each ghost has a specific "strategy". Or you could roll your own..you could program them to be as easy as always heading towards pacman (or his general location/quadrant), or as complex (shortest-path) as you'd like.
Play pacman! This is the first task for your project!
I'd look at the original arcade cabinet assembly code for Pacman and the description of what it does. It's a real eye opener :)
Personally, here's what I would do:
study open source games to see what they do
buy a book about game programming (actually, I have a book about game programming already, but you probably want something more recent than that)
pick a toolset/game development library (Sourceforge, Google Code)
work through the tutorials that come with that library, possibly change to a different library if the API is too weird
come up with a requirements document
draw up a first pass design ("plan to throw one away"), try to have somebody review it
decide on a test plan
write up a schedule, not because I want to stay on schedule but because I want to break things down into easily-defined tasks
write the smallest complete game I could (eg., a Pac Man sprite that I can control inside a window: no maze, ghosts, score, lives, ability to die, etc.)
add features to that game until I've implemented the whole thing
Sounds like a good idea for a learning project! The 2 general things I recommend for your approach are
work in iterations
read a bunch about C++ and DirectX along the way
Start small -- write some code that does nothing more than draw Pac-Man on the screen. Then build on that by implementing movement across the screen. Then build the map boundaries and the inability to travel through them. And continue in this fashion, prioritizing the next task you need to complete, and then doing whatever it takes to complete it. Try not to make the tasks too big.
In order to figure out how to complete the tasks, you'll need to read. Books, web sites and existing code are all very helpful in figuring out how to do what you want. It's worth looking at several different ways to complete the same task, because some ways are better than other, or might better fit your project.
Good stuff! I am glad that Pacman motivates and inspires you.
Things to get started.
1) Decide on the development environment.
a) Are you building a standalone game or a networked game.
b) Which language are you targetting at to improve?
2) How well versed with AI?
3) How well versed with the programming algorithms techniques - like A * (A star) path finding, Dijkstra algorith, collision detection, hit testing or even recursive programming?
4) Are any of you talented in graphical design?
Good luck.
P/S FYI, if I were to write a Pacman game, I would do it in C# and Silverlight 4.0 (I can write C++ comfortably but my priority is to jump on the Silverlight bandwagon).
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I want to start this as a hobby in developing a desktop game. I have found several engines, but I am not sure whether it does the initial job I am looking at.
Initially I want to do the following:
Create a figure (avatar), and let the user dress the avatar
Load the avatar in the game
In later stages, I want to develop this as a multi-player game.
What should I do?
I also recommend Ogre. Ogre can do this, it provides everything needed in regards of mesh and animation support, but not as a drop-in solution. You have to write lots of code for this to be done.
For our project we implemented something like you do. The main character and any other character can be dressed with different weapons and armor and the visuals of the character avatar change accordingly.
As a start hint for how to go about this: In your modeling tool (Blender, Maya, 3ds max, etc.) you model your avatar and all its clothes you need and rig them to the same skeleton. Then export everything individually to Ogre's mesh format.
At runtime you can then attach the clothing meshes the user chooses to the skeleton instance so that they together form the avatar. This is not hard to do via Ogre-API, but for even easier access to this you can use MeshMagick Ogre extension's meshmerge tool. It has been developed for exactly this purpose.
If you want to change other characteristics like facial features, this is possible too, as Ogre supports vertex pose animations out of the box, so you can prepare pathes for certain characteristics of the face and let the user change the face by sliders or somthing like this. (e.g like in Oblivion)
One thing to be aware regarding Ogre: It is a 3d graphics engine, not a game engine. So you can draw stuff to the screen with it and animate and light and in any way change the visuals, but it doesn't do input or physics or sound. For this you have to use other libs and integrate them. Several pre-bundled game engines based on Ogre are available though.
If you are good with C++ you should use Ogre, it's the best open-source engine, continuously been updated by it's creators, with a lot of tutorials and a very helpful community.
http://www.ogre3d.org/
It's more of a GFX engine, but it has all the prerequisites you desire.
Good luck!
No engine is likely to do this for you. What they do is generally allow you to load and render 3d models. But combining them, the way you'd need to do to "dress them" is up to you. And creating them, or letting the user do so, is ultimately up to you. The engine might offer a number of tools to make the task easier (for example, rendering the model while the user is designing it), but a game engine is not a magic "make a game" box where you just have to press a button, and your custom game comes out.
A couple of people have said Ogre3D, I'll offer up Irrlicht as an alternative.
You might want to take a look at http://www.crystalspace3d.org/ - I have to admit it was more of an exploratory matter for me, but it seemed like a pretty nice engine - with physics and scripting included. They have an project which shows the avatar walking in the spacestation-like building with very smooth camera effects.
OTOH: depending on how far you want to push this, you might find yourself recreating the SecondLife(tm)-like kind of environment. If that's a fair assumption, then you might take a look at OpenSimulator and the associated opensource viewer projects and see if this may be of interest to you - and work there with the existing team to develop the code further, rather than working on your own.
If you good with C++, I suggest the C4 Engine. From my experiences, existing game engines are either too rigid or just nothing more than a collection of libraries.
Ogre is a good way to go if you are just interested in getting something to show. As some have already stated here, Ogre is a rendering engine. There are lots of add-ons and functions to complete common tasks like Audio, Input and whatnot. This is perfectly fine if your just aiming at playing around or creating a prototype.
Should you want to start a long-term project that will be developed over a longer period of time (which would be pretty likely considering you probably being the only developer and games being complex applications), you should really start thinking about what it is that you want to do. Then, based on you're goals, look for several engines that can tackle your needs (there's always some API to accomplish XYZ). Then it's up to you how you manage your game and where you use existing libraries - you'd basically tie up your own engine according to your needs.
It get's a bit more difficult if you start looking for a real game engine in terms of "engine for all my game-dev needs". Check out the nice list of 3d game engines at devmasters (http://www.devmaster.net/engines/), you'll find lots of alpha status game engines trying to accomplish this, although you should keep in mind that support and documentation usually isn't first class in those cases.
I personally never used it, but I evaluated the open source engine Delta3D (delta3d.org) for my project and was impressed by it's cool architecture. It encapsulates a whole bunch of other quality open source frameworks for stuff like graphics (OpenSceneGraph: openscenegraph.org) or physics (ODE: ode.org). That's probably as close as you'll get to a free and flexible game engine as far as I know. It was developed at an air force university, and due to it's academic background comes with lots of detailed documentation.
If you're good with C++ you can write your own engine :P
Ogre is the best of Irrlicht and Crystalspace, and the reasoning behind that is simple - Ogre has actually been used in a production pipeline by the game industry. It actually has a lot of weight behind it, whereas Irrlicht and Crystalspace are more or less applications that don't do a lot out of the box. Crystalspace however has a branch project that implements a game engine right into Blender 3d allowing the artist to play the role of programmer without leaving the actual software.
I'm not very big on Irrlicht - there is a lot of sneakiness behind its motives. For an open source project it branches out into many different derivatives that are either complete game engines or WYSWYG editors and they find ways to lock you into paying somehow.
Ogre excels at being a graphics engine rather than a library, and it has to be compiled to individual needs. The tradeoff is you can implement Ogre into any design work flow or even create a new one. Where it takes the load off your shoulders is having to write graphics code of any kind thus making it a very slick rapid prototyping engine in its basic form.
One engine that you could try is the Torque 3D game engine www.garagegames.com which, although not being freeware, allows for out of the box usability. While the functionality that you seek in terms of being able to fully customise the character is not instantly available within the engine, if you are willing to create the models yourself it should not be too hard to add them into the game and the utilise the game engine to change the 'skins' of the avatar. One thing that I feel will set this apart from the other engines is the fact that it comes with networking functionality pre-installed (from what you have described in your question I am guessing that you are attempting to either make an RTS or MMO, and if so I wish you good luck).
While it may seem strange that the engine is based around a shooting game, there are guides witin the Torque forums that allow you to add the coding for sword based combat and other things associated with a fantasy based game (if, that is, what you are planing on making).
But anyway... good luck with your project. If you are attempting what I think you are attempting it is no easy feat. But I'm sure you know what you are doing =)
Hope this helped
If you are interested in using the Irrlicht 3D engine, you can find a number of tutorials that step you through the process of creating simple 3D applications here.
I also suggest Irrlicht. It's easier to begin with, but it does not have half of the Ogre3D support though.