As the title suggests I am looking for a suitable game engine. We are 3 programmers that have never made a game before but now want to create a complete game. The game will have: C++, 2D graphics, top down view, Real time action and a story component.
Sadly I failed to find a real engine which uses C++ and still allows modifying components to better fit into our game.
Thank you in advance for helping us.
Can you give a little more context of what you need?
I have been using orx (http://orx-project.org/) for 3 years, it is written on C, but has a C++ shell as well (called Scroll) and brings a lot to the table such as support for animations, sound, particle effects, FX* and time tracks**.
It is core idea is to have objects described on ini files and create/control them via source.
It has a small, but very active community (which now I am a part of) and questions on the forum/gitter are answered pretty fast.
* Basically it changes an attribute of an object for a given period of time, very useful for small effects. For instance, you can use it to change an object alpha, which causes a blinking effect, that serves as an enemy death effect.
enet_host_broadcast will send a packet to the local network for everyone to receive if they're listening to it. I don't think that's what the OP wants.
The ENetPeer is the main connection object representing the "other end," so I imagine this is valid until such time that the connection goes away. I don't know what kind of notification you get when it becomes invalid, though.
Are you sure? I just tested here (server running on NY based VM, clients running on my machine).
I am thinking to go down in a road trying SDL and Unity2D at the same time. Apart from the 'handmakehero' (looks awesome project) what other links/tutorials would you recommend me for these SDL and Unity2D ? Based on you experience so far, are there any must-see (video) tutorials or books ?
That seems a bad idea. I would write down the features I want my game to have, then find out if I have any idea how to code it in a simple way (for instance, I want monsters to attack and people to lose HP) or if it is complicated (for instance: I want monsters to move to players, avoiding obstacles - a.k.a: pathfinding). If it is complicated, find out if there is a lib that solves this problem or if the engine has support for such a feature. After this is done, I would pick one library and use that one only. Also keep in mind that those are not the only engines in the world, there several other 2D libraries out there.
Another pro-tip (believe me, I took a long time to start doing it, and regret for not doing it early): use a version control system! And commit often! I used dropbox a few times and it was messy as hell! I would suggest git on bitbucket (if you want a private project) or github (open source projects for free, you can have private repositories with the pro version). You can also use a git remote on dropbox, but you will miss a lot of useful features.
Finally, some tools and resources you should definitely take a look:
Can someone (as best you can) attempt to draw out a real-world example of how Pointers are useful?
Say you went to a party, you are with a heavy coat, you pass by the cloakroom and leave your cloak, the guy working there gives you a paper that says "Wardrobe 16". You enjoy the party and before you leave you go back to the cloakroom and deliver the paper, the guy gives your coat back.
In this example the wardrobe is the memory block, the coat is the memory content and the paper is the pointer.
There are several utilities for pointers, but in the general case they are useful to access memory from scopes other than the one it was created. The use and the scope is determined by where the memory is being stored (text segment, stack or heap), but I guess this would be a deeper discussion.
1) Knowing that I'll eventually need graphics, is it ok to build a rudimentary MUD and work from that? Or is there a completely different mindset I should be taking? That is, will building a MUD first hinder me more than help me?
It will help you a lot. Start small and grow over it, since you are a beginner you probably have no real idea of how complicated creating those things actually are. Also, you can easily scale to graphics, pathfinding and many other control structures you will need to build.
2) There are a *ton* of aspects to game development (art, itemization, the logic behind every object, etc.). Is there **a)** a canonical breakdown of these things—like the scientific method of game-design? **b)** a most important one I should be working on first?
Nope, it is not rocket science, at best you will find some design patterns and work methods that will reduce the amount of work and increase its quality.
2) While I'm open to *not* "reinventing the wheel," my being such a nublet, and the fact that I've never seen a game with the mechanics I'd like to implement, makes me hesitant to use already-existing stuff. I'd like to build what I can, then, when I'm well-versed enough, look into using something else (or improving my own!) Is this ok, or are there some things such that there's *no* reason to code myself? (I'm not looking to pump out a quick game and make cash.)
Really depends on what you are really interested in focusing your knowledge. I would say stay in middle ground by using libraries, i. e.: if you need to set the properties in the code (and understand why the properties have the given values), you are likely to be fine. If it is a tool that you just call DoItForMe() or push a button and everything works, you are unlikely to learn anything from it.
3) I'm under the impression that "building a game from scratch using C++" means I'll be coding *everything* in C++. Is this viable—or is it more like saying "I'm going to use binary to build a program?"
Both are possible, but the first one would take you 50 years, the second will probably take a few years.
I don't want to be negative about it, the most likely prediction is that you will work on it for a few months and quit. That is not bad, as long as you learn a lot from the experience.
Many years ago I gave it a try, mostly to learn, and boy, did I learn. I learned how to serve multiple clients on a network program, how to pack data (server was on C, client on python), basics of pathfinding, A LOT about multi threaded application, a little of physics and a little of shaders.
4) What's love like?
Do something over and over again, be happy doing it and never looking back.
I guess the most simple (hence, pretty generic) and popular 2D C++ engine is SFML.
I use ORX which is a C engine with a C++ version (called scroll). It has quite a lot of features (e.g.: particle and graphics effects) and is oriented to use ini files, so you can easily change and create new things.
As for C# unity3D (don't mind the name) is by far the most popular engine around here.
As people stated, there are some libraries that have better tools to help you.
I am personally a fan of ORX, which also a C engine and is data-oriented. It uses ini files to describe objects making changing things in you game much easier. It also support graphic effects* and particle effects, which is a great addition.
If you are willing to use python you can also use Pygame, which can be seen as a SDL adaptation for python. The main advantage (besides using a higher level programming language) is that there are literally thousands of code snippets that you can use.
* Basically a variation of one attribute of an object, for instance the classic monster blinking before dying is a variation of the alpha of the monster.
Not entirely on topic, but when you have an idea that sound good, you should probably do a very simple prototype. This will give you two notions:
1) Is the game really fun? A lot of times what seens cool on paper gets very boring and repetitive in the gameplay (in my experience, it is a fun mechanic to do once or twice, but a whole game with that mechanic is just bad).
2) It will give you a good notion of what and how you will need to code when you move to the actual game. Also, you can simply refactor some parts of the code and use them.
In time you will notice that you will be able to define a decent architeture when working on the project from the scratch and just improve it as it evolves. Also, may I notice that extremely generic code tends to be very confusing.