3D tile engine... any pitfalls?

Long story short, I'm working on a shmup engine that'll be entirely done in 3D (gameplay will of course be 2D -- think Einhander), and I know enough to make the game, but not enough to work on a cross-platform world editor of decent quality (I'm not experienced enough in GUI-specific things at the moment, I just never really touched the subject).

I'm thinking of having levels made in a way that you can edit them in a text format, constructed of "tiles" that are .MD2 models of widths that are multiples of 64 or something like that.  A sample level definition file might look something like:

activecolumn 5    ; column where action occurs (in this hypothetical example, all the road tiles are in this column), every other column is foreground and background

skybox images/storm.tga
music audio/level3.ogg

tiledef X [emptytile]
tiledef 0 tiles/road1.md2   ; 64x64
tiledef 1 tiles/road2.md2   ; 64x64
tiledef 2 tiles/terrain.md2 ; 128x128
tiledef 3 tiles/factory.md2 ; 128x128
tiledef 4 tiles/foreground1.md2  ; 512x128

mapdef
2 X 2 X 1 4 X
X X X X 1 X X
2 X 2 X 1 X X
X X X X 0 X X
2 X 2 X 0 X X
X X X X 0 X X
3 X 2 X 0 X X
X X X X 1 X X
end

...

From a programming standpoint this can save time on learning GUI programming just to make a world editor (and there's other things about custom level editors that I see complications  from, such as if I change something in a custom-made file format... I've self-imposed an artificial deadline on this project to get it done before December).  From a design standpoint, however, this can potentially make it a pain in the ass to model tiles in such a way that their geometry and textures would look seamless when placed next to each other in the game.  Perhaps I can write a Python script in Blender that can let me visualize tiles next to each other as I work on them, without affecting the ones I don't want to change?

Also I don't think modeling the whole level in Blender would work, because I don't know any free file formats that I could use, along with other technical concerns I have with limitations on textures (also I cannot model the entire level and export it as one big .MD2 file -- the format has a limitation of 4096 triangles per model).

oh shit!

I just found out GTKRadiant was GPL'd back in January.

Does this mean that I can use GTKRadiant for my game (I don't mind having to figure out the .BSP format, that's the kind of the thing I'm good at) and, if I decide to go commercial with my game (highly, highly unlikely, but I always consider these possibilities) there won't be any licensing issues with a SWAT team of John Carmack lawyers busting down my door with papers?

Because I think prohibiting someone from using a GPL'd program for commercial use would be a GPL violation, right?

Yeah fuck this tile shit... .BSP level format for the win!  Even if it isn't appropriate for shmups as much as it is for FPSes, it's still a solid, dependable, and very familiar format.

why work on your own engine when there are mature ones freely available? http://www.devmaster.net/engines/

>>3

Primarily because my resume looks like shit with a sub-3.0 GPA, no extracurricular activities or campus club memberships, no references because all my professors hated me because I avoided homework, and no prior employment record whatsoever, so I want to make something substantial that's a at least slightly "show-off"-y so I can at least have a modicum of a chance at getting interviews, if not actual jobs.

If I don't make an actual game, the least I can do is make an engine that other people can build games from.  I have the education and know-how as far as algorithms, optimizations, and fundamental mathematical theory of calculus and linear algebra is concerned, but I tend to be pokey because I obsess over every detail.

The sciencey shit doesn't scare me, but implementation-level things get on my nerves.  I'm what job interviewers refer to as "smart and useless", and I want to get myself out of that category.  I want to look the interviewer in the eye and say, "yes, I can and have written a game engine."

>>4
lol broke. Stop thinking like some sheltered nerd programmer and think in terms of real world software development. Get some people skills along the way too.

>>4

How do I becomed SEO?

>>5
People skills are boring; people are stupid so I don't like dealing with them.

>>1
Want a better idea altogether? Write a series of level generators (like Nethack or Diablo). Have a town generator, a dungeon generator, a cavern generator... Then the level files just define a series of options on your random generator. For static places like towns, have it generate a bunch of towns, then pick the one you like and fix the random seed in the level file. This way you'll never need a level editor at all.

Oh wait, you don't care how easy it is or how well it works; you just want it to look fancy for job interviews. Well have fun with that.

>>8

OP here (>>7 was an impostor... although I agree lol).  Level generators, already made one when I worked on my roguelike before I put it on hold.  You could specify 3 kinds of environments: caves, palaces, and forests, and I had more "flavors" in mind.  Cave  generator would make dungeons similar to those seen in the original Final Fantasy games (think that dungeon in Final Fantasy 4 that ended with that sapient wall that tried to crush your party).  Forest generator was easy enough, even with occasionally making small rivers and streams for variation.  Palace generator made passable layouts about 50% of the time, and would even auto-space generated things like pillars and things supposed to be decorations, and randomly make symmetrical rooms since palaces tend to have those.

But even a below-average roguelike takes much longer to develop than an above-average space shooter, so I'm opting to cut my teeth on a space shooter first.  If I want to work with computer graphics systems, it's also a better start than a roguelike.

If you want to work with computer graphics systems, you should get to work on some research.

>>9
Wow, that's a pretty shitty palace generator if it failed that often. A dungeon generator should make passable layouts no less than 100% of the time.

Anyway, yes, a space shooter is probably the easiest 3D game to make (in terms of content needed) because the only animation needed is moving objects around and particle effects; it can be done entirely with static meshes. But I don't think it would be very impressive for a job interview.

Wow, programming for resume material?

That's sad -- you aren't going to get very far :)

>>11
I present you Palace Generator 2.0:

void *PalaceGenerator2(void *args) {
    void *ret;
    do {
        ret = PalaceGenerator1(args);
    } while (!PG_Passable(ret));
}

>>11

Yeah it's probably because it generated palaces out of the same kind of "additive carving" approach (for lack of a more accurate term) that my forest and cave generators did.  In retrospect, after reading how Alphaman generated its "science laboratory" dungeons, something recursive may have been more successful.

>>12

Well I'm open to more suggestions, because at this point, making something and actually finishing it to "prove" myself is the only thing I can think of to prevent myself from being at least somewhat more hireable than The Dude from The Big Lebowski.  D:

>>14
If you are looking for work on games, you probably should specialize.  Usually games involve a team of artists, programmers making tools for the artists to use, programmers working on the game engine, and programmers working on graphics.  Pick one that you think you have the most experience in.  Also, the programmers that work on the engine rarely code it from scratch.  Most often they are just trying to piece together scene graphs and stuff that have been licensed from other companies, and milk performance out of all of that.

>>1
Look, I LOVE the commandline, and I'm normally the first to shoot down uses for GUIs and what not, but YOU are a CRACKHEAD.

MAKE AN EDITOR, how is that MORE DIFFICULT than the engine?

>>14
I'm assuming you're the same person as >>1 and >>9.
What do you really want to do? Create a game? If that is your goal, then use other people's solutions and don't reinvent the wheel. You don't need to write your own engine from scratch. You don't need to worry about stuff such as scene management, lighting techniques or other graphical effects, collision detection or 3d model formats because they are all problems that have been solved.
There are open source solutions around so USE THEM. If they are inadequate for what your game vision is, then what is to stop you from improving open source engines? If you release your improvements to the public, then everybody benefits.

Here is a list of open source engines that I have played with. I've tried a number of non open source engines but I wouldn't recommend them because you aren't able to improve them or learn from them. Spend time doing tech demos for all of them then choose one to run your game.

http://www.crystalspace3d.org
http://irrlicht.sourceforge.net/
http://www.delta3d.org/
http://www.ogre3d.org - this a graphics engine rather than a 3d game engine/sdk
http://www.cubeengine.com/ - this is very interesting
http://sauerbraten.org/ - redesign of the cube engine.

I AM AN EXPERT PROGRAMMER

beware the army of 12 year old autistics

>>17
Irrlicht is really neat. I'm using it to create a level editor.

>>17
Do you know any that use OpenGL ES?

>>22
Oh wait, I'm 4 years late. Shit.

You'd have to write things in the terminal so the blocks would line up.

Enjoy your AIDS AND FAIL, /prog/

Enjoy your AIDS AND FAIL, /prog/