The Ur-Quan Masters Discussion Forum

Hi,

I was curious, are there still people associated with/working on this project?  Also, is there a creative roadmap?

I'm a dev, might have time coming up, not sure, anyways I was just curious if this was still a thing.

Thanks :D

The project died about 3-4 years ago with some early phantom limb movement, but this was predictable when the whole thing became Project 6014 Plus where community was valued over competence.

Given that Star Control is a quarter century old, this is the time everyone should forget the idea of a mod sequel anyway. There should be a Star Control adventure generator by now or at least an engine that would let anyone make their own SC sequel, because I grew to believe that large crews like ours was can not make a game like UQM.

they were in need of a dev, but be prepared to work on horribly ancient code ;)

Mkay, I mean I imagined that it would be some combination of data files and adding legitimately new things to the game, depending on the story ideas.

Anyways, is the code/resources in a repository somewhere where I could pull and build if I wanted to take a look at it?

Thanks :D

well, the google code project was at

https://code.google.com/archive/p/project6014/source

except that they don't have the source code available there - at least, not without proper membership? Google seems to think it doesn't exist, not that I don't have permission to get it.

Oh, okay, I finally found it:
https://github.com/trinaryouroboros/project6014

From looking at it, I agree in part with what Kwayne said about needing a modable engine.  It looks like story elements are hard-coded into C data structures, probably what I would be tempted to do would be to go back to the original UQM, fork it, then try to factor the story elements out into data files so they could be modded easily.  I could also see some room for randomness that might allow the adventure to be different for different playthroughs.

Hard-coded into C isn't so bad IF it's set up right. After all, C is a pretty decent language.

But you need a good organizational system to know where to put things, and a good set of functions for keeping everything organized.

It's certainly a lot easier to do that than to generate another abstraction layer.

That said, I did write a scripting language for dialog options, and I began an interpreter but got tangled up in string handling. Working with strings in C is not my forte.

So instead of letting it have at least the potential of becoming a good and beloved fangame like Megaman Unlimited or AM2R, you just let it die a quiet death.

Such a dissapointing turnout.

Lets hope stardock at least does some good with the ip, tough im not holding my breath.

So quick to throw stones, ye who didn't lift one to help.

Actually I did at least give them some idias for missions and races, like the yuptar. I dont know if they even considered tough, but I did more than "nothing".

The problem with this is that from what I've seen from looking at the code base, it seems like every feature required C/C++ development, and there was a shortage of C/C++ devs but an abundance of people with other skills putting in requests for work to be done by C/C++ devs.  Ideally a C/C++ dev could to a small amount of work so that unlimited features could be added easily by modders.

Anyways just to update I looked at this a few months back.  If I remember right it seemed like there were three forks of UQM:
1.  The pristine original
2.  Hi definition, a fork of the pristine original
3.  Project 6014, a fork of hi definition

I ended up looking at at least a few of these (I think it was hi-def, and a diff with project 6014) and came to the conclusion that it would be totally feasible to work on this, but haven't actually taken the time to do it.


Probably what I would be tempted to do is define an xml format where scripts could be added, along with references to datafiles and art, making it easy to define new things.  From what I saw it seemed that the way things were organized closely related things were spread out all over, making changing things arduous.

If I remember, for example, there were datafiles that contained mappings from symbols to strings used in dialogues, but the actual dialog logic was in a totally different part of the code.  This just seemed hard to work with.

Yes, and that's what I tried at first to replace and then interface with, until I threw my hands in the air (even though I still cared).