ed: the biggest issue with an "Indie MMO" is that maintenance costs can make it a non-indie kind of venture very quickly.
219 karma · joined February 16, 2009
http://ludamix.blogspot.com
ed: the biggest issue with an "Indie MMO" is that maintenance costs can make it a non-indie kind of venture very quickly.
If you want a hope of success in games, either do a low-asset kind of game, do a game where big assets are matched with big marketing, or involve the users in creating content. I think there's still lots and lots of room for the third.
The first url I actually remember would probably be liii.com:8000 as that was the host of a Merc MUD I played on(Barren Realms). I have some recollection of playing on it a few times before we got internet access at home. Now they're at http://www.barrenrealmsmud.com/ and I haven't visited in probably a decade now. Nice that they're still around.
The second early url I remember is crl.com, the dial-up ISP my dad signed up with. We had a shell account on a real Unix box, with a whopping 5mb storage, and we weren't allowed to run SLiRP/TIA so we couldn't emulate a SLIP/PPP connection and use graphical browsers(a sore spot as the Web got increasingly graphical). They moved to business-only services some years later (and we moved on to other ISPs) Now the domain appears to be taken by a drug company. I don't remember what crl stood for, even.
A third good one was ftp.wuarchive.wustl.edu. They had a pretty spiffy anonymous ftp in the early 90s. Apparently it is now "too expensive to push bits to the world."
My predominant memory of the internet before around 1996 was that the Web was only one of several viable systems: email, Usenet, telnet, and ftp were also used by my 8-to-10-year-old self. But as I got older, the Web rapidly took over everything. I was still using dial-up right up until 2003 when I went off to college. And then still used dial-up when home on breaks, until I got a laptop and stole the neighbor's wi-fi. It's funny to think of how much dial-up's user experience grew less tolerable over time.
(This is from the perspective of doing mostly non-commercial programming. In commercial work you are mostly cleaning up other people's messes; there is little of interest and few learning opportunities after a certain baseline.)
Later on I can look back at it and use the idea in a more considered essay.
The point made for human health in the Middle Ages can be interpreted as a factor of the lower number of people around at that time. The difference is that we now support a large population via improved disease treatment and engineered methods of increasing calorie count. We probably still don't get the same kind of nutrition per person as the people in the Middle Ages.
Alternative currencies are worth considering(for example, the scrip used in Germany and Austria historically.) in isolation as a means of balancing local economies with national ones.
I speak from experience; the game I'm working on at my studio has an in-house tool to optimally paletteize 2d assets for an embedded system. It's a computationally hard problem so a lot of intermediate data is generated to make the final build relatively fast.
This tool generates about five files, IIRC, and one folder, for each frame of animation. Multiply this by 30 frames per second for each sprite's anim. Multiply this by an entire game's assets. The result is 80,000+ files and folders checked into SVN. That's after the coder optimized the number of files needed slightly. It can take 20 minutes or more to do an SVN update because of all the checks needed.
The solution we really need is a versioning system for binary files. There aren't many of those. Maybe Perforce works. I don't know, I've never used it.
But when felt like I hit that goal I didn't stop learning, I actually got more into it because I wanted to learn ways of getting a better result in less time, and the obvious answer to that was to keep studying and soaking up knowledge.
MacGyver.
Programming is the craft/art skill of manipulating digital code and data. Within programming you can learn about specific domains - for web apps that would mean databases, networking, a host of standard formats and protocols, and user interfaces. Many commercial programmers go their entire career focused only within one or two domains.
Computer science is the academic study of computation. As the rigorous curricula of today would have it, it is a more mathy endeavor than programming by itself. In particular there is a focus on provability and formality that doesn't come up in commercial programming.
Basically, stuff you learn in CS won't help you ship the ideal mix of features, stability, and time cost for (insert app here). What it will tell you is about a variety of methods with which you may approach the underlying computation problems and direct your own original research efforts.
So this only works if you are in a franchise business where everyone works to a script and does not innovate, develop long-term relationships, or perform an important leadership function.
http://thinking-forth.sourceforge.net/
The ideas present - which are much more craftsmanlike than an academic paper - are easy to absorb by skimming, and they're still relevant even after 20 years of research/fashion trends in programming.
Plus Forth itself is, in a lot of ways, the living embodiment of the YAGNI principle, which can make it look uncomfortably-to-incomprehensibly spartan to outsiders.
haXe and Factor are both good examples of languages that have a basis with which to grow their libraries. haXe is getting uptake from a variety of angles but the emphasis is clear the everyone involved wants to minimize the costs of multiple-language incompatibilities, and that is resulting in powerful libraries across multiple domains. I don't know the details of Factor's growth, but I suspect that it is doing so on its strengths as a "next-gen" concatenation language in a field with little comparable competitors. Both languages have C bindings available, but haXe in particular has strong reasons to create native libraries.
Linus did not start a startup to make Linux. He still hasn't bothered with one, though he certainly could have done so at various points. Similar stories exist with a huge number of open source projects.
Basically it seems like you only have to start one if:
-You don't get enough time any other way.
-You need additional resources to build the project.
-You like the people and energy.
-You want the money.
Time doing "my" work: 1-2 hours on weekdays, 4-6 hours on weekends. The stuff I'm doing is 100x as interesting of course, and I don't have to communicate, so I'm probably 10x as productive. I find that by the end of the weekend I'm always a little shocked at having to come into the workplace and slow down again.
For a few months recently, I found it really, really hard to get things together at the end of the day. Then I realized that a significant part of the problem was because of blood pressure; it's higher in the evening, making it harder to concentrate, and I had let my average drift upwards as well by eating junky stuff.
Now I try very hard to get it down - diet during the day, 20 minutes cardio after work - so that I can stay productive in the evening.
Basically it comes down to the workings of the game mechanics; with repetition and reward/penalty systems they point the way towards deeper inspection of any desired element.
Recently I've been writing some code which is surprisingly amenable to a cut+paste approach: A tool which automatically generates level layouts for a game. At first I endeavored towards a data-driven approach to customizing each type of level I wanted to make, but soon I decided, "There are only six types of levels. Each one has different requirements and they get maintained in isolation. There is no point in trying to reconcile all of them at once."
And so I went ahead with a strategy of reuse for the most common elements - low-level generation strategies - and made big switch statements for the remainder. It works, I get the job done, and there's almost never anything surprising. The only time something did surprise me was when I accidentally pasted the same code twice in different places and threw the results askew in a non-obvious way. That flags some need to slim down bloated methods, but even as-is, it still feels pretty slim at ~2500 lines.
Manuals and references for programming languages tell you about the syntax and major features but demand endless curiosity on your part to answer your own questions. Tutorials may give you how-tos for certain specific problems but usually fail to explain basic concepts. College courses usually give both how-tos and conceptual information but are usually targeted towards the abstract. In all cases you have to provide the "sweat equity" of writing stuff, failing, testing, retrying, etc.
The most well-rounded introductory literature I've seen is in textbooks. Other programming books are aimed at existing programmers that are transitioning to new languages, learning new concepts, etc.
My suggested starter set for someone intending to write web apps would include several textbooks, a book on SQL, the reference to the web language you wish to use(don't fret too much about this, it's almost a coin toss when you haven't tried using any), and a book on web frameworks for your language. The textbooks will often want to use languages that are not popular web languages, but that can be a benefit, as it teaches you what is really different between these languages, and how to focus on the concepts.
You can start by making sense of the things described in the textbooks and rewriting their examples in the language you want to use. Gradually the frameworks will look more approachable and you can start working with the examples in those. At that point - some months down the line - you may be able to get serious about your app.
It's actually a really hard problem to solve in both an accurate and fast manner without making major design assumptions. How wrong have people gotten it?
http://www.youtube.com/watch?v=Hgd3YcmIvYE http://tasvideos.org/RockmanTricks.html
Mega Man's collision was above-average for its time, and holds up to normal play, yet it is full of exploitable bugs. If you can make a system that works well enough, you are most of the way to having a game, and the next most helpful thing to learn would be finite state machines and variants.
But that doesn't mean it has to be a proprietary commercial product either. See MySQL, Firefox, SugarCRM, etc.
ed: to clarify, the only reason to have any portal is to promote the app.
ed2: I should have just linked to this in the first place: http://ludamix.blogspot.com/2009/01/intro.html