Servant of the Lord

In your example there's no advantage.  The disadvantage is that you're writing redundant code, and most programmers will look at that and think that you dont know what you're doing.... and wonder what other bizarre programming habits you have.

I always use 'this' for member-variables, as part of my personal programming style - but I'm consistent in doing so.

My rationale:
A) It differentiates between member-variables and local-variables.

this->memberVariable = 200;
localVariable = 200;

Other people prefer prefixing their member-variables with something like 'my' (i.e. myMemberVariable) - it's the same idea, but with a little more typing on my part.

B) It kicks in the intellisense. Typing 'memberVariable', intellisense won't kick in immediately until I start typing. I have to remember what the first letter of the variable's name is, which normally isn't a problem. If I type 'this->' the intellisense kicks in and gives me a list of all the member variable names.

Yeah, kinda silly , but I've never minded the extra typing. this-> this-> this-> this-> this-> I just pretend 'this->' is the namespace of member-variables. I fully type out std:: also. this-> is only a tenth of a second slower to type than std::.
I have to think while programming anyway, so it's not like I'm transcripting something where every word-per-minute counts.

I'm not sure about C#, but in C++ you normally don't have to use the 'this' keyword either - but it certain circumstances it is important.
 
One example would be passing the class' pointer to a function that takes a pointer of type 'Player' as an argument. What else besides 'this' could you give it, from within the class?

 

public void MemberFunc()
{
            nonMemberfunction_ThatTakesAClassPointer(this); //How else would you pass it, without jumping through hoops?
}

 

Another example would be declaring a local variable that has the same name as a member-variable.

In C++, the local variable would get precedence, unless you explicitly used 'this->variableName'.

I posted in a thread a bit ago trying to explain it. I might not have done that great a job word-wise, but at least there are pretty pictures to illustrate! 

The more digital rewards as possible, the better. Mailing is expensive, plus boxes, plus the items. And then you have your own manual labor of packing everything.

$5- name in in-game credits, name in website credits, a sticker pack, access to exclusive development blog (different from personal blog).

