I'm thinking real hard about paying another artist and sound guy to develop assets for my game. I'm still in the middle of putting together the engine for the game and am wondering how to go about allowing others to decide how things will look and react visually.

Hardcoded, I have an object that will go through a serious of states and react to specific events. These events and states are setup so they can be scripted as to when they will happen, and how they will happen. But the graphical reactions kinda have me stumped. These are the ways I've been thinking about but I'm not sure if they would be comfortable for an outside artist to work with.

1: I set things up so when an event happens, it calls a specific animation if it exist. Or it sets off a specific particle emitter if it exist. or specific sound and so forth. Basically the engine would be set up to loaded specific assets if they are available, and if not it just won't use them. This suits me just fine as the programmer, but leaves very little room for the artist to do what they do.

2: The other idea, which means a bit more work would be to define a set of events that could happen. Create a simple scripting language, maybe using lua or something else, and set of reactions... ie PlayAnimation, or UseParticleEmitter. And try to let the artist set what happens when an event happens.

I guess I just have this view of how everything should work, but I've never done fancy graphics either, so I don't know how flexible things need to be. How would it typically be done?

1: I set things up so when an event happens, it calls a specific animation if it exist. Or it sets off a specific particle emitter if it exist. or specific sound and so forth. Basically the engine would be set up to loaded specific assets if they are available, and if not it just won't use them. This suits me just fine as the programmer, but leaves very little room for the artist to do what they do.

If by artist you mean a guy who will model/draw the character and make the animations you tell him to do (ie: jump, run, idle) I don't see any problem there. After all you're paying the guy to make what you ask him.

I'm telling this because I also think that at some point I might need an artist and very possibly I'll have to pay one to get something decent. Until that moment I'm going to make programmer art myself so by the time I hire the artist I'll know *exactly* what I need and I'll have at least a clue of how many hours it would take to make the content (and therefor have a clue of how much to pay).

I plan to pay him/her first for concept art to see if he/her get the idea of the look I'd like the game to have (I'm hoping he/her can come up with something better though) and then explain how many characters/decorates I need and how many animations, what kind of animations and approximately how long they should be each one. Given those parameters they are free to do as they please as long as I can afford it

Caution advised. I've been there and you might be very sorry.
Have you read the "write games not engines" articles? I believe some are a bit over simplicistic.
Of course we need to get the job done, we want to maximize reuse as well.

Try to think at the final product and what you need to make it work. I think a very good way of doing things is to have stubs. You want to be as-data driven as possible, but not so much to not get short or mid-term benefit. If a feature does not pay back in mid term, it's probably not good to add it.
Also check your design. Perhaps the mesh does not really have to be so much flexibility.

Can you re-phrase your examples in the real world?
Caution: if you cannot, then you're probably going too far with reuse - perhaps it will be good long-term, but you'll take some risk (depending on how skilled you are). Try to have a balance between short-term and long-term. Perhaps you'll have to restrict to a subset of the features you want for the time being and rely on "explorative" programming.

Take for example this multilayer system I've been trying to slap in my technology. I worked for a week on it, then talked with the guy making the assets. Guess what I found? The system is totally unsuited for what we have to ship. Bad surprise (that's what happens when you cannot make up your mind since the start).

If you want to keep it simple but still somewhat flexible, you could go with #1, but make it possible to specify which animation/sound/whatever to use. Doesn't give much, but still better than hardcoding everything.

I'd definately go for option 2. Its more flexable, saves you time (in the long run, obviously implementing it will take time), having scripting can be used else where.

OnDeath - play animation - dying, play sound - "arrrgg", particle effects (bleeding), you can do lots without having to hardcode it all and you can do alot with trial and error (imagine all that recompiling it would take without a script). If you implement a "reload scripts" thing you could edit and update while the game is running.

Caution advised. I've been there and you might be very sorry.
Have you read the "write games not engines" articles? I believe some are a bit over simplicistic.
Of course we need to get the job done, we want to maximize reuse as well.

Try to think at the final product and what you need to make it work. I think a very good way of doing things is to have stubs. You want to be as-data driven as possible, but not so much to not get short or mid-term benefit. If a feature does not pay back in mid term, it's probably not good to add it.
Also check your design. Perhaps the mesh does not really have to be so much flexibility.

Can you re-phrase your examples in the real world?
Caution: if you cannot, then you're probably going too far with reuse - perhaps it will be good long-term, but you'll take some risk (depending on how skilled you are). Try to have a balance between short-term and long-term. Perhaps you'll have to restrict to a subset of the features you want for the time being and rely on "explorative" programming.

Take for example this multilayer system I've been trying to slap in my technology. I worked for a week on it, then talked with the guy making the assets. Guess what I found? The system is totally unsuited for what we have to ship. Bad surprise (that's what happens when you cannot make up your mind since the start).

I'm not building an engine as you probably think I am... I have my own framework that I've developed for over 14 years, that is what you're probably thinking I meant. By engine I mean I'm building the framework and structure of the actual game, and not the low level things like the renderer or io system.

So basically you're saying I should go with option #1. The way I worked it in my prototype of the game. I have objects that would read animations, sounds and particle emitter setups from a file, if the file existed. Basically the file names were the hardcoded parts. So for my spaceship I have a file called "shipConfig", this file has to exist and what ever you want to be related to the ship has to be in this file. Then when events would happen, the game would see if a resource was loaded for that event and then use it.

so in the file there would be something like
<event onHit>
<playAnimation "animation description" />
<playSound "sound description" />
</event>

In the game every time the ship is hit it calls the function OnHit(), that checks what actions have been set for that event and plays any that are available. Now these are always visual or audio related, so internal game stuff happens differently, but that's my department so I don't need it to be too flexible. Also none of that even needs to be available in the file, you could just have nothing and the game knows nothing should happen for that event.

I guess I'll stick to this idea, since it doesn't have much at all to do with the gameplay, it can always be changed if it doesn't work down the road.