What tools do programmers make to help game designers, artist and programmers?

Level Designers/Editors are one tool/group of tools that programmers make.

Level Designers/Editors are one tool/group of tools that programmers make.

Is the editor suppose to do this:

1) First make the map in the editor

2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.

3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map

into their program.

Level Designers/Editors are one tool/group of tools that programmers make.

Is the editor suppose to do this:

1) First make the map in the editor

2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.

3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map

into their program.

Almost certainly not. The editor would in all likelihood spit out a file (or set of files). The game would read the generated files and perform actions depending on what was in files.

Is the editor suppose to do this:

1) First make the map in the editor

2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.

3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map

into their program.

1. That is one option. Another is to have an in-game editor.

2. The editor should create a readable format that the game would read to create and use the map in-game.

3. The programmer should not have to export the Java code of the map because it should already be in a usable format. See what nobodynews said:

Almost certainly not. The editor would in all likelihood spit out a file (or set of files). The game would read the generated files and perform actions depending on what was in files.

Level Designers/Editors are one tool/group of tools that programmers make.

Is the editor suppose to do this:

1) First make the map in the editor

2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.

3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map

into their program.

Almost certainly not. The editor would in all likelihood spit out a file (or set of files). The game would read the generated files and perform actions depending on what was in files.

can the editor generate a file that contains a set of integers that represent game object data. Each integer corresponds with a different game objects like: stone, grass, trees, flowers, wood. Is that the prefer way for what the editor should perform?

can the editor generate a file that contains a set of integers that represent game object data. Each integer corresponds with a different game objects like: stone, grass, trees, flowers, wood. Is that the prefer way for what the editor should perform?

Sure it can. For a 2D game, for instance, if you have a 2D grid you are working with, you can store what type of terrain is in that square by using an integer as you mentioned. When you load the map in an editor or in the game, it converts the integer to what should be there.

I think you may want to actually create a game or two before you even bother with trying to crate toolsets, or at least get onto a team with game developers that are looking for a guy that'll handle toolsets. Doesn't have to be a big game, just something to get your feet wet so that you know what all goes on inside a functional game from first hand experience.

Perhaps this will help you understand the sort of things we do for our data files. The following is a rough XML spec for a dungeon format. The final form changed a lot, but this is the one we used in our earliest working version of the dungeons for the game it was used in.

<Dungeon name="Dungeon Name">

	<!-- Total size of the dungeon -->
	<Size>
		<Width></Width>
		<Height></Height>
	</Size>
	
	<!-- These would likely be in multiples with a From location as well if there are multiple entrances for a given dungeon -->
	<PlayerStart>
		<Room>Room Name</Room>
		<Location>
			<X></X>
			<Y></Y>
		</Location>
	</PlayerStart>
	
	<!-- Textures will be listed up front to avoid stuttering due to late loading -->
	<Texture name="Name used to refer to texture">
		<Asset>File path relative to the game folder</Asset>
		<!-- Optional global tint applied to the texture -->
		<Tint>
			<Red></Red>
			<Green></Green>
			<Blue></Blue>
		</Tint>
		<!-- Optional pixel shader can be used to transform the appearance of a texture to add some spice -->
		<PixelShader asset="Path relative to the game folder">
			<Parameter name="">Value goes here</Parameter>
		</PixelShader>
	</Texture>
	
	<!-- Post Process effects run over the entire screen (minus the GUI) after the scene has been drawn -->
	<!-- For example: in a cold environment we may want to lower the color temperature -->
	<PostProcessEffect asset="Path relative to the game folder">
		<Parameter name=""></Parameter>
	</PostProcessEffect>
	
	<!-- Rooms are indivual scenes within the dungeon connected to at least one other room -->
	<Room name="Room Name">
	
		<!-- Connections establish where each connector to another room or exit is located within the room -->
		<Connection destination="Room Name OR EXIT_TO_WORLD">
			<Area>
				<X></X>
				<Y></Y>
				<Width></Width>
				<Height></Height>
			</Area>
			<!-- Optional graphic to display for this connection -->
			<Graphic>
				<Texture>Texture Name</Texture>
				<!-- Optional source rectangle, if not specified entire texture is used -->
				<Source>
					<X></X>
					<Y></Y>
					<Width></Width>
					<Height></Height>
				</Source>
			</Graphic>
		</Connection>
		
		<!-- NPCs are computer controlled characters that behave according to the AI used for them -->
		<NPC name="Name of NPC">
			<Location>
				<X></X>
				<Y></Y>
			</Location>
			<!-- Optional floating point scale to change size of NPC -->
			<Scale>
				<X></X>
				<Y></Y>
			</Scale>
			<!-- Optional tint -->
			<Tint>
				<Red></Red>
				<Green></Green>
				<Blue></Blue>
			</Tint>
			<Animation>Name of animation</Animation>
			<AI>Optional name or type of AI to employ for this NPC</AI>
		</NPC>
		
		<!-- Graphics are loosely placed to form the look of the dungeon -->
		<Graphic>
			<Texture>Texture Name</Texture>
			<!-- Location and Size within the level to place the graphic -->
			<Destination>
				<X></X>
				<Y></Y>
				<Width></Width>
				<Height></Height>
			</Destination>
			<!-- Layers are to simulate depth, only graphics on the same layer should collide with player -->
			<Layer></Layer>
			<!-- Optional source rectangle, if not specified entire texture is used -->
			<Source>
				<X></X>
				<Y></Y>
				<Width></Width>
				<Height></Height>
			</Source>
			<!-- Optional tint -->
			<Tint>
				<Red></Red>
				<Green></Green>
				<Blue></Blue>
			</Tint>
		</Graphic>
	</Room>
	
