titaniumdecoy

What is an isometric game? What game are you using to test it? Where can I get said game?

frankish

What you said is not true. Having to jump around in code a lot is a pain in the ass. I've done it before and it's no picnic. Bad coding style? Who cares? It's what's practical that counts. This thread was not supposed to be about how I code but about the level editor itself. It seems like this was a waste of time. No one asked for the source code of The Fly Game.

frankish

An isometric game is a 2D sidescrolling game like Super Mario Brothers. With this level editor you can design games like that. I was using Super Mario World to test it.

Zap

I think this project was a rather good idea. I like the final product.

Cipher

Seems like this is going to turn into a flame war very soon...

I think it's useful... if all you want to do is make side-scrollers... but I think that a level editor for a custom game would've been better

Don't get me wrong, it's way above anything I could do.

__________________
And there was much rejoicing... Yay....

frankish

The whole reason I made this level editor was to create levels so that later I could challenge myself and implement them or possibly create a fun game.

Ooble

Er... no it isn't. An isometric view is a 3D top-down view in the vein of, say, Red Alert 2, or Diablo II.

http://en.wikipedia.org/wiki/Isometric_projection

__________________
Me :: You :: Them

Mad_guy

Multiple-source files make your code much easier to track and modify. You can separate your source files into segments related to certain things such as your game engine and seperate it from your rendering engine in a REAL game. It also makes it a lot easier to later modify your code and build upon it rather than have lots of kludge in a single source file. Have a class named cEnemy? Put it's prototype in a header, and implementation in some different files. This is good for people wanting to modify your code too since you can just take a look at the header and try and get a general idea the class layout. Got yourself a full blown game engine? Seperate it into things like physics files, rendering files, voice synthesis files, music, math functions and movement.


Debugging is also, most certainly not made trivial just because you choose the monolithic route. Especially if the bug is hard to reproduce. Yes, congratulations, you can find an off-by-one or stack overflow error. If you're trying to track down a double-free bug in a 700 long single-source file application, it won't be as 'trivial.' If you have a 800 long source file with 2 classes in it and you don't know how to track classes through assembly code how are you going to pick which class it's in? Sure, it still won't be easy or trivial with a multiple-source file program or one with short functions, but honestly, at least you can *gain* something from going the multi-source route. You've never debugged critical or esoteric bugs, have you? A bug isn't just a malfunction, you know. Let's list some things that are *not* super-trivial to debug (AKA things you probably have never encountered): Double-free's, memory/handle leaks, bad GUIs, poor performance, not meeting expectations, string issues, and in many cases things you use in programs every single day, such as a for loop, can hide a bug that can remain hidden for years. Trust me, not everything can be solved with a copy of Windbg or Ollydbg. Some things require more.

__________________
os: mac os 10.5.4
revision control: git
editor: emacs

site