A game about Necromancers doesn't sound like stickers would appeal to your target audience. I'd drop the stickers entirely... unless you want the $5 (-15%) to become -$2 after mailing your stickers by airplane to Hawaii or some isolated town in Alaska (Hey, it's in the USA!).

I've also heard people have been completely sideswiped by shipping costs for Australia, even after saying "Add $15 for international shipping".

I'm not sure the stickers would be the motivating tipping point for someone to actually contribute, if they were on the edge about it.

$10- digital copy of finished game on any platform it is developed for, plus above rewards.

Steam, iOS, XBox Live, Playstation Network, Windows Store, and Mac App Store. Do any of them charge you a fee for distributing free copies of non-free games to customers directly, cutting out the store's cut? It's something you might want to look into.

According to your wording "on any platform it is developed for", in 20 years if you port the game to a new system, you might be legally obligated to give me a free copy and eat the cost yourself.

Although everyone has its own programming style, I personally don't think you should start with the game logic of the game without getting any visual output.
I like to start setting up the core components in order to draw a screen, implement all input/visual/audio APIs in an easy to use manner, setting up a basic gamestate system, entity manager incl. messaging etc. etc. I think this is actually a good programming behaviour, start by making a planning and design of what you actually need for your game.

Absolutely. A game, even if you make it without using an 'engine' that's pre-made, has components in it that can be called an 'engine'. The term 'engine' is used very generically.

I'm in no way saying start making levels before your game can display the levels, nor am I recommending to just 'code it as you go'.

Yes, design and plan out the architecture of your game, which includes the structure that makes the game run. My point is, don't try to make that structure so generic that it'll fit any game. Make the structure specific to the one game you are currently focusing on. If you make a game, you make an engine that is custom-made and specific for that game, whether you intend to or not, whether you know about engines or not. Later, you can remove those 'engine' parts, make them more flexible, and use them for another game. This becomes your 'engine'.
But if you try to make a engine that is flexible from the get-go (without having lots of experience), without having previously made multiple games, and without having a specific game in mind, your engine becomes useless because it lacks a game to keep the engine's features and goals in-check.

I'm not arguing that your game shouldn't be planned out, and engineered skillfully, but rather that you should skillfully engineer the game and engine together, so the requirements of the game actually steer the development of the engine, lest you make an engine that serves no purpose and fits no game without heavy modification.

I got the same advice when I started: make a game not an engine. But after finishing a couple of games I felt like I realy couldn't re-use much of my code.
Mostly because I thought things weren't done efficiently or weren't easy to use. At that point I started doing things the way I described above, using carefull design and starting from the ground up and now I can just use this framework I made and start coding the game almost right away.

But the key there is "after finishing a couple of games". You already understand how games work, before you were able to make re-usable components that work with games. If your very first programming project is making a game engine, you won't know how to make the engine because you never made a game.
 

So to summarize my advice: spend some time making a good design, if you write a very good reusable piece of code it'll safe time in the end by avoiding having to recode everything again.

Definitely. This applies to all software programming. Reusable pieces of code should be created for everything from text editors, to websites, to games. Reusable pieces of code on their own don't become engines. 'Make games' doesn't mean, 'Code poorly' or 'Don't plan', it means (when starting out) 'focus on your current project (the game), not on your next few projects'. It means, don't write your code for imaginary projects down the line, but write it for your current project today. Definitely write it reusable, clean, and stable the first time - you'll be able to adapt it and use it when you get to those later projects, and overtime it'll become very flexible and even more stable. But trying to write it flexible the first time (when you're a beginner), results in not useful pieces of code even for your current project.

Writing code without having solid requirements in mind, results in code that doesn't really fit any purpose.

But don't try to implement all kinds of features you're not going to use in the current game, you can easily implement those features as soon as you write the game you'll need it in.

Yes, exactly! That's one of the primary points 'write games, not engines' is trying to get across. You phrased it alot better than I did.

I'm not at all trying to say, don't write clean code. All code should be clean, almost all the code should be reusable, self-contained, and stable. I'm trying to say to write functional code (whether it be an engine or a helper library or just a few functions), you must have a goal in mind to steer the requirements, or the code usually becomes too general to use without you having to write boilerplate over it to make it usable.

Almost all games have 'engines', and so 'write games, not engines' doesn't mean to make a game without making the parts that run the game - it means to make a game (including the parts that run the game), but don't try to make a super-flexible engine before you even have a game in mind - tailor the engine to the game, the engine is part of the game, so let the game drive the design of the engine.

A game engine doesn't exactly 'make' a game, a game is built ontop of an engine (if it already exists) or a game is built directly, and the engine is refined from the generic and re-usable pieces of the game.

 

By 'game engine' do you mean something like Game Maker (which is a game engine and a game editor)? Or are you really just interested in the software part of the engine?

 

The term 'game engine' isn't super well defined. Some people mean one thing, others mean a similar but different thing. At what point a game engine ceases to become a library (or collection of libraries) and starts becoming an 'engine' is unclear. I like to think of it as the point where the libraries start to include higher level logic. ([1] [2] <- more of my thoughts on the topic)

 

I would suggest sticking with C++ and SFML, or else Python and PyGame, since either of those combinations are ones you know.

 

Then, to make your engine, I would have some clear genre in mind (to make it loads easier on yourself), and work towards making a engine for that specific genre (say, a tile-based RPG or a turn-based strategy). I would create tools (a map editor, mainly) for working with that genre, and write the code to support logic suited for that type of game.

 

Because different game genres require different logic, if you make your engine's logic too general to fit every genre, you might accidentally end up with a library or framework instead of an engine. Or, you could figure out some way of making the logic of the engine re-arrangeable to suit different genres - but even then I'd suggest having at least one clear-cut genre to work towards at first before creating a pluggable logic system to expand to other genres.

If your goal is making a 2D game engine, but no game, then cool. But if your goal is making a 2D game, then make the game, not an engine. Engines aren't really used for 2D games much, and focusing on the engine and over-engineering it leaves you without a finished playable project at the end.

 

Regardless, it doesn't matter what language you use, or what libraries. Use the language you already know best, and the libraries you are already familiar with, and work with those. Unless your goal is learning a new language or a new library, and not completing a game. 

 

Is your goal: (pick one)

A) Making a game

B) Making a game engine without a game

