[Discussion] Tired of hearing "soon"? Thoughts on the Q&A

[Block_Fortress]

gravypod I think part of the concern is how much faster it would be to allow schema to finish the work on what needs to be finished at this point vs bringing others in to help finish. While the remaining work can be broken down, considering how much is left with many of the new features, it might take longer to train new peeps. It seems like most the work is done to the point to suggest the latter.

You entirly missed his point there, hes saying that theres no point getting people to help with what schema is currently working on, because it will probably take longer to get help up to speed than it will to finish it.

We understand the time it will take to familarise people with Schema's style of code. However, in the long run, efficiency of updates will be improved. All we want is for this game to reach it's potential before its community becomes stale, like so many other pre release indie games.

 

[Cybertooth]

That was not the point either, let schema finish the cruicial core stuff he keeps telling us about, and then when its more stable others can look at new features.
Will you leave the game just because updates take time? Really? I know i won't. It all takes patience, i've waited years for games to be released, i can certainly do that again, especially as i can play as its being developed.

Also, this thread stopped going anywhere it could make a difference a while ago.

 

[gravypod]

That was not the point either, let schema finish the cruicial core stuff he keeps telling us about, and then when its more stable others can look at new features.
Will you leave the game just because updates take time? Really? I know i won't. It all takes patience, i've waited years for games to be released, i can certainly do that again, especially as i can play as its being developed.

Also, this thread stopped going anywhere it could make a difference a while ago.

What you fail to realize is that in a collaborative development, there is no "getting up to speed". Each developer should be fully capable of reviewing the code and making improvements.

Many projects also use a bug list in which each developer would separately work on fixing bugs or finding solutions for problems mentioned. The only "Up to speed" a developer would need to be in this potential collaboration would be the primary list of "goals" ie: major bugs that need fixing, major features that need adding, major code rewrites, etc.

 

[Cybertooth]

I get what people "should" be able to do. But what is schema to do? Just bring people on board trusting that they are capable?

 

[Neon_42]

Wow lots of discussion and some "discussion". I'm please to see that this has calmed down a bit. I think I can summarize a few things.

1) Some people are frustrated and bored with the progress being made
2) these people are more frustrated because they feel ignored.
3) answers to why problems exist are being given, and expected to be accepted, instead of answer of how problems will be fixed.
4) Many people here think schema can do no wrong.

I don't think any of these things are inherently wrong, but the discussion has stopped and now its just feuding between groups 1 and 2, and 3 and 4.

schema ...I have a two questions though. Somethings that struck me as interesting. You've mentioned scalability multiple times. I think you said that as people build larger objects the game needs to be more scalable? I believe this was in the Q&A. Have you considered that people build mega ships that lag and crash servers because there isn't enough to do in the game as it is? As a consequence, in the current state of the game It feels like just a ship builder. There is no reason to fight each other, space is vast and resources plenty. The new faction system is supposed to fix this I know and it will be here "soon". My second question is thus how do you prioritize what updates come next? It would seem in this thought experiment that people build larger ships, so the game has to be more scalable. Then people start building even larger ships, so the game has to become even more scalable, and so on.

 

[gravypod]

I get what people "should" be able to do. But what is schema to do? Just bring people on board trusting that they are capable?

Yes, that is how all people are hired for any position. The worst someone can do is nothing and that neither negatively or positively impacts anything.

 

[Firestorm29]

gravypod Actually, it doesn't always work that way. For example, with SMEdit, the person who was maintaining it complained of obfuscated code, which means it's tricky to know what's going on. I would be stunned if this isn't also a part of the organization tasks that Schema mentioned earlier. Sometimes, you can have things like names of variables and objects which make it difficult to tell what it does, or the code is written in a way where parts of features are in different parts of the class. Also, code which is optimized can also be harder to tell what it does. Being assigned a developer of a project doesn't mean you can simply be dropped into source code and know how everything works. That kind of thinking is what led to Planetside 1's performance issues and memory leaks. Please let me know if any of this is confusing at all, won't mind trying to clarify things.

 

[Cybertooth]

I think the building of large ships comes from more than lack of things to do. For example, i know people build large ships because you can fit considerably more detail on to them, have large fighter bays etc. Also the size of ships in tv shows/films doesnt really help the issue.
I realise you can do all that with ships that won't crash the server, but when you're allready at that sort of size, it doesnt take long for a who has the biggest "ship" competition to get out of hand.

gravypod yes but this isnt hiring people for the usual sort of job, if they're not competent then schema will have to take time making sure they're issue is fixed, managing them etc, which could make things take longer.
I understand why you're frustrated at the pace of the game, but it also doesnt bother me. I feel the updates arn't really too far apart. And ultimately this is up to schema. You can present your argument however you want, and decide that this is how you would do it, but it really doesnt matter. Besides, the thing about modders on the last page is probably the best course of action for this game.

 

[gravypod]

