I want to make Tools where to start?
Author
I want to make tools, or a collection of tools to ease game development.
Where is the best place to start in articles to read, programs to look at, etc..
2d/3d game I'm not picky I just want to make some to get some under my belt for
my portfolio.
Thanks :)
What's your level of knowledge and experience right now? How well can you program? Have you written any games so far?
Author
Quote:Original post by oler1s
What's your level of knowledge and experience right now? How well can you program? Have you written any games so far?
I'm a .Net contract programmer in my area where I live. I have put together Enterprise websites before in Silverlight 2.
2 years professional work as a C#, Java, VB programmer.
I have successfully made 2d arcades of Pong, Breakout, Space Invaders, Mario Clone, and my own arcade puzzle game ROM.
I would say if I was working for a game studios I would be a junior level/entry level programmer.
I just have never needed, nor seen why I would need to make tools for a game engine before, but I guess I haven't really worked on any real projects that have called on it before.
In professional game development, a toolchain usually consists of:
- 3D modeling app plugins (exporters, add-ins that let artists attach game-specific data to scenes, etc)
- Data editing. This might include a simplified editor to let people without Max/Maya licenses visually place objects in a level. It also might include defining enemy behaviors, scripts for levels or entities, a localization editor for internationalization, etc.
- Data processing (compile, build, whatever you want to call it). This converts all of the assets from the first two parts into something optimized to be loaded by the game. There are a lot of tricky and important parts here, mostly which relate to optimization - load times, data sizes, build times.
If you want to do this for a portfolio, you should think about your approach from a whole team's point of view:
- The artists won't know how to program and probably won't have compiler licenses (especially in the console world).
- The designers might know how to program, but they are probably not experts, so they probably need a simplified scripting system that doesn't let them shoot themselves in the foot like they could with a 'real' programming language.
- The programmers don't want to be tied up babysitting designers or artists if possible, so making the tools as robust and easy to use is a good thing.
- Nobody wants to wait 5 hours for the data to build. One of the biggest problems that I've seen is when a large amount of data is built even though only one value was changed in the source files.
- 3D modeling app plugins (exporters, add-ins that let artists attach game-specific data to scenes, etc)
- Data editing. This might include a simplified editor to let people without Max/Maya licenses visually place objects in a level. It also might include defining enemy behaviors, scripts for levels or entities, a localization editor for internationalization, etc.
- Data processing (compile, build, whatever you want to call it). This converts all of the assets from the first two parts into something optimized to be loaded by the game. There are a lot of tricky and important parts here, mostly which relate to optimization - load times, data sizes, build times.
If you want to do this for a portfolio, you should think about your approach from a whole team's point of view:
- The artists won't know how to program and probably won't have compiler licenses (especially in the console world).
- The designers might know how to program, but they are probably not experts, so they probably need a simplified scripting system that doesn't let them shoot themselves in the foot like they could with a 'real' programming language.
- The programmers don't want to be tied up babysitting designers or artists if possible, so making the tools as robust and easy to use is a good thing.
- Nobody wants to wait 5 hours for the data to build. One of the biggest problems that I've seen is when a large amount of data is built even though only one value was changed in the source files.
Quote:Original post by aleisterbukowski
I just have never needed, nor seen why I would need to make tools for a game engine before, but I guess I haven't really worked on any real projects that have called on it before.
I'm afraid to say without any experience any tools you write will, sadly, be crap. In the same way that you should write games not engines if you start with a goal of writing a tool first you've going to end up with something which doesn't actually solve any useful problems and isn't any good to anyone.
Your best bet would be to go back to one of your previous games and see where a tool could improve either the workflow or content creation. Since you've got a mario clone then a map/level editor for that would be a very good starting point.
Quote:Original post by aleisterbukowski
I want to make tools, or a collection of tools to ease game development.
Where is the best place to start in articles to read, programs to look at, etc..
Start by looking at where you would actually benefit from writing tools. Is there something in your development process that you find tedious? Do you need to do similar tasks repeatedly?
Writing tools costs time. So, the tools you write must pay back in some form. That can be by saving time (writing lists of files by hand takes a lot of time, letting a script crawl through the same folders is much faster), by being more robust (doing things manually can be error-prone, we tend to forget or overlook things sometimes), by making things easier (a visual level-editor makes it easier to create levels -> this also affects the final quality), and so on.
So, there are many situations where tools can be useful. Analyze your workflow and I'm sure you can come up with a few ideas. Don't write tools for the sake of it, write tools where you need them. This also makes it easier to determine their requirements, because they'll be applied to a real situation, rather than a hypothetical one.
I frequently write small Python scripts for myself and colleagues to automate certain processes. This saves time, prevents mistakes and keeps things synchronized. It also makes life easier for the artists, which means they can concentrate on what they're good at (creating art) rather than wrestling with tools and panicking programmers.
Also think about what you already have available. For example in your Mario-style platformer you will already have a tried and tested system for loading and displaying tilemaps or level designs. To create a level editor tool you could begin with that code and just create a user interface on top of it to allow interaction with the level objects. You might even be able to simply retain the whole game mechanics in the ditor, so you could switch between a 'sandbox' mode for design and 'play' mode for testing. If the tool is robust enough and doesn't rely on other tools in your workflow then you might even think about making it a feature of the game - users can design their own levels using the same tool. There's certainly a bit of work to be done in implementing this, but maybe less than it appears if you can reuse modules of your game code sensibly.
Quote:Writing tools costs time. So, the tools you write must pay back in some form.
Only bad tools cost more time to write than they save.
Quote:For example in your Mario-style platformer you will already have a tried and tested system for loading and displaying tilemaps or level designs. To create a level editor tool you could begin with that code and just create a user interface on top of it to allow interaction with the level objects.
I disagree. The object model needed for a good tool is dramatically different to the object model needed for fast efficient loading/rendering of the level data. Unless your language supports reflection (C#, VB etc), you really need to find a way to be able to provide it. So for example, if you're in C++, you'd really want code to look more like this:
class Attribute{public: string getName(); AttrType getType(); void set(bool); void set(int); void set(float}; // etc ... bool getBool(); int getInt(); float getFloat(); // etc ...};class BaseObj {public: virtual type getObjType(); virtual void isKindOf(Type type); int getNumAttrs() const; Attribute* getAttr(unsigned index); const Attribute* getAttr(unsigned index) const; void write(FILE*) const; void read(FILE*);protected: virtual void initAttrs(); void addBool(string name,bool def=0); void addInt(string name,int def=0); void addFloat(string name,float def=0); void addString(string name,string def="");private: std::vector<Attribute*> m_Attrs;};// and a quick example... class Car : public BaseObj {public: protected: virtual void initAttrs() { BaseObj::initAttrs(); addFloat("length",1.0f); addFloat("width",1.0f); addInt("horsepower",80); addString("make"); addString("model"); addBool("hasSunroof",false); }};Which is woefully in-efficient for games, but does make writing tools a lot easier. e.g.
void writeNodeToFile(BaseObj* obj,FILE* fp){ for(int n=0;n<obj->numAttrs();++i) { Attribute* attr = obj->getAttr(i); switch(attr->getType()) { case kBool: writeBool(fp,attr->getBool()); break; case kInt: writeInt(fp,attr->getInt()); break; case kFloat: writeFloat(fp,attr->getFloat()); break; } }}void displayNodeGUI(BaseObj* obj){ for(int n=0;n<obj->numAttrs();++i) { Attribute* attr = obj->getAttr(i); switch(attr->getType()) { case kBool: createBoolWidget(attr); break; case kInt: createIntWidget(attr); break; case kFloat: createFloatWidget(attr); break; } }}A simple menu item for 'export to game format' is normally always a better idea than basing tools around game code (because otherwise you're going to have a maintainence nightmare keeping the entire tool code up to date with the ever changing game code).
Quote:If you want to do this for a portfolio, you should think about your approach from a whole team's point of view:
Sorry, but i had to jump on this as a very good example on why tools end up being crap. I don't mean to cause offense, so don't take it that way... :)
So. You start thinking about writing tools for artists, and you've decided to think about what they might need. So you put yourself in their shoes, and you are able to deduce:
Quote:- The artists won't know how to program and probably won't have compiler licenses (especially in the console world).
If you sit there and think, "they don't have a compiler, what tool should i write for them?", you're really not going to get anywhere.
Always, always, always, talk to the target users for the tool before you plan anything. Make a list of things they want it to do. Get them to organise that list into highest priority first. You now know what needs to be done, and in which order. If you keep up the communication with the users throughout development, things will go very smoothly, and you'll have a really good tool.
Quote:- The designers might know how to program, but they are probably not experts, so they probably need a simplified scripting system that doesn't let them shoot themselves in the foot like they could with a 'real' programming language.
How do you know that they need a programming language? Did you ask them? If you turn up in 3 months time with a working scripting system (that they don't need), you've wasted a lot of time! (especially if it turns out they are all competent C++ programmers ;))
Quote:- The programmers don't want to be tied up babysitting designers or artists if possible, so making the tools as robust and easy to use is a good thing.
Artists in this industry are a vastly more technical than you seem to be giving them credit. In my 10 or so years as a tools programmer, I have never met a single artist who needs babysitting. Artists may end up pestering programmers, but that's almost always due to shoddy work on the part of the programmer. Making the tool robust is good, but making it easy to use is less important than making it fit into their workflow.
Quote:Your best bet would be to go back to one of your previous games and see where a tool could improve either the workflow or content creation. Since you've got a mario clone then a map/level editor for that would be a very good starting point.
Not so sure that's a good idea tbh. The OP wants portfolio pieces for, i assume anyway, a future career in the games industry. A good place to start with tools programming imho, is to actually learn how to model/animate/texture with Maya, Max or XSI. Most of the tools programming jobs in industry will require knowledge of one or more of those SDK's. You haven't got a hope in hell of writing a decent plug-in for those apps unless you actually know how to use them.
Other things I'd suggest for tools portfolios:
- Find someone, and write tools for them. Tools programming is about communication as much as anything.
- improve your coding style a lot. Keep it simple, keep it stupid, and document the hell out of it. Tools code often outlives game code, and therefore it does need to be a lot more maintainable.
- Pick a dcc package (max/maya etc), and try to make your tool's keyboard shortcuts, menu layouts etc consistent with that package. People who are new to your tool, will probably be able to use it without reading the manual (which they won't read anyway).
- read this book. html version available here
- If you implement undo/redo for your tool, you're in the top 0.01% of applicants for tools programming roles.
[Edited by - RobTheBloke on November 12, 2008 5:45:57 AM]
Quote:Original post by RobTheBlokeQuote:Writing tools costs time. So, the tools you write must pay back in some form.
Only bad tools cost more time to write than they save.
I guess I should've been more clear there. What I meant with that statement is that you should solve the right problems. Writing tools for the sake of it, without having actual problems to solve, is a waste of time. The tools might be pretty good but if there's no practical use for them in the given project, they're still a waste of time. And that's why I first suggested the OP to start looking for problems and inefficiencies in his workflow. Paying back is of course the essence of tools.
Quote:Always, always, always, talk to the target users for the tool before you plan anything. Make a list of things they want it to do. Get them to organise that list into highest priority first. You now know what needs to be done, and in which order. If you keep up the communication with the users throughout development, things will go very smoothly, and you'll have a really good tool.
Absolutely. I've had it a few times where I thought my ideas would work well for the artists, but they had a different workflow than I had in mind. I'm partially an artist too, but that didn't mean I knew precisely what they wanted and needed.
Interesting comments about the importance of communication btw. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
