Suspense

That's a good point.  Have you looked at marching cubes?  The algorithm will help you generate just the smooth parts of the actual terrain, then you'd have to add the flat sides of the cubes yourself.  It isn't too hard, but it can be slow for large terrains.

Changing the noise function won't do anything to solve the problem.  It may or may not make it less noticeable, but the actual problem will still be there.  What does it look like without clamping the values to [0, 1]?  I expect it would smooth out the terrain, but then some of the blocks would extend a bit past their grid spot.  But is that really a problem?

 

The other suggestion I can make is to look into an algorithm like marching cubes.  This lets you extract a polygonal mesh that describes the surface defined by your noise function.  A little extra work will make it generate the cubed pieces you're looking for.

Microsoft needs to stop pissing off there devs or everyone will switch to IOS eww.

I would switch to Linux in a heartbeat before going to Apple.  Actually, even if all computers in the world except for Apples were to stop working, I would start a new career before switching to Apple.

And with the train wreck that is Windows 8, I'm getting very close to switching over to Linux completely.

The reason I decided to use singletons is that there's going to be only one instance of Fireball at all times and rather than calling new and delete, I thought it would be better to just make it singleton

wait.. I just got an idea that forced me not to use singleton.
thanks, anyways.

When you come up with a solution to a problem you've asked about, please post that solution.  Someone in the future may search for something related, find your post, and just see "nevermind, I figured it out", which is frustrating.  You're not helping anyone by not posting it.  Posting your idea may also spur more discussion that leads to even better ideas.

you can then really test out all those numbers and equations for your documentation, and will be able to show a potential programmer exactly how it should work rather than describing it.

This is the point of prototyping.  It's not for us, it's for you.  When I'm working on a new game design, I don't consider any of my numbers or equations as fixed until they've been prototyped and tested.  You can theory-craft all you want, but at the end of the day it's how the game plays and feels that really matters.  Prototyping is what gets you there.

I really like your idea of playing a non-magic-user in a fantasy world.  I think you've found an interesting situation that hasn't really been addressed in games before.  As you said, most RPGs would make you the meat shield for your own spellcasters.  But if you're on your own, what kind of tactics would you need to use?  Very interesting!

Your introduction says the game will change how we perceive magic and melee combat, but you never really describe how.  If that's the main hook, I'd need to hear more about how it works before I can tell if I'd play it or not.

Just because a game character provides the source position of a projectile doesn't mean the character needs to own the projectile.  Once the projectile exists, it lives in the world just like all other entities.  Assuming the the World is what manages characters interacting with the environment and with each other, the World should also manage the same interactions for projectiles.

First, some background for my comments: some people use the presence or absence of goals to define something as a game or a toy: games are activities with goals to be achieved, while toys are simply objects to be played with.  By that definition, SimCity, Minecraft, and the like are toys, not games.  A ball is a toy to be played with; basketball is a game to be won.

I find this perspective useful in describing my own attraction to and interaction with computer games (using the general definition of digital entertainment media rather than the specific definition above).  I love the idea of toys like Minecraft and Dwarf Fortress.  But I find these toys don't keep my attention very well.  Games that provide some kind of goal hold me attention much better, even when the goal no longer holds any challenge (as attested to by my countless replays of Metroid games.)  Interestingly, the game that held my attention the most consistently is Terraria, which kind of blends the two approaches by having an open world along side a steady progression of equipment, abilities, and difficulty.

From a development standpoint, they both have difficulties.  For a game, you need a defined way to evaluate success or failure.  In many cases it's as simple as reaching the end of the level or having a higher score when the timer reaches 0.  Toys can be just as simple or many times more complex: compare the simplicity of Minecraft's creative mode to the incredible complexity of Dwarf Fortress.

Based on your post, it sounds like you're a complete beginner to programming.  This response is based on that assumption.  It should not be taken as a harsh criticism, but as an attempt to convey the information someone in your position needs to start on the path to success.  These points are not necessarily in order of importance.

• You don't need an "engine" to write a game.  Sure it can make it easier, but you can certainly write a game without a pre-built engine.  One of the most common words of wisdom you'll see on this forum is "don't write an engine, write a game."  You can then take the reusable bits of your game code and start building your own framework library for the next game.
• It's great that you have a specific goal in mind, but you need to understand that you won't be able to reach that goal without several years' experience in game development.  A lot of different factors go into a game like you've described, and each can be very complex in its own right.  Very few people can start on such an ambitious project and succeed the first time.  If you start small with a very basic game (like Pong, Breakout, etc) you'll be much more likely to finish a project (and make sure you finish it).  That project will give a huge boost to your motivation and skill, as well as some reusable code like I mentioned above.  For the next project tackle something a little more difficult, finish it, take out and refactor the reusable bits to keep building up your personal library.  Rinse and repeat.
• Above all, don't give up!  Game programming is very complicated, and almost all of us lose motivation at some point.  In my experience, the hardest part is just getting started every day.  But once I push past the getting started part I can keep going for a while.

Variations on these themes pop up on here every so often.  Plenty of discussions have been had on why this type of game is or is not feasible, and as you asked that these discussions not occur in this thread, I won't go into it.  From purely a design perspective, here is one of the main problems:

... and imposing your guilds will on the rest of the populace as most real life empires have done....

Games are supposed to be fun.  But I don't have fun in games where some other player's will is imposed upon me.  If this is one of your design goals, then you're designing a game where only a few of your players end up having fun (or at least your player base has very disparate levels of fun).

To be more clear, you're talking about writing your own scripting language.  And yes, as far as I can tell professionals handle cutscenes via scripting.  Your giant switch statement is probably the simplest way to think of it conceptually.

The next idea was to load instructions from a file. This way I would have just one scene class that could load a variety of custom content files. This would be nice as well because it would allow me or others to easily add content to the game even after its released. This seems like to way to go but the problem is I really don't know how to do this well either. My first attempt was creating a StageDirection class that could call a variety of different methods like .MoveCharacter() based on what a string says to do.

Congratulations, you have just discovered the essence of scripting.

So what I'm wondering is: What's the difference, from a programmer's perspective, between a game built from code, and a game that was built from an engine. It seems to me like you'd have to do much of the same things. ie. set up a scene graph, create objects, handle input and output. The only difference I could think of, would be with an engine you allow users to alter or use their own assets more easily.

The difference is time and effort.  It's a lot more difficult to write a scene graph than it is to use a scene graph that someone else has already written.  Likewise with creating models, there's a big difference between writing a model loader and just calling Load(model).

Make a game and you'll end up making an engine as well

  When most people say that, they're talking about making a game from scratch, not with the help of an existing engine.  And the quote is a little misleading.  If you write a game from scratch and design it the right way, you will end up with reusable chunks of code for common things like loading models.  But this collection of code snippets isn't an engine, it's just spare parts.

Obviously, definitions depend on the person you're talking to.  But generally it seems the term RPG is used when the game has character advancement (leveling).  Adventure games usually only have item advancement (hearts in Zelda count as items by this definition).  So if the game has XP, it's an RPG.

Fastcall is right in that "major" games will be out of your league for a while.  But you can still think in terms of game development as you work through learning a language.  Start thinking of the types of problems you'll have to solve in order to make different types of games.  As you learn the programming and engineering skills, think about how you could apply those techniques to the problems you've thought up.  Even better, you can take a simple game component and try to implement that one piece.  For example, you could work out a simple menu system or learn to read and write data files.  These are not games themselves, but the skills are very applicable to games.  And learning to solve problems on your own is one of the most important skills you can learn.