I just finished a commission job a week or two ago (you can see a video of it here:
https://www.youtube.com/watch?v=CXeGb8xN9qA), and earlier this week stumbled on this older thread. I can't even remember what I was searching for now haha Anyway, I'd like to give my input on this. It's been kinda touched on, but rainwarrior I think touched it the best.
Flexibility.
If you go in with dreams so big about how you want a project to go, especially in a niche area like retro homebrew, and don't let the programmer provide input and/or experiment with some of your concepts, they are probably going to program it in a way that isn't fun for them, and as a result the game will probably show that. This goes directly to what you said, Jedi:
Jedi QuestMaster wrote:
are the people who are programming doing this because they believe in the project or are they only looking for money? I would honestly like a situation where it's both: you love my ideas
and I compensate you (especially if it's
my project). If it were a group collaboration from the beginning, that might be different. We all want to be content creators, but how often would we want to work on
other people's projects?
I really wanna talk about this, because I think my recent experience will show how a programmer can go from, "Okay, I am going to get paid to make this game... ?," to "Okay, I am getting paid to make THIS game!"
I was presented with some Youtube videos of an unfinished Genesis game (that is going to be a sequel to the NES game) and nearly all the NES artwork finished in a big BMP doodlesheet. The overall concept was explained to me. I asked a few questions, etc.
Firstly, don't be afraid of something different than you had in mind being changed. Two instances I can think of from the project I just finished are the bombs and the pipes. With the former, on the Genny version the antagonist would toss the projectiles in a way that they go up a bit, then back down. But there weren't graphics that were presented that I thought would suit something like that (I believe the firecrackers/dynamite at the beginning of each building were supposed to be a projectile of this sort). So instead, I drew up a bomb sprite that fit into his 16x16 gaps and used those during gameplay, and kept the dynamite things only for the intros just to mix it up. Using those also kept the sprite limit from breaking while he was climbing to the top of the screen, as opposed to having 16x16 bombs which would've definitely broke it. It turned out looking really clean, and he liked how that turned out, and I liked that I got to add something to it. Win-win!
With the pipes, there end up being instances where they are stacked on top of each other. The original solution presented to me was to have the player climb the pipe, and when they reach the next floor, stop them, and require them to push up or down again to get on the next pipe. When I implemented that, it felt like it really dragged the speed of the game down, even if it's just a split second it takes the player to push in the appropriate direction again. So instead, I just had the player able to get on or off of the pipe with a 16 pixel leeway when they are over a floor, and an 8 pixel leeway while they are under the floor. It kept the action going, and the designer really liked how that turned out. Win-win!
On the flip side of that, we know that not everything we present is going to be something that you like. I can give two instances of that, as well.
When you pick up a burger in that game, I wanted to have a mini-song play similar in fashion to how Sonic is about to run out of breath while under water. I had that finished and presented it, and he didn't like it. We talked about it and decided that the tick-tick that speeds up would probably be best, so I scrapped the mini-song idea and went with that. It ended up working perfectly, and we were both happy. Win-win!
When I implemented the "window fixing," I just went by positioning and didn't use typical bg collision. Since the windows were limited to the exact position on each screen, I just had a lookup table determining, "if player is in one of these positions, they can fix the window." With the way I had position change, it was more to the right (I didn't use different points with different positions, because I didn't see the point in it, so just used one 16x16 position). So the pos of the left side of each window was used. In this way, you had to be mostly centered on the 32x32 window. This worked alright, but he wanted to let the span of the window be the deciding factor, not just being in the center of it. So I had to go in and change it to check for both positions (left and right of the window), and give some leeway to the positions on each side. It also really helped the pace of the game remain quick, and we both loved how that turned out. Win-win!
I think these four instances illustrate how you can work with the programmer, and both come up with something you like. When I was about 60% through the project, I was like, "Man, this is coming out a lot better than I thought it would!" I told him after the fact that I was not sure about the game when I started the project. I figured it would be just "okay." By the end of the whole thing, I was as excited about it as he was. Are there things that I would change in it that he wanted? Yes. Are there things that I did that he may have wanted slightly different? Most likely. But it didn't end up feeling like a chore for me to work on the game. It
felt like it was my game as well... because of the flexibility of the designer.
And if I can hit on one other aspect of this, scout out programmers. Different people work differently, of course. For instance, I like to be able to put the CHR files together myself, because it will vary from project-to-project on how things need setup for our particular style of programming. Where the digits will go to make things speed up in the code (i.e. maybe not having to add to get a proper offset into the CHR), whether or not 16x8 sprite mode will be utilized, etc. I would personally find it more annoying rearranging tiles that already exist rather than putting them in myself. Some programmers might want those details already finished, though. That would require you to know exactly what you want, however, which may have the tendency to put a tighter grip on the whole flexibility thing.
So I guess the tl;dr of this is that, even though we may be getting paid to do the job, we still want our input to be valuable to the finished program, so that we have had some sort of impact besides laboring, which would probably divest our interest in it, causing our work to feel like... work : P It's a niche thing, retro homebrew, so feeling like work is the last thing that we want. Try not to flesh out every single detail, and I think that will make a world of difference.
I think this is all I can think of right now.