Starting out in maxscript is easy, for programmers. Sometimes. Knowing 3d is obviously helpful, having an artist who knows about programming helps. But a hybrid, the technical artist, an artist that programs his own tools, but has enough skill to move forward with the programmers as code changes and adapts. Get learning.Some things to note : italics are programming terms. Bold is code examples, and other stuff should make sense automatically. The artist programmer, a beginning. Well lets start somewhere simple. There are some cool things you can do with max, literally, anything. Starting out can be difficult so im gonna explain piece by piece. One thing that you will use a lot of : VARIABLES. A variable stores things. Simple right? A sock drawer holds socks, a fridge holds refridgeratable (lol) objects. It makes sense that a variable has a type. There is text, numbers, and "objects","items","collections","maps". All these things are really easy to understand when its broken down. For example, a string holds text. Most strings in maxscript are referred to by string literals right? A string literal is just a bunch of words,numbers etc wrapped in double quotes. "a string" is a string where as, a string is most likely a syntax error. Variables are relatively easy to grasp. Variable = value. name = "fuzzy". location = "\models\textures". Thats all there is to it. Numbers, pretty much the same. number = 2. age = 21. ageplustwo = age + number. See what i did there? Adding variables works most of the time. Like, variable plus variable can work most times if the types are the same, or if they can work together. Like, filename = "texture".filecount = 1.newfilename = filename + filecount. The output should be along the lines of texture1. You can add to the file count, and adjust the name of the rendered texture using a plus 1 after saving to the texture1 file. If this is all confusing so far, go back and read it again lol. But the next part will have something my colleague asked for as an artist, when learning programming, Visual aid. No i lie, the next part is about the tools max gives us in max 9 (and other max versions) to edit, run and test scripts. The maxscript tools in max. There are a few things that are invaluable while testing and figuring out maxscript. There is, the documentation. Please, read the documentation when stuck. Its gibberish at times, its hard to understand but when you start seeing patterns at each interval you get stuck you learn faster.  The maxscript listener (F11 by default). This is where you can type test code and see things on the fly, test if your functions exist, ask max wtf it is doing and what not. This is also, really really helpful. The maxscript editor in version 9 sucks, fullstop. But its faster then having to keep running scripts from the utility or the menu. So running the editor and using some damn cool shortcuts. After this bunch there are some helpful shortcuts, but for now there is also, the maxscript debugger. Its not highlighted, because i dont use it much either at first. There are other cool things you can use but for now lets use these. Quick Reference Maxscript editor - Ctrl S - Save (yes, its important) Ctrl D - Fix the coloring of the text in the editor Ctrl E - "Evaluate" the code. This means it tests it, and then shows the errors in the listener or shows "OK". Maxscript Listener - Ctrl D - Clear All (so you can see wth its doing when it places things inbetween every other line) A very small start The documentation covers some very simple stuff which is nice. Im going to do the same as well, and im going to start out by usnig the maxscript listener too. Open the maxscript listener -> Welcome to MAXScript. Now that it is open and waiting we can start coding. Is it that simple to program in max? It can be. Visual aid, lets go! Max gives us functions to use. Not a very technical term, functions do a function. They can do many functions, and ask other functions to do stuff, and even give us results. This is a later concept but for now lets remember that we need a variable, and a function that gives us something. When i say, "hey make a box, and name it pancake", i can always later tell my friend about pancake's hair. Pancake is 2m tall! Ridiculous. This is what we are going to do. Storage = ask function to do something and give me a "handle" or name to reference the object im making, or item im using. "box = make a box for me","i want to make it blue", "box.color = blue". So max wants us to be all formal and use the maxscript language so lets make a box. From the documentation : "You can draw a box in MAXScript just by entering the box() command". I can see that if i type box() into the maxscript listener and hit enter, i can see a box created with default values. The box has options i can ask it to use from before its made, so i can say i want it to be 20 units high and 20 wide, 20  long. Again from the documentation : mybox = box length:20 width:20 height:20 Type that into the listener window (on a new line) and hit enter. Do it again with different sizes and see how easy it is to do certain things. note : programming refers to a "return" of a function.This simply means that max is handing me something back.If you want to use it you can, if not ignore it. The maxscript window shows some information, this is a return in the listener only and shows that the box now exists in the engine and in the code, as well as you should see a box in the viewport. Now we can set the properties of the box using its name that we filled up with , the box itself. mybox (the variable) contains the "returned" box, inside it. So i can say mybox's name should be "ArtCodeBox" instead of "box01". There are hordes of properties you will use later on , but for now we are changing its name. mybox.name = "ArtCodeBox" There, you will see the changes immediately in the window where the object name shows (by the toolbars, where the mesh wire color picker is). Concluding It seems horribly short and, rewheeling the invention. This may be true now but i want to start really slowly, and move into more advanced things later. Starting to understand programming is not the easiest thing when you are an artist. This is by no means a demeaning statement, as most programmers know nothing of art so play fair. There are tons of resources, tons of tutorials and of course, http://area.autodesk.com for a slick forums with fast responses, there is documentation and there is also, common sense. Learning comes from seeking knowledge, not complaining that the tool isnt robust enough. For a second installment, and the coming soon third part, we are going heavy into simple, fast paced programming for artists that speeds up everyday tasks. To all the artists :  Please suggest some ideas. I have some, my colleague has some, what annoying thing would you like to automate (small things for now)? Comments welcome, and of course ideas, suggestions, flames ( i can delete those, you see ). FuzzYspo0N/Sven

