I'm slowly introducing myself into some procedural generation techniques. However, instead of generating a map or level in a video game, I want to learn how to create procedural character models.
I guess something that would be akin to this would be the creatures from the video game "Spore". The basic idea is that the program will choose from a set of pieces of a creature, and piece them together to create one model.
Where can I go to learn more about this?
Also, do you know of any game engines that may have some compatibility for this sort of project?
I think as long as the parts of your creature are static assets and predefined by you (together with the information where the joints and fixpoints are), it does not really matter which engine you use. All common engines like Unreal or Unity allow you to create a character in the game from different components, which would be your creature parts.
The only challenge I see is the problem of animating the creature. You will still need some kind of skeleton that tells the engine how to map the animation to your creature. Maybe you can have different creature trunks with skeletons and animation and fixpoints to attach your various parts like arms or legs.
Related
I'm using the Marmalade SDK, my question is, can I use only cocos2d-x and Box2d, and not use Iw2d, IwGx, IwGL altogether (or vice versa)?
And what factors will my choice depend on regarding if I want to use cocos2d-x and Box2d, and not all the others (or vice versa)?
P.S I'm developing a 2d game that will need minimal physics
you can use Cocos2d-x without using Iw2D, IwGX, etc. Cocos2d should abstract these things for you. Cocos2D-x is a complete game engine, where Iw2d is only a rendering system that renders 2d sprites für you.
What systems you want to use depend on how much low-level work you want to do yourself.
If you use Cocos2D-X it will have support for a lot of features out of the box. Like scenes, sprite-rendering, skeleton-animation, effects, particles etc..
Iw2D just abstracts the low level OpenGL-API so that you can render sprites with just one function call. But it does not support animations and other features. So you would have to include other projects or write the functionality yourself.
IwGx is a wrapper for OpenGL which introduces states so that the OpenGL-API is easier to handle.
IwGl is just plain OpenGL and you would have to implement even the rendering yourself.
Which one to use depends on the project. When you just want to make a 2d game cocos-2d or Iw2D should give you enough control to succeed doing so and also you will save time because you can use already tested systems.
Box2d is only used to drive the physics simulation of your game world. You can use it with all of these systems.
Depending on your C++ and game programming experience i suggest to first use a game engine (like cocos2d-x) or Iw2D to learn the basics. For your second game you can still switch to a more low level api if you want to.
Sounds like you can focus on the Quick flavor of Marmalade, which has cocos2d and box2d bundled up with Lua. That will make for easy start and development.
I have a question about organizing code while also displaying fundamental OOP principles. My task is to implement a world (MxN grid) with robots who get instructions to move around in the form of strings. They are also given an initial starting position and orientation. Instructions are performed in completion one robot at a time.
I made two classes, Robot and Map, but when I completed my coding I realized that the Map did not really do anything, and when I want to test functions within the Robot class (making sure coordinates are within bounds, etc.) it seems that the Map class is more of a hassle than anything. However, I feel like it is important for demonstrating the separation of things. In this case is it necessary to have two classes?
I think it does.
Map looks like a collection of Robots. It's like an Eulerian control volume that Robots flux in and out of. It keeps track of the space of acceptable locations in space and time. It maintains rules (e.g. "only one Robot in a square at a time"). Feels analogous to a Board for Chess or Checkers game.
The problem appears to be that you can't figure out what the meaningful state and behavior of a Map is.
I can see how a Robot would interact with a Map: It would propose a motion, which is a vector with direction and magnitude, and interrogate the Map to see if it ran afoul of any of the rules of motion for a Robot. Those are owned by the Map, not the Robot. Different Maps might allow different rules of motion (e.g. no diagonal moves, one square at a time, etc.)
With these programs, it seems like every aspect of the game is done through the GUI. Is there any coding when making games through these programs? Like would you code in collision detection, or would that be done through the GUI?
I don't know the Unreal engine but Unity3D and SIO2 but the situation should be similar. Basically a lot of programming is taken from you and can be done through setting properties like in a Blender material. But at the end you have to do at least a little bit of coding.
The process of collision detection for example involves attaching a collider to your player character and another one to your obstacle. Then you have to attach a small script to your player like this.
void OnTriggerEnter (Collider collider) {
if (collider.material.name.Equals ("ObstaclePhysicMaterial")) {
player.PlayAnimation ("Die");
// your code snippet to game over or whatever
}
}
Not too abstract but it has to be done and of course your game over logic will include some more code to reset all objects to their initial position. So at the end you cannot avoid coding but when I started learning Blender I made the experience that more complex Blender scenes have indeed similarities to programming. You have to plan your scene and find the most efficient structure to avoid unnecessary work i.e. thinking in terms of logic is slightly analogue.
So if you plan a game with heavy graphics and not too sophisticated logic I like to encourage you to give scripting a try. Start with studying sample projects.
With development kits you usually get. The most important part the engine. Sometimes materials and land scape tools. All you do really is the scripting part. Events, environmental variables, usually in LUA or python. Not the actual engine and physics.... the hard part.
I need a 3D engine for a very specific task in Artificial Intelligence, and I'd like some input.
The first part is the trivial one - basically, all I need is a FPS engine (3rd person would be good, too), such that it allows me to navigate a room and interact with objects (if you have Java and Windows, I'm looking for something similar to the Give Challenge, but a little more up-to-date). Physics would be nice, but is not a must.
Now, the non-trivial part would be: I need to impose a virtual grid over this room, such that at any moment I can say "the player is located at B5 - now he moved to B6", and so on. I need to redirect this information to another system (namely, one which will give the player instructions about what to do) and, at the same time, send messages to the player, so I must be able to have a single point through which the game logic passes through; also, I'd love not having to write my own collision detection and such.
So far, I've tried:
the Source SDK: it seems a little overkill (since I'm not really planning to shoot anyone, at least half the code base is useless to the task), and since I'm not really a Windows developer, I'm spending too much time with the "easy" stuff (such as getting VS up and running). Plus, cross-platform would be really nice.
Blender game engine: while this worked decently, the interaction model seems a little weird, and some easy stuff (such as making sure the camera stays inside the scene or showing the mouse on screen) gets too weird too soon.
Crystalspace 3D: I've tried their demos, but it looks a little old-fashioned, and since that was one of the problems of previous engines (it's easier to get volunteers when your game looks nice) I'd like to try something else.
Now, maybe I'm asking a little too much for a single software, but I'd love some input. Can anyone suggest me an alternative? Or should I give one of the previous ones a second chance?
Try the UDK. All of the things you request are present, and it's free for personal/noncommercial projects. Here are some highlights:
Modern looking. The UDK features an intuitive-ish visual material design system, post-processing effects, Scaleform Gfx UIs from Autodesk, and more.
A visual scripting interface called Kismet that can control gameplay elements, the camera, and more.
UnrealScript, a scripting language similar in syntax to C, C++, Java, that gives you the ability to extend existing functionality or create your own.
Comprehensive documentation available on UDN.
Lots of community support outside of Epic, in places such as Polycount, Eat3d, 3dbuzz, and more.
Basically, "and more".
If what you're looking for is a professional, free (as in beer) engine that will allow you to focus primarily or solely on your differentiating gameplay features, Epic has set the bar high.
I am a C++ programmer trying to learn designing, as a start I am trying to get a hang of designing by giving myself a task to make a OO design for a game of chess.This is not a homework q just trying to develop some skills.
Here is the summary of what i have in my mind till now:
A "Piece" class which will hold the current position of the piece on the board.
specialized classes "Camel" "Horse" "Queen" "Knight" "Pawn" & "Elephant" which will be derived from the "Piece" class. Each of these classes will hold 2 members, "no of places allowed to move" & "rule of moving" and get methods to retrieve the same.
A base "Player" Class which will be extended by classes "BlackPiecePlayer" & "WhitePiecePlayer". Each of these classes will hold another class instance called "PieceManager" The "PieceManager" class will be the one which will determine the logic of moving around the pieces on the Board.
A "ChessBoard" class which will hold the mapping of all the pieces on the board and have access to set of rules with which pieces can be moved. It will provide interfaces to authenticate a move calculated by "PieceManager" and then make the move while updating its own mappings.
Heres a generic flow that i can visualize. A class "WhitePiecePlayer" is asked to make a move, it will ask its own "WhitePieceManager" to make a move. The "WhitePieceManager" will access the positions of pieces on board by using interfaces of "Board" class. Then it will use its internal logic to calculate a move for an piece.Each piece stores its position so it calculates position for that piece. Then authenticates the move is possible by calling a method of the Board class and then makes the move by using Board class interface..and so on..
Sorry for the long story, I am just trying to develop a feel for the design and this is what i have in mind right now, Do you think its good for a start or any suggestions on how to make it better(if it is correct)
A few suggestions
Your hierarchy of piece related classes seems reasonable (though using the proper names for the pieces Knight, Rook, and Bishop would probably be preferable to Horse, Camel, and Elephant).
I would not store the number of squares a piece is allowed to move. You would want to encode that in the "rule of movement" method if only because that can change depending on the situation. A pawn can move two squares on its initial move and then one square in subsequent moves. A king can only move one square unless it is castling.
Your piece classes will need to have some sort of method to get a list of all a piece's valid moves in order to provide those to the engine that is going to choose a move.
You don't need BlackPiecePlayer and WhitePiecePlayer classes. You just need to instantiate two different instances of the Player class and ensure that there is a "color" attribute.
A ChessBoard class is a good idea and will need to represent the positions of the pieces but it should not implement logic evaluating moves. That is something for the move engine to do.
As Javier discusses, building a chess program is likely going to involve quite a bit of effort on the design of an efficient algorithm for choosing a move. Assuming that your intention is to apply OO concepts and not to delve into the discussions about how to build a chess engine (which will often sacrifice OO purity for better performance), and assuming that you want to build something that can play well enough to be interesting, you may want to consider implementing antichess rather than regular chess. From an OO standpoint, it is essentially an identical problem, but the end result is something that plays reasonably well without investing hundreds of hours in mastering chess algorithms. That's a much more enjoyable outcome than a chess program that plays terribly.
A few comments
1) The most important thing in a chess prgoram is the algorithm to choose a move. Usually it is an alpha-beta pruning algorithm. In order for this algorithm to be efficient, the way that pieces in the board are represented is very important. You can read that in this implementation issues section of wikipedia. I'd read that for the basis of board-piece representation. There is a lot of discussion in internet, and open engines like Crazy or Fruit. I doubt that they use OO, though - I do not know if there is any Object Oriented engine in the wild.
2) What are the camel, elephant, etc? What kind of chess are you trying to represent? I am not familiar with that, sorry. Is elephant the rook and camel the bishop?
3) What is the utility of having two different classes, WhitePlayer and BlackPlayer? In which way would they be different from Player? Shouldn't you have two different instances of a Player class, called white and black?
Good luck with your project. I hope you learn a lot from it! :)