🔒 Locked
Tools Programmers Underrated?
Advertisement
Original Post
My expierence is exactly the opposite. The new guy gets put on tools. Why? Coding tools isn''t fun. Most tools are badly documented and poorly written as they just need to get something done. But then, it''s decided that the tool needs to be expanded. Everyone who''s worked on the tool allready knows it''s crap, and doesn''t want to touch it. So, it gets foisted on the new guy.
Some places understand the use of a good tool. But unfortunately, a lot don''t understand that a good tool reduces development time potentially on multiple projects.
Some places understand the use of a good tool. But unfortunately, a lot don''t understand that a good tool reduces development time potentially on multiple projects.
Coding tools isn''t fun ?
Places I''ve worked at haven''t had tool writers. But tools are essential, so I would take the time to write my own. It''s a lot of fun when someone says "I wish there were a good way to extract the SQL from all this code", and I can tell them "give me half an hour; should be trivial to hack up a Perl script to do that".
I truly believe that an optimal team of 7-10 would have the most proficient coder being the technical lead, and the second most should be a "tool writer / guru" - the person you look to when you find you''re doing repetitive things, or you''re just stuck, or you just need another set of eyes.
Let me know if your company wants an experienced tool writer. I love that sort of thing. Creativity at its best. Search "marc wallace resume" on google. (apologies for the shameless self-plug)
Places I''ve worked at haven''t had tool writers. But tools are essential, so I would take the time to write my own. It''s a lot of fun when someone says "I wish there were a good way to extract the SQL from all this code", and I can tell them "give me half an hour; should be trivial to hack up a Perl script to do that".
I truly believe that an optimal team of 7-10 would have the most proficient coder being the technical lead, and the second most should be a "tool writer / guru" - the person you look to when you find you''re doing repetitive things, or you''re just stuck, or you just need another set of eyes.
Let me know if your company wants an experienced tool writer. I love that sort of thing. Creativity at its best. Search "marc wallace resume" on google. (apologies for the shameless self-plug)
It depends on the tool they were writing. If they were developing tools for windows, they would have to learn Win32 (or MFC, buts that debatable). If it were a level editor or world builder, they would have to know OpenGL or DirectX. If it were something else (I don''t know), they might have to know MySQL or other database interfaces. I''m writing an engine, and a buddy of mine is programming the tools, he''s had to learn Win32 (he hates MFC), and OpenGL. I can usually tutor him on all the graphics theory he has to know, but in a big company, you''d have to know it already.
I hope that makes any sense and helps ya,
-------------------
Realm Games Company
I hope that makes any sense and helps ya,
-------------------
Realm Games Company
As others have stated, a lot really does depend on the company.
I was a tools programmer for a year and a half. The tools team wasn''t made up of the new guys; in fact, everyone on the tools team had quite a bit of experience and a broad range of knowledge. The things I did required a good knowledge of Win32, MFC, C++, and the Maya and Max plugin APIs. It also required good software engineering and design skills, since many of the tools I created replaced existing tools which had been hacked together and, over time, proved cumbersome to use and difficult to alter as needs changed. And yeah, math was pretty important too - my first tool created inverse kinematic-based animation curves from motion capture samples.
That said, it''s true that most companies don''t fully appreciate the value of good tools programmers, mainly because they don''t directly generate revenue. However, some companies at least are beginning to realize that a talented, full-time tools programmer (or even a team of them, for larger companies) can greatly enhance the productivity of artists and programmers, and save them millions over the long run.
I was a tools programmer for a year and a half. The tools team wasn''t made up of the new guys; in fact, everyone on the tools team had quite a bit of experience and a broad range of knowledge. The things I did required a good knowledge of Win32, MFC, C++, and the Maya and Max plugin APIs. It also required good software engineering and design skills, since many of the tools I created replaced existing tools which had been hacked together and, over time, proved cumbersome to use and difficult to alter as needs changed. And yeah, math was pretty important too - my first tool created inverse kinematic-based animation curves from motion capture samples.
That said, it''s true that most companies don''t fully appreciate the value of good tools programmers, mainly because they don''t directly generate revenue. However, some companies at least are beginning to realize that a talented, full-time tools programmer (or even a team of them, for larger companies) can greatly enhance the productivity of artists and programmers, and save them millions over the long run.
I dunno about c# (never used it, but I would guess its alright). DirectX or OpenGL would be fine (i prefer openGL). The math level should be pretty high, just look at some of the other game editors out there, whoever wrote those would have had to have been pretty versed in 3d math.
-------------------
Realm Games Company
-------------------
Realm Games Company
One place you can get into tools development without math skills is in sound or texture pipelines. I''ve worked on a number of very complex audio tools that required me to have a lot of experience in C++, STL, MFC and human-interface usability. Of all the people in a game team it is often sound designers who have the least amount of technical knowledge. Making a tool that lets them put sound in the game without a lot of interaction with programmers is a tough problem. I focuses first on usibility by the artsits, second on maintainability and robustness of the code base, third on feature set requirements, fourth on extensibility. Lastly I worked on speed and optimizations as I find they often confuse a toolset''s code base making it ultimately trashed instead of expanded.
Topic Locked
This topic has been locked by a moderator. New replies are not allowed.
Sign in to reply to this topic.
Advertisement