achowe@tiger.waterloo.edu (CrackerJack) (07/20/89)
I'm also currently in the process of writing a game (actually on hold
do to summer job as a programmer) but I have an answer to your question
about selling and PD (not necessarily the right one).
The way I figure it is this:
1) If you sell a game through a company you make squat for royalties.
You could also sell the rights to the program completely for lump
sum but if they make it sell then you'll be kicking yourself till
you die.
2) If you sell as an independent with no 'name' or 'imagine' then
you make investment to packaging and promotion. This may be alright
but you need either:
a) several titles to sell and/or
b) an excellent sound, solid, sellable product (SSS)
eg. FTL/Software Heaven came out with << Sundog >>. Excellent
quality. Next they released << Dungeon Master >> and they didn't
rush it either. Following that came << Oids >>. All of these games
are fun and meet the SSS standard. Any time FTL come up with a new
game I'll be able to trust the quality of ideas and code.
If your product is inferior to an already existing product or buggy
or difficult to use (bad user interfaces have been know to make or
break the product and company image eg. << Auto Duel >> gasp!!
vs. << Roadwar 2000 >> a good product) then you may be making an
outlay of monies that are going into a black hole.
3) That leaves the Public Domain of which two paths can be followed.
a) Release all your code and ideas into the world for free never
expecting a dime. If your code meets the SSS standard then this
only helps to build a reputation.
eg. Simon Poole and his << Uniterm >> product.
Also GNU software is often good. An other good example are the
guys behind << Sozobon C >>. If they had more time they could
really put together a solid fully optimizing compiler at lot like
WatCom C for the PC. With the support of the library writers for
dlibs, fplib, and gemfast, the << Sozobon C >> compiler (which I
use) have my highest respects.
You may be offered a job or at least recieve inquires either for
work or your product by companies. Also I find that repect is
often more important than the money, but we still must live in
a modern world and so must earn a living.
b) My last point is the idea of releasing early versions into the PD
to:
i) sample the market
ii) beta test software
iii) cheap promotion and advertising
From here you can decide whether you would like to become an
independent, sell your product to a companies, or just carry
on releasing into the PD updates because its more a fun casual
past time than a money making venture.
eg. Take the writers of << Quick Software >>, Darek Mihocka and
Ignac Kolenko. I believe that they are upper year or grad.
students here at U. of Waterloo (since they have unix accounts
here). I have not met them, but I see their intentions as
mentioned in the above point. They have several utilities that
seem to meet the first two SS and are trying to determine the
third S (sellable) by sampling the market.
None of this helps with programming but I hope this paints a picture
of an industry infested by a big blue bully in which machines with
less market share must try to survive with what software exists or
trickles into existence.
- Ant
achowe@tiger.waterloo.edu | "Murdered by pirates is good."
__ _ | - The Princess Bride (movie)
/ _ _ _ |/ _ _ | _ _ |/ |
\__| `<_\<_ |\|= | ` \_/<_\<_ |\ | disclaimer...terrell@druhi.ATT.COM (TerrellE) (07/24/89)
In article <15273@watdragon.waterloo.edu>, achowe@tiger.waterloo.edu (CrackerJack) writes: > > I'm also currently in the process of writing a game (actually on hold > do to summer job as a programmer) but I have an answer to your question > about selling and PD (not necessarily the right one). > > b) My last point is the idea of releasing early versions into the PD > to: > > i) sample the market > ii) beta test software > iii) cheap promotion and advertising > > From here you can decide whether you would like to become an > independent, sell your product to a companies, or just carry > on releasing into the PD updates because its more a fun casual > past time than a money making venture. > Alternative (b) is a tempting one - beta testing is EXPENSIVE. When I beta tested a program that I developed, I had to involve testers all across the country (none of them were local). That meant a hefty phone bill, and expensive postage. But it was worth it: the "world" didn't see the problems with the program that were fixed through the testing effort. Furthermore I don't lose sales to customers who are satisfied with a buggy public domain version, and have little motivation to go through an expensive upgrade. I'm surprised that you suggest a preliminary PD release for beta-testing when you mention elsewhere in the article how important your reputation as a software developer is. Making the public your beta test crew can be hazerdous to your reputation. I used alternative (b) once to do beta testing on a PD program that I had no plans of "commercializing". The program was a spelling correction program, and one user discovered a bug that would effectively delete big portions of the file being corrected!!! One the one hand I bug was reported (and fixed) that might have gone undetected with a smaller test crew, but also an embarrasing bug was reported worldwide on the net... Also, with a formal beta-test arrangement, your testers are more aware of your expectations. They will go out of their way to test things that ordinary users wouldn't bother with. My advice: if you have plans of developing a commercial application, choose a beta test team (~7 people), and pay the price. If the testing is properly managed, your investment will be returned tenfold! If you have no plans of commercializing a PD program, then try a testing strategy that is less expensive... I did follow alternative (b) more or less by accident. A PD application kept growing and maturing. Eventually I stopped issuing PD updates, and a year later released a commercial version of the product... NOW I wish that I could get the names and addresses of all of the PD users so that I could offer an upgrade... So if you can, find some way to inexpensively get the names and addresses of your PD users. This information can be very useful. If one of the PD software houses sells your product, I suppose you might be able to get the names and addresses from them...