gravypod Actually, it doesn't always work that way. For example, with SMEdit, the person who was maintaining it complained of obfuscated code, which means it's tricky to know what's going on. I would be stunned if this isn't also a part of the organization tasks that Schema mentioned earlier. Sometimes, you can have things like names of variables and objects which make it difficult to tell what it does, or the code is written in a way where parts of features are in different parts of the class. Also, code which is optimized can also be harder to tell what it does. Being assigned a developer of a project doesn't mean you can simply be dropped into source code and know how everything works.

I have no idea what you are saying....

 

[Firestorm29]

There's a few things going on in that paragraph actually.

1. According to who worked with the code to create SMEdit, the code was hard to read and work with. Which means either he has to re-write his code so others can understand it better (and use more comments probably (guilty of this myself...)), or explain what each part of the code does.

2. A variable is a place where you store a number and an object is something which is a bit more complicated. These are given names so you can refer to where they are stores later. Problem is, you can name them anything you want. So you can wind up with variables and objects which don't explain themselves very well, like "XA3".

3. You can write code that isn't like a list of steps to do. So something like the parts of the program which make the weapons do whatever may be split in different areas of the code.

People may wind up doing things like saying "Screw this XA3 naming crap, I'll just make my own variables and leave those ones alone." That mentality leads to problems like hogging up RAM and/or Memory leaks.

 

[Ithirahad]

Keep all the time you need and make an more awesome game. I dont see it dying I dont even know how they come to that conlusion?

Ehh, I'd assume that it's primarily just due to some some fans attracted by the Yogscast leaving, as well as just conjecture from how slow updates have been, most likely... Personally, though the update speed can get a biiiit annoying sometimes, it actually has a significant upside - Generally, it's the more mature players who are willing to wait and don't get bored instantly because they find things to do (Minigames, etc.), resulting in a small, but tightly-knit and usually non-idiotic community, whereas Minecraft started quickly gaining popularity because of Notch's frequent (awesome!) updates... and gaining hordes of whiny/immature/annoying/etc. idiots.

schema ...I have a two questions though. Somethings that struck me as interesting. You've mentioned scalability multiple times. I think you said that as people build larger objects the game needs to be more scalable? I believe this was in the Q&A. Have you considered that people build mega ships that lag and crash servers because there isn't enough to do in the game as it is? As a consequence, in the current state of the game It feels like just a ship builder. There is no reason to fight each other, space is vast and resources plenty. The new faction system is supposed to fix this I know and it will be here "soon". My second question is thus how do you prioritize what updates come next? It would seem in this thought experiment that people build larger ships, so the game has to be more scalable. Then people start building even larger ships, so the game has to become even more scalable, and so on.

Yeah, this is how I feel too... I love scalability as a principle and ideal, but I'd much rather see features for more intricate, detailed, immersive, varied (especially those last two) smaller ships than performance updates to improve support for ludicrously large ones. When the economy is balanced, enormously gigantic huge ships SHOULD become essentially a thing of the past anyway, so why bother with always trying to make them work better?

 

[gashnal]

Everything you just pointed out is relying on two things.

1. Admins setting the correct settings in server.cfg (that is our choice if we leave defaults in place and also our own fault)

2. The Community you are choosing to be a part of.

You clearly have not been looking around much if you have not seen the hundreds of examples of emerging gameplay and player driven content that is not orchestrated by myself. This is filmed easily due to the game creating the content through player interaction. None of the thing you list are issues where we are playing Starmade.

Groundwork for the foundations go in first, not rushing in Shiny features to keep you interested when the rest of the game will simply be incompatible at this point. All the things people ask for have been confirmed. They have a roadmap and you need to learn to trust in that.


TLDR - default settings and an unengaged community make any game boring. This game is what you make of it, with the players you are with and with the settings you choose.

I think that's where people tend to disagree, what is "shiny" and what is "necessary"
AI is not step 1 I grant you but at this stage it should be at the top of the list, I played minecraft when you could stand in a puddle of lava and be totally fine and required script moding in the server jar files to make buckets even hold a liquid so I understand that erly game is full of bugs and compared to the erly days of minecraft this game is pretty well functional except this isn't starmade's early days its two years of development, and we still don't really have planetary mobs or a reason to use the mining mechanics, there is no survival options at all and no plans on making those core mechanics because the focus is on balancing things which shouldn't happen till you have all the core systems in place. The emphasis on making the game a PVP client is ruining development for the rest of us.

 

[Ithirahad]

I think that's where people tend to disagree, what is "shiny" and what is "necessary"
AI is not step 1 I grant you but at this stage it should be at the top of the list, I played minecraft when you could stand in a puddle of lava and be totally fine and required script moding in the server jar files to make buckets even hold a liquid so I understand that erly game is full of bugs and compared to the erly days of minecraft this game is pretty well functional except this isn't starmade's early days its two years of development,

I know what you mean, but... Didn't Minecraft take a long time (Since the first released version of Classic) to have even half of the amount of features Starmade has?

and we still don't really have planetary mobs

Agreed...

or a reason to use the mining mechanics,

A mining/crafting revamp is planned, and coming "soon"... :\

there is no survival options at all and no plans on making those core mechanics

