Archive for category Advice
How To: Keep Your Console Window Visible
Another common beginner’s query on the GDNet forums concerns character mode (”console”) applications. Specifically, keeping them open after they have completed execution, usually so you can examine the actual output produced. A frequent response is the suggestion to insert some sort of artificial pause in execution right before the closing brace of main(), such as a call to system("pause"), cin.get(), or similar.
There is nothing altogether horrible with doing this. It is not the end of the world. It will not cause any harm — the only potential snag would be in the use of the system() call, because interpretation of the input string is implementation defined (it may do nothing on some platforms). But that’s not usually a scenario a beginner need concern themselves with. In programs that are really just quick and dirty hacks, it would hardly merit a second glance… However, in larger, “real” projects, it does constitute a design flaw: “real” console mode applications typically are designed for batch pipelined processing. Data compilers; translation, reformatting or filtering tools; asset processors… Utility applications that are part of some larger aggregate operation that would be basically useless if you had to “press any key to continue” after every program in the sequence was finished.
Put another way, pausing at the end of your console program is roughly equivalent to having a GUI application pop up a dialog box when you selected the “exit” option that said “Click okay to exit.”
Finally, even for quick and dirty hacks it is pointless and inefficient, since it requires you to type some code (even if it’s a small amount of code) to do something that you can do with no code at all. The reason the program “closes immediately” is because your IDE is creating a temporary console context within which to run your code, and closing that context as soon as the program completes. Any decent IDE should have an additional option to run your program in such a way that that created console remains open.
Below, I’ve provided screenshots of the location of the appropriate command for Visual Studio and Code::Blocks, two of the most popular IDEs for C++ development. By making use of these options, you’ll no longer have to clutter up your code with hacks that are specific to running your program within your IDE (which are detrimental to running the program “for real”) and you should be able to work just a little bit faster because you’ll have a better grasp of how to use your tools.
Visual Studio
When you run your program in Visual Studio, you are usually invoking the IDE’s “Start Debugging” command. There is an additional “Start Without Debugging” command, usually just under the first command, inside the Debug menu (unless you’ve rearranged your menus). Your key bindings may be different than those in my screenshot here, but the command itself will still function the same.
The “Start Without Debugging” option keeps the console window created for your program open until you hit a key, basically automatically inserting the equivalent of system("pause") after your own code, just for this execution.
Code::Blocks
Code::Blocks keeps it’s “keep the window open” command in the Build menu.
An interesting feature is that Code::Blocks will provide you the return value of main(), and the execution time, directly in the console window your program runs in.
How To: Create A Blank C++ Project in Visual Studio
In my capacity as the For Beginners forum moderator at GDNet, I have the distinct pleasure of having to answer the same questions, or address the same confusions and misconceptions, repeatedly. One of the more common such issues involves creating a new C++ project in Visual Studio.
Typically this impacts users who are migrating from an outdated tool like Dev-C++ the most, because Dev-C++ did not require you to have a project structure in place to compile. Users coming from that kind of environment are often turned off, initially, by having to create projects in VS, especially since so many of them simply click through the wizard dialogs without much comprehension. In their defense, of course, there are aspects of those wizard dialogs — and default settings for projects — that are suboptimal for beginners, and the UI for accessing and changing those options isn’t very discoverable.
So, to begin, launch Visual Studio and create a new project (the option is in the File menu). You should be presented with a dialog similar to the one below.
Notice the tree view on the left — the organization of the tree view will look slightly different based on the exact flavor of Visual Studio you have, but you should be able to expand and collapse items to find the section shown here (the “Visual C++” section). You’ll want to select “Win32,” which should change the set of options displayed on the right to include at least the items shown in the screenshot.
Some people occasionally choose the “CLR” option, which ultimately leads to the creation of a C++/CLI project, not a native C++ project. If you don’t know the difference between C++/CLI and C++, you probably do not want a C++/CLI project. Trust me. Pick “Win32 Console Application” from the “Win32″ section instead.
You will end up at a window similar to the above screenshot. Note how the text strongly encourages you to click the “Finish” button (at the bottom of the window, not shown here). In fact, it doesn’t even mention the “Application Settings” text that I’ve hilighted over on the left. This is why I said this wizard UI wasn’t very discoverable — that text is actually a hyperlink style button that provides you with different options for your project. Click it and see for yourself.
When you first get to this screen, the “Empty Project” checkbox I’ve hilighted will not be checked — you want to check it so things look like they do above. In particular, the other checkboxes should get greyed out (it will not matter if they were checked or not once they’re disabled; you can see here the option for precompiled headers is still checked but we will not have PCHs enabled in the resulting project).
At this point, you can click the “Finish” button and you should be presented with a nice, mostly-empty project. VS will still create some standard filters (the things like look like folders in the solution explorer), but it will not create any files. Nor will you have certain advanced options like precompiled headers enabled by default. If you had hit “Finish” immediately instead of clicking through to the Application Settings page, you would have had a project with precompiled headers enabled, a handful of extraneous headers to support the PCHs, and a source file containing a nonstandard _tmain() entry point designed to help provide ASCII/Unicode character set swap support.
None of that is particularly useful for the beginner, and in fact often gets in the way and causes confusion. I’ve seen a lot of new Visual Studio users that believed they had to write “special C++” in Visual Studio, mainly because they chose the wrong options during the creation process. Unfortunately, this tends to be Visual Studio’s fault just as often as it is user error.
Hopefully this post will help clear up some confusion. At this point you should be able to create a new C++ source file (you can right-click any of the “folders” in the solution explorer to get a popup menu allowing you to add new files to the project; this is shown my last screenshot) and type the following canonical Hello World example in:
1 2 3 4 | #include <iostream> int main() { std::cout << "Hello, world!\n"; } |
Compile, run, and away you go.
M is for Massive
Hobbyist developers don’t make MMOs.
Which isn’t to say they don’t try, or don’t think they are. But more often than not, they are simply misappropriating the terminology because they think it sounds cool, because it will attract more attention to their project. This is often true, although the attention they end up cultivating is typically the negative kind.
Here’s the thing: that first “M” in the acronym “MMO” stands for “massively.” That means the expected player base of the game is large. Not fifty players. Not a hundred players. Multiple hundreds of players is a bit closer to the mark, and ideally you’d want a number somewhere in the four-digit range. Building a game with the capability to support peak concurrency volumes like that involves two things that differentiate such games from others. First, it requires the technical acumen to build a network infrastructure — which consists of both software and hardware — that can scale appropriately. Second, it requires actual people to actually connect and play the game.
The complexity curve to achieve the first point, the technical scalability, isn’t linear. MMOs are involved… there are client programs, server programs (often multiple types… login and authentication, backups, core gameplay, tournaments and player-versus-player arenas, economics, web portals), physical machines that run those servers, and IT and security glue linking everything together and guarding against thirteen-year-olds with too much time on their hands.
It is extremely unlikely that any given hobby developer will have had the requisite experience with the problem domain to build all that out correctly — not the first time, at least. Because of that, their game will evolve in painful, halting stutter-steps. The first hurdle might be around the hundred-player mark. Perhaps it will be because the server is persisting character data too frequently, causing the database save to bottleneck and become unstable. Perhaps it will be because the core networking layer is using a naive mechanism for handling clients, and starts to thrash trying to service all the pending and active connections. It could be for any number of reasons, but something will break. It will need to be fixed, and then eventually something else will break, and so on and so forth. With time, dedication, and a healthy measure of elbow grease, one can end up with an MMO this way. It’s been done before, although it’s uncommon. Of course, this is assuming the players stick around through all the trials.
Which brings us to the real meat of the issue: the players. Getting players is tough for hobby and indie games, because they are competing for eyeballs that are far more likely to go to big commercial titles with huge publisher-backed budgets and similarly turgid marketing campaigns. Player base retention is tricky as well — typically this isn’t given as much thought, since the important thing for financial success is to dazzle a player enough to cause the cash to fly swiftly from the wallet, after which they are not given much thought. This doesn’t work in the long-term, of course, and it certainly doesn’t work in the MMO space, which is currently dominated by the monthly-fee culture. You’ve got to really keep players engaged to keep them coming back, especially if they are paying for the privledge and especially if your game is undergoing those inevitable growing pains discussed above.
The grim truth of the matter is that most hobby games will never achieve nearly enough players to actually scale and stress the system enough to be considered an MMO on the basis of that first, critical, “M.”
But then again, does it matter? There are generally two kinds of person who want to make an MMO as a hobby project: the guy with a lot of ambition and not a lot of grounding in reality who really does want to make the next World of Warcraft where you can participate in a massive online world in which you can do anything, even marry The Hulk, and the guy who really just wants to make a cute little persistant world of his own imagining that he can log in to and fool around in with his buddies. There is no hope for the former — and regardless, if they manage to get anything off the ground, it will end up being the latter kind of game anyway. The latter’s goals, though, are actually quite achievable — yes, they are misusing terminology by calling their projects MMOs, and they should be gently corrected. But there is no reason to jump down their throats, telling them how impossible their projects are and how they will never, ever have any success.
So the next time you see some poor newbie on your favorite game development forums or IRC chat asking for help on something related to an “MMO,” try to get a bead on just what it is exactly that is being built before flying off the handle. Jumping to conclusions, bashing them, failing to provide any kind of assistance, correction, or guidance — that’s just a disservice to entire hobbyist game development ecosystem.