On 2013-07-10, Jeremiah Goerdt <jeremia…@gmail.com> wrote: > After getting halfway through the tutorial (did I mention how awesome > the tutorial is?) I decided to go back to Haxe (an amazing language) and > build my own framework.
Please, I beg you to reconsider. Don't make a framework, make a game. Then make a couple of other games using the same code. Then you will have a framework. A framework made without a game usually turns out very convoluted and completely useless. You need a way to "ground" your design in something real, and actually making a game as you go is a good way to do that.
About a year ago, I spent some time looking at MUD codebases with permissive licensing. I was unpleasantly surprised at how barebone most of these were. The authors all had stated something to the effect that they didn't want to abduct people's creative vision by adding a combat system, etc.
To me, that's such a cop-out. Why not code a solid combat system in a modular fashion that makes it easy for someone to unplug it or use it as a stepping stone to write their own modular combat system. Sure, I know the answer–because that's a lot of work :).
There were also a few codebases that were more feature-full, but written in an incredibly idiosyncratic way. They smacked of a single author who never had to worry about someone else reading their code. This, too, would have been different if the author had actually run a game using their own codebase.
There were also a few codebases that were more feature-full, but written in an incredibly idiosyncratic way. They smacked of a single author who never had to worry about someone else reading their code. This, too, would have been different if the author had actually run a game using their own codebase.
Most of these code bases I've seen are from games that actually opened and were popular. As you say, it takes a lot of work to get it to this point. Getting to this point and having a cleanly written code base is less likely than getting there and having some degree of mess and over complication.
There were also a few codebases that were more feature-full, but written in an incredibly idiosyncratic way. They smacked of a single author who never had to worry about someone else reading their code. This, too, would have been different if the author had actually run a game using their own codebase.
Most of these code bases I've seen are from games that actually opened and were popular. As you say, it takes a lot of work to get it to this point. Getting to this point and having a cleanly written code base is less likely than getting there and having some degree of mess and over complication.
Yikes. I haven't really looked at complete games because those tend to be leaks with no clear terms of use. I guess I was assuming that if you have multiple contributors over a period of years, it would mean cleaner code. Maybe that's not a good assumption in our field.
> After getting halfway through the tutorial (did I mention how awesome
> the tutorial is?) I decided to go back to Haxe (an amazing language) and
> build my own framework.
Please, I beg you to reconsider. Don't make a framework, make a game. Then
make a couple of other games using the same code. Then you will have
a framework. A framework made without a game usually turns out very
convoluted and completely useless. You need a way to "ground" your design
in something real, and actually making a game as you go is a good way to
do that.
–
Radomir Dopieralski, sheep.art.pl