Zophar's Message Domain

Go Back   Zophar's Message Domain > Emulation Talk > General Emulation

Reply
 
Thread Tools Display Modes
Old 12-31-2008, 01:59 PM   #1
Lillymon
Senior Member
 
Lillymon's Avatar
 
Join Date: Apr 2002
Location: England
Posts: 2,379
Default phamicom - How to not write an emulator

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.

Quote:
Originally Posted by Random poster
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]?
Quote:
Originally Posted by Me
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.
Quote:
Originally Posted by phamicom developer
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.
__________________
Amelia Explains It All - Eventually. Probably.
Lillymon is offline   Reply With Quote
Old 12-31-2008, 08:46 PM   #2
Isildur
Senior Member
 
Isildur's Avatar
 
Join Date: Nov 2004
Posts: 1,339
Default

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...
Isildur is offline   Reply With Quote
Old 01-02-2009, 05:54 PM   #3
Shadow
Senior Member
 
Join Date: Aug 2008
Location: Germany
Posts: 108
Default

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)
Shadow is offline   Reply With Quote
Old 01-03-2009, 12:09 AM   #4
Ugly Joe
Senior Member
 
Ugly Joe's Avatar
 
Join Date: Dec 2003
Posts: 1,461
Default

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.
__________________
Ugly Joe is offline   Reply With Quote
Old 01-03-2009, 10:54 PM   #5
Shadow
Senior Member
 
Join Date: Aug 2008
Location: Germany
Posts: 108
Default

Quote:
Originally Posted by Ugly Joe View Post
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.
Shadow is offline   Reply With Quote
Old 01-03-2009, 11:35 PM   #6
hcs
Senior Member
 
hcs's Avatar
 
Join Date: Oct 2001
Location: California
Posts: 1,585
Default

*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 by hcs; 01-03-2009 at 11:42 PM. Reason: explainage
hcs is offline   Reply With Quote
Old 01-06-2009, 04:26 AM   #7
Isildur
Senior Member
 
Isildur's Avatar
 
Join Date: Nov 2004
Posts: 1,339
Default

Quote:
Originally Posted by Shadow View Post
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 is offline   Reply With Quote
Old 01-07-2009, 12:40 AM   #8
Shadow
Senior Member
 
Join Date: Aug 2008
Location: Germany
Posts: 108
Default

@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.
Shadow is offline   Reply With Quote
Old 01-07-2009, 09:34 PM   #9
Isildur
Senior Member
 
Isildur's Avatar
 
Join Date: Nov 2004
Posts: 1,339
Default

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
Isildur is offline   Reply With Quote
Old 01-08-2009, 05:03 AM   #10
Shadow
Senior Member
 
Join Date: Aug 2008
Location: Germany
Posts: 108
Default

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.
Shadow is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 03:57 PM.

Contact Us - Zophar's Domain - Archive - Top

Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2019, Jelsoft Enterprises Ltd.