phamicom - How to not write an emulator

Lillymon

New member
This is fairly random, but looking at FakeNES got me thinking about another NES emulator that died several years ago: phamicom. This was supposed to be continuation of FCE Ultra, using SDL, adding an in-game GUI, and generally fixing things up. It appeared, implemented some changes related to SDL, then promptly died. The last news update was over five years ago now. So what happened?

Well the thing I most remember was a post I made on a related forum, I can't find the post now, so I'll just summarize it as I remember.

Random poster said:
I've just heard about phamicom, and I've come to ask whether it will implement [Insert obscure mapper FCE Ultra didn't support at the time]?

Me said:
Well, I don't know. These guys are making big promises, but they just look like another bunch of unproven programmers to me. I've seen my fair share of projects make a few news posts then die, and I don't have a good feeling about this one.

phamicom developer said:
I'll have you know we're not 'unproven', we've each produced multiple software projects and all have great experience in this field. As for the mapper, our aims are not currently aimed at improving the emulation accuracy, we're focusing on implementing the in-game GUI at this time.

That was pretty much the topic. I probably wasn't as nice as I should've been, but when am I ever? I sometimes like to think I am the person that killed phamicom, though my comments may simply have been prophetic. I think I can draw one reason why phamicom didn't do well from this though.

#1: It didn't focus on accuracy.

As far as I'm concerned, accuracy takes centre stage with emulators. Emulators allow you to operate software on the platform they emulation, more accurate emulation means you can operate more software. On the NES, this means more accuracy means you can play more games. The opening poster in this topic was clearly looking for that, and I think any project that doesn't focus on accuracy is missing the point.

Thus phamicom failed because it was an emulator project that didn't really have any focus on emulation. This may have been because the developers came from outside the emulation community and wanted to focus on the 'general experience' rather than doing what we actually care about, and making more games work. This fact made it hard for anyone to get excited about the project, and so it almost immediately faded out of view as other emulator advances captured more interest.

Still, that's not the whole story. Some programmers can go for ages without anyone noticing what they're doing, so what else was going on? Well the first news post for the project states: "Currently, phamicom is being spearheaded by Deraj, Dangalak, and Flea.", which is central to my second point.

#2: Too many cooks spoil the broth.

Most great projects start with one talented programmer. Others then join, but the initial programmer takes a leading role. Others start with a conglomerate, but one person gets the final say about where the project goes. Either way, the key is leadership.

I can't say for certain, but I think phamicom didn't really have a 'lead' programmer, it just had three highly experienced programmers who all knew where the wanted the project to go. Trouble was, there was no agreement where to focus on first, so they didn't. Their efforts got spread, enthusiasm quickly waned, the project stagnated, and the initial programmers went back to their own projects.

So, my thoughts are that phamicom likely died because it was unpopular and directionless. The two fed into each other. The lack of direction meant it never built up any sort of community, and the lack of a community meant the programmers didn't have anyone suggesting what was most important to focus on. Thinking about this gives me more of an insight into byuu's seemingly strange licensing, the community is of great importance when coding emulators, and the phamicom developers never had one.

The lessons to be learned are that you should figure out what the community actually wants to see, make that you first area to focus on, and make sure you have a leader that can keep programmers focused on that.

That is all. Good night, and good luck.
 
I dunno... I don't think one can really draw any solid conclusions about what doomed a project, without having been privy to the internal conversations. What you suggest are possibilities, but those aren't necessarily the only ones...
 
But she is right. Successful projects ALWAYS have a top motivated leader behind the stages.

I have tried a non leaded team project. The result was anarchy and chaos. In the end we lost everything.

Then in the next try I took the leadership, as my team asked me to do so. I changed the organisation, the workflows, the hierarchy etc. Most people were impressed and motivated while some few preferred the easy going from before where nobody really had to say something. It's not a question of power, but responsibility. If you are in charge you have to solve problems and set a course. If you are just member you don't have to decide but work on the tasks.

(Sorry if my English may not be perfect, I'm no native speaker)
 
The multi-coder thing can work. What you need are well-defined interfaces. That way, the work can be divided into modules. You can do what you want within your own modules; if you follow the interfaces, all the work will fit together.
 
The multi-coder thing can work. What you need are well-defined interfaces. That way, the work can be divided into modules. You can do what you want within your own modules; if you follow the interfaces, all the work will fit together.

...if someone defines the interfaces and the others agree... ;-)
As far as emulation software goes I have seen more one man shows with great results than multi-coder projects. It's the nature of software development that you have to program the thing the way you think is right or have to define the concrete steps and milestones, work packages if you work in a team.
 
*pastes the entire contents of The Mythical Man-Month in this space*

Which does, by the way, argue that a software project, no matter how vast, must ultimately be architected by one mind. It also suggests that whatever the lowest level, the code itself should be the responsibility of one person, assisted by other people who don't directly write code.
It seems to be generally well thought of. In the few projects I've been involved with, there always seems to be a single coder at the top, whether by fiat or de facto.
 
Last edited:
But she is right. Successful projects ALWAYS have a top motivated leader behind the stages.

Putting aside for a moment whether that's true, you're missing the point of my previous post. If condition A is necessary for success, failure doesn't necessarily mean condition A wasn't met. Any of a number of other things could be the hitch. In a case where one doesn't actually know any real details, it's arguably wise to avoid drawing firm conclusions from that particular example.

That said, I disagree with your claim above. There are plenty of real-world examples of successful collaborations --particularly when dealing with just two or three people-- in which the collaborators cooperated on equal footing. Even if you were to limit the scope of your statement to software projects, you'd be wrong; I know programmers who have worked on projects that could serve as counterexamples.

That's not to argue against having a single strong project leader- it's often a good idea, particularly for software development. It's merely that there are few phenomena involving people for which one can safely use the word "ALWAYS" (in all caps, no less =P). Insisting on such an absolute is a bit presumptuous.
 
@Isildur:
Okay your are right, there are always examples where my theory breaks. But this is just my own experience. You are also right with your statement that failure doesn't necessarily mean condition A wasn't met. I can only agree on that. I had a really incompentent boss and even more incompetent employees.

But I still believe that a project has more chances if one takes the lead and the others contribute. Otherwise it will work until the point when there is no consensus possible. I see no point in endless discussions in a project. In a conflict case someone has to make a final decision or people talk the project to death and leave.
 
Yeah, I agree that's usually the case. In a leaderless group, even with just a few people, there's a risk of people not seeing eye-to-eye, and the project becoming hopelessly mired in disagreements, and that risk multiplies with each additional person.

Speaking of bosses, though, another problem I've seen is inability to delegate responsibility. In a company I worked for, the boss would insist on micromanaging everything, with the result that she was a terrible bottleneck, because every slightest thing had to be okayed by her. On top of that she would change her mind frequently after much work had already been done based on her previous directions, so I and other employees would have to do things over. Things got done at a glacial pace. It was incredibly frustrating. =P
 
Oh yeah. The first thing I learned as project manager in a software company was delegating. It's crucial in order to keep the overview. But I think your boss just had the habit of the founding days when all decisions had to be made by her.

Change requests by management is also a big issue. That often happens when a boss doesn't really know what is technically possible and what not. If a boss also doesn't know how much work time has to be spend on workpackages he or she makes promises to the customer which bring you as employee into big trouble.

So in an optimal case your boss has experience in these kind of tasks because he or she has done it before and remembers what it means. But I also had a boss who was a perfect technician but lacked some experience in financial issues like making a well balanced offer. The often made error is to cut down the work time in order to make a more competitive price. This only works when you have to do a routine job, but not if you have entirely new technology or tasks.
 
Sounds to me like having the emulator "look pretty" took priority over functionality. This somewhat reminds me of ZSNES, which (as of 1-8-2009) stands at v1.51, which was released on 1-25-2007. This is my favorite SNES emulator, and it's somewhat disappointing to not see anymore updates. I mean, I know that there are unofficial updates, but it's nice to have a stable, official update. Ah, I'm rambling...
 
Sounds to me like having the emulator "look pretty" took priority over functionality. This somewhat reminds me of ZSNES, which (as of 1-8-2009) stands at v1.51, which was released on 1-25-2007. This is my favorite SNES emulator, and it's somewhat disappointing to not see anymore updates. I mean, I know that there are unofficial updates, but it's nice to have a stable, official update. Ah, I'm rambling...
from what I know hanging around the development channel, pagefault is still working o that brand new core.

Then again, he's been doing that for the past year or two, so I dunno.
 
from what I know hanging around the development channel, pagefault is still working o that brand new core.

Then again, he's been doing that for the past year or two, so I dunno.

Well, presumably he wants to do it right. I'd rather have him taking his time than have something that wasn't worth the wait.
 
Good things come to those who wait. Maybe you should wait a bit longer and maybe. Just maybe. You will find what you are looking for. Quality doesn't happen overnight you know.

I am still here BTW :)
 
Back
Top Bottom