Custom Map Makers

If you could, what kind of a game would you make.

fps, kinda like urban terror..

Fast Placed, with a proper "Jump Mode" but perhaps some jump related functions would only be available in the Jump Mode itself, like the 3 walljumps feature.
In fragging mode you'd only be able to do one, but this is just a wild thought, i don't know if it'd work.

And of course, It'd have to use a good engine, that doesn't make you lag as much as the idtech engine. I want some with extremelly beautiful graphics like the ones obtained by hte critek engine

FPS of course I'd like something with movement capabilities a bit like parkour. Maybe mobility variations in class vs protection/firepower (light/med/heavy). And work in cyberpunk hacking... so the hacker classes could open/close doors and thus routes, interfere with enemy vision/hearing, along those lines. But they would be vulnerable physically while doing it.

Yeah a great FPS with a mix of parkour movement and cyberpunk. Something like that lol....

I'll just dump some thoughts about making games in here~
This is mostly a collection of things I've picked up or learned myself in the past 2 or 3 years while working on various games.

This isn't supposed to discourage anyone, it's just a collection of negative things and stuff to watch out for.
It mostly applies to large-scale projects. If you're doing a one-week game jam, screw planning and a team and just DO IT.

I'm also not saying this is how you "make games". This is merely a guideline of things I found to work well.

First up: Making games isn't all fun and games.
While I personally have a lot of fun creating games in general, I can think of hundreds of incredible frustrating and annoying memories right now. This ranges from simply being stupid yourself (I'm a programmer, I'm stupid all the time) over bugs down in the engine that are extremely hard to track down to simply not being able to import a simple model.
You WILL encounter THOUSANDS of issues like that when making a game - and let me tell you, 95% of the time it is your own fault. (unless you chose the wrong engine, more about that later)
What I'm trying to say is, you need to be strong and capable of dealing with problems all the time. Making a game is hardcore problem solving - and I'm not talking about tracking down gameplay bugs/glitches, those are actually fun most of the time.
You have to know everything that is to know about your engine and your game to fix issues. (Of course this mostly applies to programmers, but the more experienced artists are the better the whole project is off)

Keep in mind such a game will keep you occupied for months, if not years. Be ready to dedicate all your free time to it.