C) Learning a new programming language

D) None of the above

 

If A, let us know what language you already are most familiar with, and someone can recommend a good 2D graphics library for that language.

If B, let us know what language you already are most familiar with, and someone can recommend a good 2D graphics library for that language and some architectural articles or books.

If C, learn Python. 

If D, could you elaborate on your actual 1 (one) primary goal for this project?

 

Note: There's nothing wrong with wanting to make a game engine as a goal - it's really fun to do - just realize it comes at the expense of actually making a game.

Many beginners think they need an engine to make a game, but that's not true, and they end up tripping over their 'engine' and failing to produce a game. This is the only point I'm trying to get across. The idea of an engine is appealing, but misleading, to game developers.

 

Engines come out of games before games come out of engines. Engines are the reusable components of pre-existing games wrapped up in a consistent and easier to use interface for future games - but focusing on the engine without a solid game in mind leads to an engine that isn't usable for any real game without heavy alterations - unless a developer has already made a half-dozen real games, in which case the real-world requirements of engines are already in his mind.

Making an engine instead of a game is putting the cart before the horse - from finished games come the knowledge and re-usable pieces to make engines.

 

You said, "But let's say I know nothing!". Okay then, start here, and learn to crawl (basics of programming) before you walk (Pong and Tetris) before you run (a original 2D game of your own design). The process is slow, but very much worth it! 

If you need help, there are thousands of gentlefolk ready to help and standying by on these forums when you have a question that Google can't answer.

std::vector<Object> is perfectly fine if Object isn't too large in memory (it's member-variables count towards the memory, but not non-virtual functions). If Object has less than, say, 10 member variables, I'd recommend to just do std::vector<Object>.

 

std::vector<std::unique_ptr<Object>> would be good if Object is very large (very large), or if you need to hold Objects that are in some way 'null' in the vector. But you can just do that with a member variable of Object anyway if it makes sense to the class.

 

std::unique_ptr<Object[]> wouldn't be a good idea (it might not even compile, but I'd have to check). Everything it offers, std::vector<> also offers, but std::vector is designed for the purpose of dynamic arrays and std::unique_ptr isn't.

 

To avoid any confusion, std::vector calls the destructor of Objects just like std::unique_ptr does; and both by default hold the Object in dynamic memory. Both also cleanup after themselves. But if std::vector is holding normal pointers instead of instances, then it won't clean up what the pointer points to. (std::unique_ptr is an instance that contains a pointer, which it cleans up in its destructor, so it's cleaned up).

 

std::vector<Object> = cleaned up.

std::vector<Object*> = The memory the pointers point to are not cleaned up.

Yes that is correct, you wouldn't add them from their constructors if the array actually owns the objects.

 

If you think in terms of ownership:

Something owns an std::vector that owns the Objects. The Objects don't know about each other. Whatever owns them knows about all of them, and can handle the interactions between them using the functions the Objects provide.

 

For example, to test if one Object is colliding with another, you might have a function in Object that takes another Object (by const reference*) as a parameter.

The class that owns all the Objects can pass one Object as a parameter of another's function.

bool Object::IsColliding(const Object &anotherObject) const
{
     return /* ...check if 'this' object is overlapping with 'anotherObject'... */
}

 

Object objectA;
Object objectB;
 
if(objectA.IsColliding(objectB))
{
    //...
}

 

So the 'objectA' doesn't know that 'objectB' exists, though it knows that other Objects *could* exist, and can take them by parameters for temporary work, but shouldn't keep track of the other Object for longer than the duration of that one function call.

 

*A reference, because you aren't wanting to create a copy, and const because - in this case - you aren't wanting to modify the Object passed in.

You can, but the array has to be static. Also, by 'array', it's much better to use a std::vector.

 

So like:

 

class Object
{
    private:
    std::vector<Object*> AllObjects; //A vector of pointers.
 