Incorrect parts are marked in bold. Technically, the existence of pirates and pirate bases that send out raiding parties means that there is a sort of survival aspect... and there are certainly plans to add a LOT more survival features at some (far-off-ish... "eventually (TM)"?) point. However, yeah, currently space PvE is extremely lackluster and there is really no fun ground PvP or PvE; it's just whoever shot first.

because the focus is on balancing things which shouldn't happen till you have all the core systems in place.

He's adding a TON of new weapons next update, not to mention new planets, some texture changes, logic gates (like Redstone but better)...

The emphasis on making the game a PVP client is ruining development for the rest of us.

Um, no.

 

[rece ktore leczo]

I love scalability as a principle and ideal, but I'd much rather see features for more intricate, detailed, immersive, varied (especially those last two) smaller ships than performance updates to improve support for ludicrously large ones. When the economy is balanced, enormously gigantic huge ships SHOULD become essentially a thing of the past anyway, so why bother with always trying to make them work better?

Optimization of the engine must be done either way. Schema could just said "it's fine" and move to adding features and releasing the game, but then the final product wouldn't be optimized well enough and wouldn't be able to handle ships as big as current version can handle.
And don't even start with "optimization can come later" because that would mean much more work should be put in the future. And what it mean? MORE WAITING FOR NEW UPDATES.

So please read Schema's answers in this topic, he explained pretty everything we should/want to know.
I'm pretty sure there is one describing that adding features now and optimizing the game later would probably break the game and it would need time consuming fixes and also i think there is something about adding new features, that it would mean this game needing more resources, so without any further optimizations, next versions of Starmade would be able to handle smaller and smaller ships.
It doesn't mean we won't get any new features, but to do this, the foundations are needed.


If i didn't correctly recall what Schema meant then i'm sorry, better do not believe in my post and read Schema's answers Yourself

 

[Ithirahad]

I understand, Rece, but IIRC, part of his progress-log-thing stated that he did some optimization that's "mostly for big ships." I have no idea what his idea of "big" is, but if it's anything like the community's idea of "big," it's probably not what I'd put very high up on my list of priorities unless it helps in some other way.

 

[mindlord0013]

What you fail to realize is that in a collaborative development, there is no "getting up to speed". Each developer should be fully capable of reviewing the code and making improvements.

Many projects also use a bug list in which each developer would separately work on fixing bugs or finding solutions for problems mentioned. The only "Up to speed" a developer would need to be in this potential collaboration would be the primary list of "goals" ie: major bugs that need fixing, major features that need adding, major code rewrites, etc.

Schema created the game engine himself. I doubt there are many people familiar with using it. So it would be almost impossible for Schema to randomly hire someone and expect them to just know what to do, given a list of objectives. It would take time to familiarise them with the engine, time Schma has to put aside himself to teach them.

 

[therimmer96]

Schema created the game engine himself. I doubt there are many people familiar with using it. So it would be almost impossible for Schema to randomly hire someone and expect them to just know what to do, given a list of objectives. It would take time to familiarise them with the engine, time Schma has to put aside himself to teach them.

Yes and no, it would take time for them to familiarise themselves yes, but schema shouldn't need to do it. As long as he has properly documented and annotated the code, it should be easy for some one to pick up after reading it a few times. That is how people in the industry pickup projects from one dev after they leave. It is always good practice to document a large program, and always good practice to annotate, no matter the size of the program.

And I am happy to wait until the core is fixed before hiring a new dev, but I do think that would be sooner with another dev.

 

[Firestorm29]

Yes and no, it would take time for them to familiarise themselves yes, but schema shouldn't need to do it. As long as he has properly documented and annotated the code, it should be easy for some one to pick up after reading it a few times. That is how people in the industry pickup projects from one dev after they leave. It is always good practice to document a large program, and always good practice to annotate, no matter the size of the program.

And I am happy to wait until the core is fixed before hiring a new dev, but I do think that would be sooner with another dev.

That's the thing though, the code is NOT clear like what you are talking about. People like the SMEdit guys have tried and have had a hard time doing what you just mentioned. I'm sorry for the bold, but this is the third time I've said this now. Stop talking like it is when it is NOT.

And there are people who don't document what they code, either from bad practice, creating code which wasn't intended to be shared, or simply for job security. You can't fire someone easily who is the only guy who understands how your ATM program works, for example.

 

[therimmer96]

That's the thing though, the code is NOT clear like what you are talking about. People like the SMEdit guys have tried and have had a hard time doing what you just mentioned. I'm sorry for the bold, but this is the third time I've said this now. Stop talking like it is when it is NOT.

And there are people who don't document what they code, either from bad practice, creating code which wasn't intended to be shared, or simply for job security. You can't fire someone easily who is the only guy who understands how your ATM program works, for example.

The reason they cant read it is because it is obfusticated. schema for obvious reasons wont share how to de-obfusticate it yet. If some one was hired, he would share that information with them. anyway, I have said i am happy for him to do the core by himself, so stop acting like I am against schema and the game please.

 

[DukeofRealms]

I'll just leave this here http://en.wikipedia.org/wiki/Obfuscation_(software)

EDIT: Posted at the same time as therimmer96