The more I program, the more the artist wants to change things... (I believe this is normal?)?)?

Good (INSERT DEITY HERE), after 20 games, I write so much... I program so much. I feel like it's a constant battle between me and the artist team. They always want something "new", yet they asked for something new 4 weeks ago, I delivered. What is wrong with me sometimes i feel, why can't the 'Artists' just use what they have, that I intentionally made reusable?

NO

They always want something new, every day. Is this the 'Norm'? It's like, I make reusable code, they want something better. Why can't they build on the platform I founded. Is it something wrong with me, or is it something wrong with them?

 

Yeah, that's what game design documents and SCRUM are for.

 

Grow some balls and tell them no. They're doing what anyone else in their situation would be doing -- that's why they're artists and you're a programmer. They don't know what goes into coding something or how hard it is, as far as they're concerned you're a wizard who can do anything. They're visual, they want to see shiny stuff. Know when to put your foot down, if you let people walk over you, they will. Why wouldn't they?

If they don't get that the code is reusable, show them how it's reusable. Make presets for them and stuff like that.

 

Consider their request and try to see things from their angle. Always be open to the possibility that your own biases may be skewing things for you, and your initial trepidation to do something may be a story your telling yourself. Estimate how many hours it will take you and compare it to how many hours they think it will save them. If you don't have enough time for all the requests, ask them which one is the most important to them. They have their biases too, so be fair and objective in trying to determine the right course moving forward. Also tell them of your concerns. Let them know what things are hard to implement and why. There is certainly a way you could simplify the situation so a non-programmer could understand. Don't BS them.
Lastly, listen to the people who have been the most useful in terms of workload. People who contribute to the game the most and are getting the most stuff done are better licensed to request things. If you feel these artists' work is inconsequential, or you don't have respect for them, walk away from the team. If you're the leader then get rid of them.

 

Learn to code flexibly.

 

I'm amused by how much variation there is in the responses you're getting.

In my experience, changes will come up in every project, but if things are nailed down ahead of time, it's a lot easier to explain why the nails shouldn't be pulled back up.

If the artists on your team get the final say no matter what, then as long as you're getting paid for your time instead of per-task, then at least you're making money on their indecisiveness. If you're getting paid per-task and they keep changing the tasks, then you need to bring the issue up and request that task specifications be detailed up front.

Lastly, I think you'll find that things get better with each new client/employer - both because you'll work for better organized people and because you'll get more accustomed to production faults yourself (and anticipate them).

 

Whether ideas like these come from within your team ("hey I just saw this new game that has X, we should add that!") or from a paying client, you need to learn to put these requests through some kind of process. Ideas are cheap but effort is expensive. Nothing will burn a developer out faster than reacting to constant change requests, which often are nothing more than fleeting whims, thought up in an instant and forgotten the next. It's hard to kick goals when the goalposts keep moving.

When these requests come in, document them into a "backlog", where they will be considered and ranked against all of the other similar requests. Then, when you have some free time (ha!), you can sit down as a team to estimate them, prioritise them and pick the best ones. You will be amazed at how many of them will simply be dumped onto the cutting room floor, because they are no longer the shiny new idea.

 

Just 'cause they want it doesn't mean you have to do it. There should be some management process around this so that it's not ad hoc and your time is used effectively.

Yes, everyone always wants something new. But are they always willing to pay the cost? And do they understand what that cost is?

As for "why can't they build on the platform you founded?" That's a great question. Ask it of them, find the answer. Often coders think they're designing for artists/bankers/basket weavers, but who they're really designing for is other coders, or themselves. Is that perhaps why your art crew aren't re-using your stuff? Or do they not understand it? Or have you misunderstood their needs? Or do they not understand reusability? Or...?

 

"The only constant is change." ... quite whining and deal with it. Learn to YES...AND in conversations and find ways to evolve towards a win-win by listening to what they're really after and finding similar solutions that are easier to code.

Grok the idea of the 3rd option.

Gigi.

 

Practically speaking, discuss and agree more at paper level before going into coding.

 

You say you're coding flexibly, but they're still asking for things that won't work with what you've coded. Perhaps you're wasting time trying to be flexible and should instead just code what they need, adapting as you need to. Don't give them things they didn't ask for.

 

I haven't thought about this video in a while, but it seems relevant. It's a level designer/artist's perspective that mirrors your programmer's situation.

 

So as some varied responses may have made apparent to you - the issue has a lot of different answers from different perspectives.

I would suggest the artists themselves probably have a different story than you have.

All that aside I wanted to bring up something because as a one man team I am both the artist and the programmer and I do the same thing to myself but I understand why I'm doing it and can make decisions when its the right thing to do for my game and when its really feature creep.

The root of this for me is the iterative design process. It is incredibly difficult to nail everything the perfectly the first time.

Often as you create new screens, new animations, new buttons, new backgrounds it becomes painfully apparent what is lacking and where you need to do something to make your product be what it really needs to be.