    public:
    Object()
    {
         Object::AllObjects.push_back(this);
    }
 
};

 

However, you have the problem that you'd have to remove objects from the array when the object is destroyed (otherwise you'd still have pointers to objects that no longer exist).

 

It might be better to have the collision between two objects be managed by outside of the Object's themselves, and that the array of Objects are also outside of the Object class, and the array isn't an array of pointers, but an array of the actual object instances themselves.

 

An Object shouldn't know whether other Objects exist, unless it "owns" the other Objects or is related to them (as children or parents or whatever).

Why is SFML a dead end? It's already released a very stable developmental version, and although the developer hasn't released an official stable release or updated the tutorials, it's been less than a year. SDL 1.2 was released many years ago (I find dates as early as 2001) and has only had a few minor bug patches since then. SDL 2.0 is maybe close to release, but so is SFML 2.

 

I'm not saying SDL is bad or that SDL 2.0 won't be released, I'm just questioning the 'SFML seems to be a dead end' statement which I am really confused about. Was there some announcement I missed?

It'd be difficult to balance the three requirements:

• Not completely limited if you don't farm
• Not completely overpowered if you intensely farm
• Must actually fit in with the rest of the game without seeming like two separate games glued together

How's this? Farming, instead of directly affecting the power of your hamtaros in battle, effect the moods and mental health of your monsters.
 
First, farming brings in some income (which can also be acquired by winning battles with other NPC pokemon trainers), which can be spent on items (health potions, special monster equipment (like harnesses and stuff), etc...).
Second, you can use crops to lure wild monsters so you can capture them (Final Fantasy 7 did this with Chocobos and 'Greens'). Different plants are more desirable to different breeds of monsters. Crops also somehow help during the breeding phase (FF7 again).
Third, even after you capture monsters, they still want to eat food. If you don't feed them well, or only feed them junky scrap plants after selling your best crops, make them depressed and/or angry at you (depending on the temperament of the breed and the individual personality of the specific monster of that breed). This, combined with how you physically train your monster (scolding too much, not being firm enough, spoiling them with too much treats, beating them, etc...), how hard you press them in battle and in physical exercise, all effects the mental health of the monster.
If the monster's mental health is terrible, the monster may disobey your commands during battles, and even turn on you if you aren't a good trainer.
 
This happened in the 1999 RPG game Guardian's Crusade, where you traveled alone, but you had a baby dragon with you (who grew gradually during the course of the game). The baby dragon, if not treated well, didn't follow your commands, or even attacked you while in battle. Later, when my dragon became larger and learned how to breath fire, he liked to roast me during inopportune moments of combat. 
 
(To quote IGN: "this RPG features a unique relationship-building system between you and the pink, morphing baby [dragon] ... If you treat it poorly, it'll attack you, but if treated too nicely, it'll become lazy, and won't attack."[/size])
You get to interact with the dragon outside of battle too, asking it to 'fetch', or petting it, or feeding it hamburgers, dead bugs, chocolate bars, beef jerky, or whatever other food you might have on you. The hamburgers and chocolate bars were primarily for you and healed health in combat, but I figured a the dragon might like them also and fed mine lots of chocolate. It seemed to like the bugs better. *shrugs*
 
So all the above combined becomes a mix of Pokemon, Harvest Moon, Guardian's Crusade, and, uh, Nintendogs?! 

Make the easter egg data be assembled from pieces of real data legitimately used elsewhere in the game.

 

And here I was thinking you were talking about actual easter eggs, since Easter was yesterday. 

Both are really good libraries. Either one will work for you. I'd lean more to SFML, though. It's very cleanly written. My full opinion is written up in this thread.

Currently, I use SFML for my projects, but I've also used SDL extensively, and if I was forced to use SDL again, I wouldn't mind at all.

 

The official SFML tutorials are excellent (though not fully updated for 2.0 yet). For SDL, Lazy Foo's SDL tutorials are fantastic.

I'm wanting to load a file, and put the entire file into a std::string.

This method works perfectly fine:

