   Creating game tools
  I was just wondering what toold people use to create their games. Right now I am makeing my own level desighner tool to make all my custome 2D maps so I dont have to write them out by hand. then all the levels can be loaded by my 2d engine automaticly.So what tools to other people make or buy to make thier games?   
  Personally, I'm a geek through and through. If I need something done, nine times out of ten I'll write my own tool for it. I feel more comfortable using code that I wrote because if it goes wrong I know what needs to be fixed and I don't have to jump through hoops setting up my environment and linking everything then digging through code I'm unfamiliar with trying to find the bug. Not to mention it's much easier to extend my own code.My current toolset is an editor along the lines of UnrealED. A level editor with a built-in GLSL IDE, texture file converter, mesh file converter and so on. The only outside tool I use is Milkshape 3D for models and MadTracker 2 for music.   ;  We usually just throw it together using the best tool we know about for it.  If you know a language that can get it out quickly, use it.Use Python, Perl, Tcl/Tk, C# or Scheme or whatever you want.  If you think a particular language can get the task done quickly, use it.  If you think it will take a certain amount of time to make the tool, you should consider the cost (in time and money) of making it vs the cost of buying a tool or having somebody else make it for you.  We are in the business of making games.  We are not in the business of making tools.  If we need a tool for something, spend the resources necessary to get the job done effectively, but don't agonize over it.   ;  The thing you need to keep in mind is the complexity of the editor.On virtually every game I've worked on I've spent most of my time on the editor. In fact the only games I ever finished were the ones without an editor.My current main project is an editor for creating visual novels. I wanted to make my own visual novel and started work on an editor/writer, but then somewhere along the way I trashed the game and decided to release the editor to the public instead. It's very easy to spend a lot of time on your editors, which is fine as long as that was your intention. Otherwise you need to think of it as just a tool to solve a specific problem in your game's development.   ;  Heres the thing I am planning on using one engine for all my 2D games. So i figured instead of writing out all the levels and game info in a text file by hand I would make an editor so I could do it visuely. i figured any one who made games with many levels made editors for their levels.Here is what I got.;  For really simple games, an in-game editor might not be a bad idea.  While playing a level, have a special console command or key combination that pops up a simple UI and lets you edit the map and save out the data again.   ;  I think it's a better idea to host the game engine inside a proper window so that you can build a proper UI around it. Too many ingame editors are like: press the secret key to activate a function, or scroll the mouse wheel to cycle through game objects for placement.That kind of editor are okay in some cases, but doesn't scale very well for more ambitious games.   ;  It's questionable why so many seem to want to create their own editors.Something to consider is for example this. Try to use file formats that allow the use of existing tools. XML or CSV files, as an example. I would even say CSV is the better choice of those two for most purposes (in games).Also, are you sure you need an editor at all which displays the game world? You could have your game "hot" update the world. As in, make the game automatically detect changes to the data files, and make it re-load them automatically if a change is detected.If you do that, you can edit your simple file format outside the game with whatever tool (like, in a spreadsheet application), save, and the game you would have running at the same time would automatically notice you saved the data file, and it would re-load the changed file.Do this on a computer with two monitors. Edit the data on one and use the game on the other. Hey, even cooler, have two computers, one edits the data, one runs the game, but still the game detects if the data changes and re-loads it automatically.I will have to add that for example a map for a 2D game can be created very far from a simple image. You define colours that act as 'keys' as to what should be placed at that point of the map. You paint the image in your favourite image editing program. And make your game to go through the pixels of the image and place objects accordingly on the map. This is a very simple idea and can work very well for a 2D game but this idea is used in 3D games as well.I guess my point here is that you should seriously consider what is actually necessary in your project(s). Don't use your time into developing all sorts of editors if your game projects are small and are unlikely to ever reach (good quality) commercial status. There are enough editors already developed which can be used right now.   ;  Good points, reptor. Yeah, .csv files are pretty easy to work with (Excel/Calc) and easy to process (using a scripting language - though be aware of encoding!). Not really suitable all kinds of data though. But yeah, keep things simple. :)As for automatically refreshing content, I think that can backfire when you accidentally save a file you just messed up - and boom, there goes the game. I'd rather refresh manually, but I haven't tried automating this so I can't tell how that would work out. I assume you've done this before? How would you say it worked out? Pros/cons?Using bitmaps for levels is something I'm not too keen on. I did it once, processing a bitmap to turn it into a tilemap, where black pixels were solid walls and white pixels were floors. The tool picked the right transition tiles based on the surrounding tiles. It works, but directly modifying the bitmap itself didn't work for me: it looked so different from the actual level that I found it hard to make the connection. From a level-designers point of view it was rubbish. I need to see what I'm building, a close resemblance to what it'll look like in the game. In-game editors aren't that bad of an idea, really. :)Either way, with a high-level scripting language and a few libraries, it's pretty easy to write a simple, get-things-done editor. Or to write a conversion script to turn an existing editors output into something useful for your game. I made a free-form 2D level editor with layer support and collision-line functionality in a couple of days, using Python, Pygame, pgu and pywin32. Still needs some tweaking, but I can already build levels (e.g. the visual and physical aspects) with it. Most time was actually spent on research and experimentation.@Scarabus2: true, such editors don't scale well, but that's ok if the game doesn't scale well either. ;)   ;  Captain P: Never work on your precious game without having it under source control! Messing up a file should never be something to worry about.   