I'm putting the finishing touches on my mapmaker right now, and the entire process has left me embittered. Have you ever read "If you give a mouse a cookie"?
Programming a game is kind of like that. If you decide to program a game, you're going to need to implement a graphics engine. If you only want 2D square tiles with no special effects of any sort, this is easy. If you want the ability to rotate sprites, handle alpha translucency (rather than straight out transparency), and screen-blended particles, you may be in trouble, because you're either going to have to go totally 3D and deal with the preformance hit of transforming all your sprites every frame, or you'll have to come up with some frankenstein 2D/3D hybrid (Direct3D, thank goodness, can actually write to DirectDrawSurfacey7's which will help you out, but it's still tedious).
nce you have that done, you're going to need to write a scripting subsystem that gives you control over how the GUI is displayed and can control the monster AI as well. While we're at it, you're going to need to program an object/actor system that is a representation of every object currently active in your game. And you'll need to design the scripting language and interpretter which reads those scripts in when the program is run. Maybe your script interpretter can also optimize the scripts at runtime, in which case you're writing a compiler, which isn't easy.
And since these objects are going to need a ton of graphics and you can't load *all* your graphics into memory at once (my game currently has 130mb of graphics, including 30mb of tilesets and 90mb of character graphics - those aren't 24bit bitmaps or PNGs, btw: I'm talking about custom compressed, indexed sprites), you'll have to write another subsystem which will only load the graphics you need into memory, and know when it can get rid of graphics that are no longer in use. You'll probably want to write your own graphics format as well, to help compress all your graphics (uncompressed, I have no doubt that I'd be looking at more than half a gig of bitmaps!) and to speed up reading your sprites into memory.
Now, you have objects that can be controlled by AI and can draw themselves using graphics which are loaded only when neccesary. But where are they going to walk around on? Better get to work on designed a map format. Your map format isn't just what tiles are where, by the way, it also contains map scripts, locations, object spawn points, blocking information - and now that you've designed the map format, you had better get to work on designing a mapmaker so that you can display all your graphics. God help you if your graphics engine from the main game isn't reusable, because otherwise you're going to have to write the whole darn thing over again.
What about music and soundeffects? Once again, you can't load all these resources into memory all at once - you'll push up your minimum spec so high it wouldn't be worth the ease of use, so you'll need to design a system for your audio similar to your graphics loading system.
What about drawing text? It doesn't matter if your sprites are pre-rastereized, truetype drawn on the fly, or sprite-based: drawing a 128character spring every frame will absolutely kill your framerate. So you're going to need to write a text renderer object which renders text strings that the engine wants to draw to a seperate backbuffer surface, and then maintains a database of these strings so that the next time that string needs to be drawn, you don't have to redraw the entire thing.
The list goes on and on.
Or, you could have stuck to GM, which might not have given you all the freedom you have when you're writing every last bit of your engine yourself... but it also eliminates all the tedious set-up work which I've described here, and allows you to go straight to programming your game.
The choice is yours to make. =)
<3, Fish.