</Dungeon>

Well I worked on an arcade shooter clone written in Java for 1 month doing things like adding projectile collision detection of the monsters, adding monsters and a life bar. I guess I should learn XML.

Level Designers/Editors are one tool/group of tools that programmers make.

Is the editor suppose to do this:

1) First make the map in the editor

2) Once map is done, program will generate a code in Java based on what the map looked like in the editor.

3) Programmer can export the Java code of the map created by the artist so programmer can add the code of the map

into their program.

Almost certainly not. The editor would in all likelihood spit out a file (or set of files). The game would read the generated files and perform actions depending on what was in files.

can the editor generate a file that contains a set of integers that represent game object data. Each integer corresponds with a different game objects like: stone, grass, trees, flowers, wood. Is that the prefer way for what the editor should perform?

In the end, your tool will be tailored to your engine and to the purpose you are trying to accomplish. If your game engine has a mechanism to differentiate game objects by some sort of ids, then yes, perhaps storing objects as ids in your input file would be the way to go. Honestly it all depends on the situation, what you are trying to do, and how your game does so.

In my experience, a tool such as a scene or level editor would probably use the same "engine" as the game. Its job is to make the creation of entities more convenient than hard coding everything. By having the tool use the actual engine, you get to see how things will pan out in the actual game as you are creating your level. The only difference with the actual game is that the tool spits out a file and your game reads that file as its input. Hence, the editor would need a way to save things out in a convenient format, and your game would need to parse that file to reproduce the entities. The tool exports, and the game imports.

Another example.... Artists usually create content in commercial applications such as Photoshop (for textures) and 3ds max (for modeling). The problem is that rendering your asset in 3ds max will not look the same as in your game. An artist has no idea what his/her creation will look like until the work that was created can be rendered by the game's rendering pipeline. A tool, using the game rendering pipeline, can be created for artists to check and tweak their creation. Within the tool, lighting settings can be modified. The textures and materials could be tweaked. Things will be modified until the artist is content with the results, at which point things can be exported into a format that the actual game will know about and can import in.

Similar tools can be created to facilitate content creations related to other fields... say sound for example. A sound engineer will work on creating sound in a software he/she is familiar with. But in the end, the results must be checked with the actual game's sound engine. A tool could be created for that as well within which sound settings could be modified until the sound engineer is satisfied and the results match what he invisioned in the first place.

What I'm trying to get at is that there is no real general ideal when it comes to tool creation. You must first analyze workflow problems within your project, see how you can facilitate it, and create a tool tailored for it.