Development Blog

When it comes to people using Leadwerks to design their games I wouldn't have thought the design was that critical in many areas for someone to have to do all the design up front simply to delegate it out to programmers to code, unless the quality of the programmers employed was very poor!

 

I think the design is very critical in an LE game where you have multiple people because part of that design would need to be the interactions between components. Start a project where you, NA, Master, & Max make a game and only give a vague design and tasks and combining all that code will most likely be a nightmare. But have a detailed design doc where you describe the functionality for a specific task and the interaction interfaces that task needs to expose/consume and you'll have a much better chance at success.

 

I've actually thought of experimenting with that. I want to make a simple pong game and I would just make a detailed document broken out by task and detail how each task would be consumed and what it should expose and then as people on the forums to do these task. I would break the tasks out to be very small so it would only take someone maybe a couple hours. Then I would assemble the pieces to make the game. I think it would be an interesting experiment to test exactly what Josh is saying. If I have 10 different programmers would they really be tripping over each other? The game would be like Pong or Tetris or something simple.

This article was written to explain some of the advantages people working in small teams have, so they can better understand their own strengths.

 

that's the way i read it...

 

Frictional Games and their small team accomplisments comes to mind...

 

well... i guess it's safe to assume that beta 1 is just around the corner i mean after getting so positively vibed

after reading the article...

 

 

 

--Mike

I agree completely, and have experienced this myself when I was doing engineering. You can see this with Unity as well. In the very beginning they were much faster at getting the technology out, but with almost 100 staff, they still put out great stuff, but you can see that the efficiency portion has definitely dropped a bit (but probably not as badly as some because I think they do a good job at hiring people), and in many cases they've just bought in or licensed tech instead (beast, umbra, etc.).

 

The only way that large companies can stay really efficient is if they have a real brainchild managing the project who can layout every system ahead of time and delegate work to a bunch of really good "day to day" single task coders. People who can do that are few and far between.

You can see this with Unity as well. In the very beginning they were much faster at getting the technology out, but with almost 100 staff, they still put out great stuff, but you can see that the efficiency portion has definitely dropped a bit

 

See I don't think that has to do with the amount of programmers they have, I think it has to do with the amount of processes they put in place to reduce the risk of someone releasing code that screws their program up. When they had 100 customers they could afford to screw up. When they have 100,000 customers, screw ups cost you more as it kills your reputation. They probably have to do change controls, then 3 people have to approve, a code check has to happen, then instead of making new releases every day they wait and package them together because nothing pisses people off more than having updates every single day because changes are it'll break something for you. These things are what you do when you are a big company to reduce risk and what you don't have to do when you aren't. That has nothing to do with the amount of programmers you have.

 

This article was written to explain some of the advantages people working in small teams have, so they can better understand their own strengths.

 

Interestingly enough the "advantage" a small team or company has is that they have to take more risks to make it big. So their advantage is they can "afford" to go out of business which is kind of strange

I think the design is very critical in an LE game where you have multiple people because part of that design would need to be the interactions between components. Start a project where you, NA, Master, & Max make a game and only give a vague design and tasks and combining all that code will most likely be a nightmare. But have a detailed design doc where you describe the functionality for a specific task and the interaction interfaces that task needs to expose/consume and you'll have a much better chance at success.

Sure, if there is to be a common communications interface used by all components then someone would need to design that up front, that almost goes without saying as you are requiring everyone else to use that, but then the rest boils down to functional specs again for the remaining components.

 

If you want say a path finding system writing, or a foot placement system with IK, or a blended animation manager please don't tell me you'd be designing all that up front and telling me how to code it because that would probably result in any decent programmer walking at that point as you have effectively de-skilled the job and demotivated your staff by turning them into a team of monkeys who just churn out code.

 

Sure you can operate in that way, but that's your own choice. It's not because it has to be that way. Maybe lots of software houses do operate in this way and I've just been lucky in not working for any of them yet, I don't know.

You can see this with Unity as well. In the very beginning they were much faster at getting the technology out, but with almost 100 staff, they still put out great stuff, but you can see that the efficiency portion has definitely dropped a bit

See I don't think that has to do with the amount of programmers they have, I think it has to do with the amount of processes they put in place to reduce the risk of someone releasing code that screws their program up. When they had 100 customers they could afford to screw up. When they have 100,000 customers, screw ups cost you more as it kills your reputation. They probably have to do change controls, then 3 people have to approve, a code check has to happen, then instead of making new releases every day they wait and package them together because nothing pisses people off more than having updates every single day because changes are it'll break something for you. These things are what you do when you are a big company to reduce risk and what you don't have to do when you aren't. That has nothing to do with the amount of programmers you have.

 

 

The number of programmers you have, assuming your statement to be true, which I agree it probably is, directly affects the number of potential errors there can be, and lead programmers ability to watchdog, those issues. Many hands, often spoils the soup, and the rate at which you can cook more soup does not increase linearly with the number of pots, stoves, and cooks, particularly if you have to make sure the soup is just as good, and tastes the same, in every pot, which inevitably has to be done by one master chef or a master and a very select number of understudies.

 

Another way to say it is, I think you are right, but it is a contributing factor, and what you are saying is compounded by the number or programmers, and is not an either/or counter to what Josh is saying.

 

If you want say a path finding system writing, or a foot placement system with IK, or a blended animation manager please don't tell me you'd be designing all that up front and telling me how to code it because that would probably result in any decent programmer walking at that point as you have effectively de-skilled the job and demotivated your staff by turning them into a team of monkeys who just churn out code.

 

I think many shops can operate this way. Many times shops would rather have senior programmers doing more design than coding because they are more valuable coming up with a good design than typing away at a keyboard. The design is where the value is not the typing of the code. I love doing both but if I was forced to choose I'd rather go design. So your decent programmer in your example would be coming up with the design and having "newer" programmers following the design and typing the code. The design is 90% of the battle.

 

One benefit of doing it this way is that you can outsource the actual typing of the code if you need to. You can also have 1 programmer pick up where another left off if something comes up with the first programmer because it's so well documented and designed.

 

This is what indie designers should be doing. Instead they often come with vague descriptions and no knowledge about the systems required or how to come up with at least a high level design of them. There is a big world full of programmers who will take those tasks on. Instead they want these designer programmers on the team and you can't have to many of them on the same team because of a clash of principles that will most likely happen.

 

Saying all that I would prefer to just give the required interactions for the design. Tell the programmer here are the inputs and here are the outputs required. I would probably give tell them how I want these inputs and outputs designed though so it's the same way between programmers.