You also need a team.
I'm not saying you can't make a game alone (I've done so multiple times), but there's a big issues with that.
Unless you're a programming, modelling, texturing, level designer, mapper, graphical artist and animation genius without a job it will take forever - you can of course just stop and release, but quality will suffer.
Splitting all these jobs into multiple peoples is obviously taking away the workload from you and also increasing speed as people can work at the same time.

Finding people "wanting to make a game" isn't the biggest problem. There's literally thousands of people with ideas and skill our there (finding 3D artists can be hard though), but you need to be able to work as a team. Everyone needs to feel comfortable in the team. Some team members might just stop working for whatever reason - remove them from the team. They will annoy all other members and slow down the whole project (Ideally a member would leave by herself, but that might not happen too often - also, ask for reasons if it happens. You might be overlooking major issues in your team).

Spend a lot of time to find good programmers. You don't want a 14 year old kid that started learning Python 3 weeks ago being your "game programmer".
Ideally you want people with experience in multiple programming languages
Newbie artists aren't *that* much of a problem actually - at least they will produce things you can temporarily put in the game. Replacing assets later on isn't a big deal. However, if the design (bad code can be improved) of your game logic is flawed, you're in deep shit for two reasons.
- You can't maintain the code. This means fixing bugs will become a huge pain, if not impossible. Same for new features.
- You can't get a new programmer on the team since you're most likely missing documentation/tests/examples and the design pisses him off anyway.
Software design is a hell of a job. The code provides your floor to build on - if the floor can't even hold a single man, how can it hold a whole building?

If artists drop out of your team you're still left with their assets (most of the time) - if your programmer leaves, you're left with cryptic code. Finding a new programmer that will decipher it and build upon it is extremely hard. Don't lose your programmer(s).

If your team breaks apart the failure of the whole project is almost guaranteed (unless you have enough motivation and can gather a new one).

To maintain motivation: Take breaks. Stop working on the game for a week or two. In the end development will be faster. (Make sure your team knows you're simply taking a break and haven't stopped.)

Planning...
Create the dreaded design document. I have avoided writing one for Rain for years... back in April(?) I finally sat down and started writing.
I can't stress how much this helped the whole project. It gives you very exact goals and the whole team instantly knows what needs to be done.
Of course, don't write the design doc alone - it must be a collaborative effort of the whole team.
(I recommend setting up a Wiki for that - we're running one at Hazewood and it makes everything a lot easier)

Also set clear goals that you can actually reach. Shooting for the stars is a very common mistake, avoid it.

To actually get going on a game you'll need an engine. Choosing the right one for your game is crucial. (I've switched engines twice with Rain. NOT PRETTY. Don't do it.)
Of course, you can find yourself a programmer and write everything from scratch. DON'T DO THAT. You're making a GAME, not an ENGINE.
Yes, your own custom engine will offer you tons of flexiblity and be perfect for your game, but there's huges downsides to consider.
- It will take A LOT of time
- You WILL have THOUSANDS of bugs
- You have to wait for programmer(s) to implement every single feature
Having the hassle of basic graphics, sounds, input and file loading taken away from you will speed up development by far. Your programmers can now actually spend time working on the actual game.
There's a lot of engines out there, but don't pick just the one with the longest list of features/most shiniest one. People like to go "Unreal Engine 3 is awzum!!!11", only to have their programmers drop out 2 weeks later because they're completely fed up with Unreal script (can't blame them ).
Make sure your team is either experienced on that engine or you're providing a custom toolchain your team learns/already knows.

To sum it up, one last thing. Love your game. Create a game you would love to play for the rest of your life. Make it the best game ever.

Just out of interest Rylius, which engine would you choose if you could choose any?

Depends on the game.
I like to use Slick 2D for (obviously) 2D games - easy to use and won't get in your way, physics library binding exists, various GUI systems can be integrated.
You can pretty much use anything for 2D games since you have a lot less to worry about and performance isn't a huge problem either.

Stuff looks completely different in 3D.

Is the game going to be open source? Free? Commercial? What founds do you have available?
Ideally you want an engine that is licensed under (new) BSD or MIT, neither of these licenses will bite you in the ass whatever you do.

What tools are your artists going to use? 3DS Max exports to every format you could imagine, no restrictions here. Blender? Make sure to settle on good file formats.

Do you need networking? If yes, do you need competitive networking (ie, FPS)?
Competitive networking won't be provided by any engine, you'll need to write it yourself. Make sure the engine lets you do that (BSD/MIT always do).
How many players are you aiming for?

Big/open maps or close quarters?

Target poly counts of a typical scene?

Target computers?

How much do you want to mess with the graphics? Closed source engines rarely give you deep access.

Do you need a scripting engine?


These are all factors you need to consider. If you answered "yes" to a lot of them, go for something BSD/MIT, this will be the only choice to properly implement the features.
If you want huge maps and crazy amount of details, go for CryEngine - note you can't sell the game unless you pay tons of money in that case.
Modding is also an option - if you want to have a fast FPS with wacky weapons, go make a Quake 3 mod.

There is no engine that fits all - carefully consider what suits your game best.
Ideally you want to have made at least one test game on each considered engine before deciding to use it. Work with the engine for a week or two, that will give you a rough overview of what you're in for.

How do you feel about a heavily modified directx open source idtech2 engine.

Depends on the game.

My personal opinion doesn't matter.

If it didn't matter, it wouldn't be requested.

Aye, if you really wanna know.

In general I strongly dislike DirectX (as any Linux user), but if the other features of the engine are perfect for your game, go for it.
id Tech 2 itself is an extremely old engine - something I can't suggest hopping on either. Unless it has been modified heavily you'll have a hard time getting things done.
The code was done in some QuakeC stuff iirc, something that was great at that time but will definitely get in your way today.
The toolchain (maps and models) would probably be worse than the UrT one (and that one sucks big time already), so not much fun without heavy modifications here either.
You got a specific engine in mind (like DarkPlaces)?

That's the stuff you need to care about regardless what game you're making (unless you want big/open maps, a MMORPG or weird stuff like that).

Edit: To sum it up: It depends on the game.