Using max for game development has been done time and time again. As an artist, using max is natural. As a programmer using max is powerful but hidden a lot of the time. Merging the artist and the programmer makes things simple and effective in game development. “The technical artist” is supposed to be the gap filler in this situation. In large game companies, multiple artists and multiple programmers bring a good turn around, but with the right tools the job gets easier, faster. Give an artist a functional tool and the programmer wont need to spend time a) explaining what code does, b) explaining why the tool cant perform certain tasks, and c) wasting time fixing small bugs over and over as the engine progresses. As a smaller company working together is vital. “The aspect of team comes in very handy”, is a thing of the past. The integration is crucial to making games games, and making games well. The artist, for example can flourish given the toolset he or she may require, leaving the programmer free to make the game play more game like. Keeping things tight as a team makes it fast and easy to update things. Keeping your head out of the clouds and keeping ahead of things can be difficult in the industry, but the first steps in the right direction give amazing amounts of progress, fast. This is where we have gotten to lately. An artist with a tool, that can be extended, should be given the tools he needs to make the game easier on everybody. Understanding that taking a few days to learn new things and taking a long time to figure things out comes naturally when programming, but the artist without the tool, can wait without the tool. The programmer taking 15 minutes out of the normal code to toy around with a new tool for the artists can greatly improve understanding on all levels. Once there is a familiriaty with the language, and or extension toolkits there can be massive improvements to everyones workflow . Below i outlined a couple of pointers for the two sides of the team, should it benefit you. Artist : 1) Be clear and concise. No programmer needs vague explanations and needs to figure out art jargon while programming. 2) Be reasonable. No programmer wants to spend 6 months making a tool for the game. Start small, and start simple. A toolkit is made up of many parts, massive toolkits are made from massive amounts of code. Start with automating repetive tasks. Things that will increase your workflow will slowly show you where you can grow. Show you where you can learn. 3) Be understanding. The programmer SHOULD dedicate time to you, and your workflow. In a small team this can make sense and can be easier, where as larger teams this requires perhaps dedicated technical artists but the concept remains. Give the programmer a clear, concise, simple tool addition description, and give the programmer time to work it out. Keeping in mind that the team is a team, you can do great things if you let them happen. 4) Be predictable. From the start keep things consistent. How you like things, make it clear. How you work through toolbars, make it clear. How you layout your shortcuts, make it clear. As you work further, there can be less interaction, and more working together. An understanding of who you are working with makes it easy to guess the next step. The next feature. “Working in the zone” makes it easy to program, knowing what can help and improve your artists workflow before asking, makes it faster to develop, faster to please the artist and easier to make games. Hope this helps, the next post regarding this subject will detail a few techniques in maxscript that will definately help in game development, as well as in making custom formats, or using existing formats to exploit the engine you are using. We are using torque in some cases and we use XNA for others, writing tools for Max, XSI, and other 3d apps doesnt take too long, and can make the game engine itself unbelievably easy to control content, to control art assets, to control scripting engines, to automate importing exporting, almost anything can be achieved in a short time.