At what point would you personally accept that it is more feasible to write a brand new game?
At what point are you willing to merely steal the art assets of an old game? I mean, I'm not legally sure in all countries, but I think technically the binary patches to the game are a violation of copyright anyways? I'm asking, at what point are any principles being stood upon. Why not just make a clone SMAC project and if you want to CYA, first say "you must first install SMAC to use this" ?
I've dealt with a lot of open source projects over the years, including trying to involve myself with FreeCiv at one point. Someone tried a "mod it for SMAC" effort at one point, but they didn't get very far and abandoned it. This is a pattern with most people in open source: they propose pie-in-the-sky projects, they get started, they run into trouble, they get bored, and finally real life intervenes with money and job pressures. There's a very limited timeline that anyone has for success. A lot of people think they have lots of time to work on things because they're "not being paid and doing it in their free time". What such people usually fail to realize, is that personal concentration is a finite resource that is evaporating.
In short, how feasible is it for you to do any of the things you suggested? Do you have a track record of actually shipping open source projects, and having them be successful for some period of time?
Myself, I managed it once. Basked in the glory for 6 months of wonderfully working code. Then had a fight with the project lead, who dumped my code. A man-year of effort down the drain on my part. Well, that taught some things about self-destiny.
For writing a brand new game we'd need great story designers and writers.
Also some voice actors
I've been maintaining a fully-featured open-source program for 6 years.
Why haven't you forked the project? In fact my project started as a fork in 2012.
QuoteI've been maintaining a fully-featured open-source program for 6 years.
Well good, then we don't need to go through any more "amateur hour" admonitions. The question still stands though. When do you accept that it's easier to write a new game?
QuoteWhy haven't you forked the project? In fact my project started as a fork in 2012.
Because I was the CMake build system guy, not the Scheme compiler writer guy. I did not have enough understanding of compilers at the time to develop the core compiler. The strategic issue is that although the guy allowed me to create the fully working Visual Studio build, he had no personal committment, investment, or incentive towards Visual Studio or CMake. His concern with Windows was minimal as well. He would complain about all the extra work CMake was causing him. Since of course I had done the heavy lifting to make it all work, my reaction is like what am I, chopped liver? He threw out the code; I had hoped the small community around the compiler, would see the value of keeping this thing working with the CMake build. But push come to shove, nobody else wanted to do the ongoing support for CMake and Visual Studio. Windows wasn't sufficiently important to them.
CMake has become standard drill for so many projects since then. No it is not a lovely build language, and I won't be doing any more of that, as that part of my so-called career is long since over. But what a waste, back then. I learned that I can't drag people into support situations they basically don't care about.
Could it be that you yourself are interested in writing a game from scratch?
I'm sorry but so far you haven't proven your case. Creating a new codebase for the same assets (either based on the original executable to the point of being a derived work, clean-room engineering, or not at all based upon it) is by far easier, and has guaranteed results.
Also note the finished Diablo 1 complete rewrite "Tchernobog"
Now that's a coincidence. The final straw in forking "opentrack" was that after having received the go-ahead for porting to Linux, the project owner refused to accept the code. The rationale was that he was comfortable with ".sln" files and CMake was new. Having done the porting work, the build system choice was either autotools, SCons or CMake.
Man I regret giving up CL due to the lack of work. No one's hiring except for ITA Software.
Could it be that you yourself are interested in writing a game from scratch?
It was more than an interest. I tried to write such a thing during the dot.com bust and ultimately went bankrupt. It won't stop me from trying again, but many core design issues of the 4X TBS genre have eluded me over the years. Making something very similar to SMAC is doable, as it's been done before. But making something that is an improvement, game mechanically, that doesn't devolve into tedious unit pushing... I've never figured it out. It may be an intractable problem. I wouldn't say I've given up, but after all these years of contemplation, I'm most certainly stymied.
I've also contemplated the best way to narrate something like a SMAC universe. It leads to different problems. Although SMAC's naration is good, and half of why we still play it, it is also uneven in quality and needs to be regarded objectively for its faults. They got some things right and other things are just filler. It is sad that nobody had any incentive to try again.
QuoteI'm sorry but so far you haven't proven your case. Creating a new codebase for the same assets (either based on the original executable to the point of being a derived work, clean-room engineering, or not at all based upon it) is by far easier, and has guaranteed results.
Newsflash: you don't have the source code. Twiddling an AI you don't have source code for? Good luck with that. I'm writing up a Yitzi game in the AAR subforum right now. I see no evidence of it playing any better. AI does the same dumb things it always does.
QuoteAlso note the finished Diablo 1 complete rewrite "Tchernobog"
A complete rewrite is a "new game". Not hacking on the binary of an old game. If you thought I meant you must design a completely new game experience you are mistaken. That's up to your ethics of how many copyright violations you want to make with a derivative work. You could rip off the story and art assets of SMAC and call it a day. You could CYA by saying "you must install SMAC first". If you are content with a hobbyist level of effort, probably no one will sue you.
No one has sued FreeCiv. Game mechanically it's almost a straight copy of Civ II. There are very few changes. There's even a "Civ II compatibility" ruleset option if you want to make sure you're playing straight Civ II. They did write their own code and provide their own art assets. I don't recommend using their code though. Unless something changed dramatically over the years, it's an ugly mess, and the AI isn't that bright anyways. Not what I'd call a treat to work from.
QuoteNow that's a coincidence. The final straw in forking "opentrack" was that after having received the go-ahead for porting to Linux, the project owner refused to accept the code. The rationale was that he was comfortable with ".sln" files and CMake was new. Having done the porting work, the build system choice was either autotools, SCons or CMake.
Project leads are #######s when it comes to build systems. It's a permanent cultural problem with programmers, because in the C/C++ ecology, the build system is made to be a completely different thing than the rest of the programming. So programmers don't like new, tedious learning curves beyond their current skill set. If they are project leads they handle this problem by executing build guys that come along to do ports. You can do the greatest port ever; the project lead will say "waah I don't like it, I have to lift a finger to have this capability." They don't care about the new capability, you cared.
So then you're faced with taking on the whole project yourself, without any help. And the extant community is probably going to stick with the old "official" project anyways in most cases, so you won't get anyone else helping you. Gotta handle all the coding and build a community too. For many starter projects that's a completely losing proposition, and certainly was in my case.
A possible answer is to have the build system technology deeply tied to the language, so that nobody is fighting and gnashing teeth about learning how to do builds. Rust has this kind of design. To be honest, their included build and package system is the only thing I'm sure I like about Rust. I'm not convinced that the safety dances they want programmers to do, actually buy an independent game developer anything. My jury is out on the question, and I reevaluate the Rust community from time to time, but so far they haven't produced anything tangible that would make me change my mind.
I have worked on designing my own programming language, which I'd eventually integrate a conceptually similar build system with. But I have not gotten far in the language design effort. Frankly I've gotten stuck a lot.
BTW I didn't fork CMake either. That would have been a sheer suicide mission. Yes I had a falling out with their principal developers, I was kicked off their mailing list. A little too interested in forward looking ways of making things better. Consequently my willingness to touch anything related to CMake nowadays is pretty limited. Conceivably I would do it if some open source project actually had value to me. I have bugfixed a few people's CMake builds here and there over the years. But in practice, no open source project has had any ultimate value to me.
Especially, 3d graphics engines are generally made on wrong principles that aren't sustainable for my needs, so I've given up on people who try to write them open source style. Most of them make the same basic mistake of trying to do DirectX and OpenGL at the same time. I really wish OpenGL would hurry up and die. It's sad, and I was on the OpenGL side of things earlier in my career, but things evolved as they did. It's a painful, crippled API nowadays and it needs to be shot and left in a ditch. Of course the Linux crowd doesn't know what they're doing with graphics stacks, so they'll piddle with Vulkan and nobody else is gonna care. Windows has DX12, Apple has Metal, they don't want Vulkan. If Vulkan could finally kill OpenGL on Linux that would be a good thing at least for Linux, but they will foot drag that for quite awhile. That's pretty much the Linux way in my experience. You get diversity but you also get inertia and low QA.
QuoteMan I regret giving up CL due to the lack of work. No one's hiring except for ITA Software.
I've never thought that jobs depended on what compiler one knows. But then historically, I had 3d graphics software development as my specialty area. It was niche, and I was hired based on what I could do with that. I didn't hang out in industry very long before going my own way either. Logical next stage would have been to go work as a principal at somewhere like NVIDIA, but I realized it would be way too dry and boring for me. I tried to find my star as an independent game developer... and 20 years later, I'm still trying.
As for the Common Lisp ecology, been there done that, trying to assess it for Windows game development. They never could provide anything. It kept me looking for other languages. Eventually I gave up and decided to try to write a language. Which I've had little success with. Anyways, the people in the CL community are all too old to make Lisp a "great thing" again. New languages borrowing from Lisp have a chance to be accepted, but the old timers who really do Lisp proper, they're done. They don't have the energy to fight the standards and marketing battles to make Lisp a thing again.
For the record, I will never work on extending the SMAC binary. I'm impressed by the people who choose to deal with software that way, but for me personally, it is commercial suicide. I've wasted years of my life on endeavors that have no money at the end of the rainbow. I can't afford to do that sort of Quixotic thing anymore. Really I'm only interested in the kind of game development that would actually make me a living. That means choosing partners very carefully, or avoiding them entirely. So I feel a need to be clear up front with my intentions, and the bar I set for partnering with people. If we're not even on the same page about some things, for instance the Windows vs. Linux gaming ecologies, there's no point in even wasting the time. Which is why I prefer the public discussion processes to shake those things out, to get to know people better.
You can't make a 60 Hz game on SBCL or any other implementation.
It's only JVM that allows for consing freely and wastefully while still keeping deterministic 60 Hz.
Just like Closure isn't a working web browser.
They hold some nonsensical positions, e.g. that FFI to C code isn't the right choice because of C code implicitly connecting to Unix signals.
- Skyrim has better graphics and slightly better combat than Oblivion
- Life is Strange is like Telltale but done right (note, I love LIS)