GameDev General

Pages: 1234... 7
@Lumpkin
I'm developing a 2D side scroller with a single, continuous map (i.e. no levels or hubs) split into sections so all I need are the configuration files and the textures and such.
So the map itself is hardcoded?
If the map is not part of the source code, it is not 'hard-coded'.
Well he said all he loads are configuration files. So it must be hard-coded or randomly generated.
Configuration files are not 'hard-coded' because you can change them without recompiling your program and see the effect when you run the executable.
The paths to the configuration files are hard coded, but no map content is stored in the source code. The configuration files will tell the engine what to load and where to load it. I think my save files will have an "NPC blacklist" so that the game doesn't load NPCs that are dead.
I get what you're saying now.

The config file IS the map file. But doesn't that get kinda big?
Last edited on
What would you expect? Did you think your favorite mainstream video game hard-coded everything, or that the level files didn't get big?
Well, if the configuration files do get too big (in all likelihood they will probably be reasonably small individually but there will be lots of them) then I could always stick them in a compressed archive. Text files generally compress well.
Yeah, and if you compress them you can always start using PhysFS to load from the compressed files.
No I never said that. Most mainstream games use a binary format. They get large too.

When I worked on my RPG I never hardcoded a level.
Last edited on
closed account (3qX21hU5)
Anyways anyone else have any experience with the questions I posted? I am actually quite curious on how others go about doing/implementing them specially the testing aspect.
I'm not hardcoding anything either...

Anyway, text might be bigger but it has the advantage of being more compressible and human-readable so that I can fine-tune things by hand and so that people can modify my games if they want to.
@Zereo re. Your questions

For 1) Game testing tools. I often just add keyboard commands. It's easy to add code for this in the EventHandler() function.
In a game I'm currently working on the player has 8 weapons for which upgrades are purchased in an upgrade menu between levels. This makes testing the various weapon levels difficult, so I enable key 'u' to upgrade, and 'd' to downgrade the current weapon. I also enable a shortcut to the level I want to test. Just hit the level number at the start screen.

The player also has 3 bomb types. One is hack bomb, which "hacks" all enemies within its blast radius so they are turned and fight on the players side. I use a key command to automate testing this feature. Getting it to work just right has been a little tricky.

I find it useful to grant invincibility to the player (disable collision testing against weapons), so I can test without struggling to survive.
Finally, it's nice to be able to pause animation and step through it frame by frame to examine details. A couple of bool variables control calls to the gameLogic() function, with the key commands 'p' (play/pause) or 's' (step)
1
2
3
4
5
if( run || step )
{
    pLogicFunc();// pointer to current logic function
    step = false;
}


2) I'm not sure what you mean by 'state management'. If you mean whether a level is in play vs. being at a menu, then I use function pointers for this. There are INIT, Delete, Event, Logic and Draw functions for level play, and for each menu in the game. A function pointer for each of these is used to ensure that the appropriate function for the current state is being called. The program flow is determined by the function pointer assignments made in the INIT and Delete functions.
closed account (3qX21hU5)
Finally, it's nice to be able to pause animation and step through it frame by frame to examine details. A couple of bool variables control calls to the gameLogic() function, with the key commands 'p' (play/pause) or 's' (step)


Ohh i quite like that idea. I do kind of the same as you. I have a few shortcut keys for certain things like turning on and off bounding boxes, getting a certain upgrade or ship, ect. Then I just added in a in game console window that I can bring up with '~' to test more in depth things like adjusting enemy hit points and speed or spawning a certain group of enemies. Wanted to make a UI with sliders and stuff for it but just opted for a console instead since it seemed a bit easier.

But will definitely have to add in the step through frame by frame (Or even a few frames at a time) since I can definitely see where that would come in handy.

2) I'm not sure what you mean by 'state management'. If you mean whether a level is in play vs. being at a menu, then I use function pointers for this. There are INIT, Delete, Event, Logic and Draw functions for level play, and for each menu in the game. A function pointer for each of these is used to ensure that the appropriate function for the current state is being called. The program flow is determined by the function pointer assignments made in the INIT and Delete functions.


Thats correct basically the global state of the game (IE Titlescreen, menu screen, level 1, level 2, ect).

I kind of go a different route for handling these. Basically I will have a base state class that each different state inheirits from. It basically just provides the functionality for changing from one state to the other and some other basic things that each of them needs like the update function, draw function, and event handling.