//Read the file into the stringStream.
std::ostringstream stringStream;
stringStream << file.rdbuf();
	
//Convert the stringStream into a regular string.
return stringStream.str();

However, I was trying this method (which I've never used before), and encountered a weird issue where it's not reading the entire file.

//Loads the entire file, newlines and all, and returns its contents as a string.
//Returns an empty string if the file doesn't exist.
std::string LoadFileAsString(const std::string &filename, ReadMode readMode)
{
	//Open the file for reading.
	std::ifstream file;
	if(readMode == ReadMode::Binary)
		file.open(filename.c_str(), std::ios_base::in | std::ios_base::binary);
	else
		file.open(filename.c_str(), std::ios_base::in);

	if(!file)
	{
		Log::Message(MSG_SOURCE("FileFunctions", Log::Severity::Error)) << "Failed to load '" << Log_HighlightCyan(GetFilenameFromPath(filename)) << "' at " << Log_DisplayPath(filename)
																		<< "\nDo I have sufficient privileges? Does the file even exist?" << Log::FlushStream;
		return "";
	}

	std::string fileContents;
	
	//Find the size of the file, by seeking to the end.
	file.seekg(0, std::ios::end);
	
	//Resize our buffer to match the size of the file.
	unsigned endPos = file.tellg();
	fileContents.resize(endPos);
	
	//Seek back to the beginning of the file.
	file.seekg(0, std::ios::beg);
	
	//Read the file into the string.
	std::cout << "Buffer size: " << fileContents.size() << std::endl;
	std::cout << "Seek size: " << endPos << std::endl;
	file.read(&fileContents[0], fileContents.size());
	
 	//Temporary stuff while trying to figure out what happened:
	if(file)
        {
		std::cout << "All characters read successfully." << std::endl;
	}
	else
	{
		std::cout << "Error: only " << file.gcount() << " could be read (of " << endPos << ")" << std::endl;
		
		std::cout << "Error flags include:\n"
				  << ((file.rdstate() & std::ifstream::goodbit)? "\tstd::ifstream::goodbit,\n" : "")
				  << ((file.rdstate() & std::ifstream::eofbit)?  "\tstd::ifstream::eofbit,\n" : "")
			      << ((file.rdstate() & std::ifstream::failbit)? "\tstd::ifstream::failbit,\n" : "")
			      << ((file.rdstate() & std::ifstream::badbit)? "\tstd::ifstream::badbit,\n" : "")
				  << std::endl;
	}
	
	return fileContents;
}

The file certainly exists, and it's opening fine, but I'm getting:

Buffer size: 859
Seek size: 859
Error: only 784 could be read (of 859)
Error flags include:
	std::ifstream::eofbit,
	std::ifstream::failbit,

Using a hex editor, I see 859 bytes
Windows Explorer reports 859 bytes

Why is it stopping at only 784?

I checked the character it is stopping at, and it's only a space. I did a Ctrl+F (using the hex editor) for 0x1A (EndOfFile or Substitute char in the ASCII table) and it never occurs in the file.

What is going on?

 

------------------------------------------------------

Ah, I just found the problem through more googling. Since this problem was confusing me, and since I had already typed out the post, I figure I'll just post the thread anyway for anyone else that encounters the problem.

The problem occurs because Windows marks the end of a line with first a carriage return character (\r), and then a line-feed character (\n). Two characters, two bytes.

When loading with ifstream() from file, if in text mode, both bytes will be combined into a single newline when read.
When I seeked to the end of the file, it told me the number of bytes.
But when I read the file into my buffer, it combined the two line-ending characters into one, which counted as a single byte.
So the byte-length of the file was greater than the number of characters read from the file (once carriage returns and newlines were merged into single newline characters), because I was reading in text mode.

This means my solution is one of two things:
A) Read the file in binary mode. The string will then contain both \r and \n in the text.
B) Read the file in text mode, and understand and be prepared for the merging of the two characters.

I'm just going to use option 'B', and cheat by letting the operation 'fail', and if I detect the failbit set, I'll get the real number of characters read using gcount(), and use that to truncate the buffer after-the-fact.