Iterative design process is not feature creep. It can feel like it if you do not understand what is going on.

I would be open to discussing the changes ; but always keep on the table that ultimately your trying to ship a product. If the need derives from making a good product that works properly and pleases the user and looks and feels good then it may be worth doing.

If the need comes from a random creative flash the artist had for a brand new never previously discussed item naturally I would say 'Hey that's an interesting idea. I'm going to put that on a list for possible items to do in an update if our product does well in a 1.1 release. For now lets focus on getting this product out the door!"

 

It is my personal opinion that iterative design processes should really only be used during prototype/alpha phases. That's the point at which it's okay to need to see things partly in-action before you know if they work or not. It also means that while it's still good to do your best to write clean code, it's not such a big deal to make a few sloppy mistakes as long as it lets people test the idea.

There comes a point at which you move past this phase though, and you have to have a plan and stick with it. One of the most common problems I've seen with startups and indie teams is that they act like they're prototyping nearly up to launch. Almost everybody figures it out eventually though.

 

I can agree with you deram_scholz. It's a little hard to draw that line clearly when you do a mobile project that only takes a month sometimes though

 

I agree that at some point you have to lock your project down and finish it instead of continuing to change stuff forever. However, "alpha" is typically the stage where you're feature complete and are starting first rounds of dedicated testing.

To me, the further you get along a project the finer-grained changes should become. Early on you can make broad, sweeping changes that impact the whole project. Near the end you want changes to be pretty local and to have minimal impact on other areas.

 

Feature creep is what destroyed the first game I worked on, years ago. I was just the Lore Conceptualist so didn't have much say but members of the design team constantly asked the programmers for more and the programmers didn't say no. So the game became huge and impossible to support financially.

Listen, consider, and give a realistic estimate of the time and money it will add to the game development. Then if necessary, say no. Or you can say we will save that for later in development and come back to it then.

 

Pretty much this.

Also: Have a plan.
If you need to change things because your financial situation changes, a concept proves harder to implement than expected or an idea just isn't good, that's fine. It's perfectly okay to change an existing plan.
Making one up on the fly however, is a quick way to get stuck.

 

From my perspective it seems like there is not enough of a team going on. It shouldn't be a battle to do the project. Sure there will always be challenges but you have to all get on the same page. Do you all have the same vision and do you all really know what you are building? It sure sounds like the answer is "no". It seems like they have one set of expectations and you have another. My advice is to get together with them and get on the same page. Find out what their expectations are and let them know what yours are. Find out exactly what you are building together as a team. Or find another team that you can gel with.

 

LOL! This is awesome!

 

This is critical.

If everyone's pulling the project in different directions you're heading for trouble, no matter which way you cut it.

It's normal for team vision to drift and you should accept that there will be change over time, you can't realistically set things in concrete at the start. So, this isn't a do-it-and-its-done thing, it's something you need to actively maintain for the entire lifetime of your team.

 

Got something better to do?

 

i havn't gotten bothered by artist asking for new feature. But I get bothered by artist not following the format (when i was working with Adobe Flash long time ago). Wrong Pivot. Too heavy CPU-workload art work. Irresponsibly naming.

 

Why is your art team making architectural decisions about your game? This stuff should all be done way before your art team is engaged.

 

I can safely say we do not work like or experience any of the replies or comments in this thread. Thank goodness!

 

I wonder if these are randomly generated 'internet' teams, or mayhaps they have inexperienced leadership. I lead teams in my day job and my night job. By night, 'my team' means the wife and I, and by day, 'my team' is distributed across 6 companies in 3 continents. In both cases, the teams communicate smoothly and efficiently with a constant emphasis on 'Change is the only constant'.

Gigi

 

Change, any one have any spare change?

 

geez, did I really write this post? Thanks for replying! It let's me know I'm not the only programmer in this boat!

out of 1,000 artists, maybe 1 has come here to this forum. Artists don't believe in the Internet.

So the only thing I can assume, is everone posting here, is a programmer.

 

I'm an artist and programmer, and my girlfriend is another artist. I can agree with @Gigiwoo that "Change is the only constant" is sort of umm.. unavoidable to an extent, but it sounds like you're redoing a lot of the same thing thus being stuck in the same place, or progressing really slow, for a while, which is also avoidable, to an extent. You can avoid some of that constant daily change by having a done GDD of the game, and following through it.

Ofc there's still gonna be a lot of changes but if your game designer and artist and you know what you're suppose to be making then it should smooth that zig zag a bit.

As much as I hate it I work by "Change is the only constant" daily. Me and the gf brainstorm a lot of ideas and new things pop in and out constantly, but we find a middle ground, and stick to it, to an extent. xD

As much as I hate it, you can't avoid change. Learn to roll with it. And tell your artists to dial it back a bit, and think ahead a bit. Redoing the same thing daily isn't very productive. xD

I started designing all my code and assets in a way that I can sell them on the asset store for people to be able to just throw in their projects and it'll work, that guarantees I can reuse it as well in a different project.