I then create a new class for each of the states that define whatever they need to do. To manage it all I stick them into a Stack. Have to give a shout out to the SFML book for the state management design (And pretty much the whole framework design). Here is the code from one of the games I have been working on that demonstrates it. The repo is quite behind from the current implementation have been meaning to push the recent changes to it for awhile now. But feel free to look around if you want it has most of the basic framework.

State.h and State.cpp - Base class for all the states.
https://github.com/Epidemic-Games/SFML/blob/master/State.h
https://github.com/Epidemic-Games/SFML/blob/master/State.cpp

GameState.h and GameState.cpp - Where the gameplay happens (Got rid of this for different level states)
https://github.com/Epidemic-Games/SFML/blob/master/GameState.h
https://github.com/Epidemic-Games/SFML/blob/master/GameState.cpp

StateStack.h and StateStack.cpp - This is what handles all the different states and determines which one is active.
https://github.com/Epidemic-Games/SFML/blob/master/StateStack.h
https://github.com/Epidemic-Games/SFML/blob/master/StateStack.cpp

And here is a common use of changing states. This comes from the MenuState and is for when the play button is hit. It pops the current state (MenuState) off the stack and pushes which state you want to go to onto it.
1
2
3
4
5
6
7
8
auto playButton = std::make_shared<GUI::Button>(*context.fonts, *context.textures);
playButton->setPosition(100, 250);
playButton->setText("Play");
playButton->setCallback([this] ()
{
	requestStackPop();
	requestStackPush(States::Game);
});


Anyways thank for the answer fun2code I'm always interested in how others go about different aspects of game programming and don't really know to many people that are into game programming.
Last edited on
I've had a good look at those program files now and must say that's a much more organized approach! I hadn't thought to treat the game state as an object.
I see parallels with my less organized c like approach. Perhaps I should stop trying to think up everything myself.
When I use a set of function pointers I'm actually modeling virtual function behavior. Thanks for the links. I may try that approach in my next project.

@chrisname I was going to comment about the idea of not clearing an image and using partial redraws to update it, but I guess that concept got shot down pretty good on page 1, and you haven't replied back on it. Ive experimented with it and found fairly simple methods, though it's only useful when there is a static background image. The basic idea is to paint over any moving object from the sub-rectangle of the background image where the object is, then move the object and repaint it.
Last edited on
@fun2code
That's helpful, thanks. I'm not going to implement it though, for obvious reasons. I was mostly just curious how it might be done.
Last edited on
Anyone do 3D dev?

I don't know what a matrix is at all.
closed account (3qX21hU5)
I found the sections on matrices in "Game Engine Architecture" to be of great help with learning how to use them http://www.gameenginebook.com/ . I would definitely recommend checking it out.

But otherwise what don't you understand about them (Or how they are used)? It is quite a broad topic and would need some specifics to try and help.
Last edited on
Before learning about matrices, you should understand vectors reasonably well.

Matrices are multidimensional arrays. An array (or vector) is a series of numbers, so it has only one dimension -- when you write the numbers you write them as a column or row, so, like a straight line, they're one-dimensional. A matrix is like an array except that it has more than one row (dimension), and each row has the same number of columns. Wikipedia describes them as "rectangular arrays" for that reason.

In programming, you can implement a matrix as an array of arrays, although that's not considered a good implementation. It's better to simply use a one-dimensional array and calculate indexes as i = y * w + x where i is the index, x is the x column, y is the row, and w is the number of columns per row.

As for what they're used for, in games the primary use is for transformations (scaling (making bigger or smaller), rotation and translation (moving from one location to another)). For example, if you wanted to rotate an object by 45° in two dimensions, you would use the following 2x2 matrix:
[  cos 45° sin 45° ]
[ -sin 45° cos 45° ]

To actually perform the transformation, you multiply that matrix by your position vector:
[  cos 45° sin 45° ][1]
[ -sin 45° cos 45° ][5]

That's the most important stuff in matrices. The other transformations (scaling and translation) are simpler. Besides vectors and trigonometry, the other main thing you need for 3D graphics is linear algebra. Other than that, the only other maths you need for game dev really is basic mechanics for the physics engine, and maybe basic numerical analysis if you want to do linear interpolation between game states (it's sometimes used in game loops for synchronisation, see the article I posted in the OP).
Last edited on
Re: matrixes.

Once again I recommend the arcsythesis tutorial:
http://www.arcsynthesis.org/gltut/


It explains them and gives practical applications.
Pages: 1234... 7