"Patch" :doitnow!:

[RolandtheMad]

There is a patch in the works already for refitting I believe.. we should petition to GET PLANETS or at least SYSTEMS RENAMABLE. It may be hard but *it is not impossible* and it *will add to replay value* and *the eXperience*. I mean really.. I just don`t get the same space opera feel about System X as I do about "The Grand Homesystem of the Mighty Human Empire"

The way to do this would be like one person described - basically every system keeps the same name for programming purposes but a player can put a mask over it for cosmetic purposes..

For multiplayer they could devise some elaborate naming convention or maybe just whoever controls the system (and if it is divided control then nobody can rename).

[H Tower]

wait, let me get this straight, they haven't finished the game yet, and they're already working on a patch?

Show me some proof please.

[RolandtheMad]

http://www.ina-community.com/forums/showthread.php?threadid=244675&perpage=30&pagenumber=3

Go to bottom, read Xentac's reply

[H Tower]

that doesn't mean they're sitting there working on it already.

And now that I think about it, its not as strange as it sounds. Different people have different jobs, some work on multiplayer, and others work on AI, etc, etc.

[RolandtheMad]

It has been said more than once and by different people in regards to refitting, that was just the first I found.

[kalbear]

So, to clue folks in in the process of the generic software engineering group:

There are developers. They have a few jobs. Some program. Some do artwork/content. Some write stories.

This is all work done from about the beginning of the project through the middle. Design is done first - layout, specs, that sort of thing - and then work fleshing out features, adding things, changing things...

Meanwhile, you have testers. While this early dev work is going on, they're busy writing test cases based on what the specifications say should work. They're writing tools to help auto-test the thing. They don't tend to get to do a whole lot of testing at this point, because, well, there's not a lot of stability to test. Maybe component-level testing - the graphics engine, art display, sound, menuing...but nothing concrete, usually.

The next stage is called 'feature complete'. This means that no new features should be added to the existing framework. Code is still being tweaked, changed, modified, and sometimes totally written. Features can be stubs at this point, that do nothing. Artwork can have placeholders (like the Ithkul, for instance). So long as all the features are actually present, that's the important thing.

Well, not really. The important thing is that nothing new is being designed right now. The product is being performance tested, memory tested, conformance tested. During this time, the devs are fixing a large amount of bugs and spending time finishing up the features left. Hopefully more of the former, less of the latter. Testers are getting closer and closer to full testing, where they have a complete product to test against without having to worry about 'is this turned on yet' or not.

Then 'code complete'. This is often referred to as an alpha product, though that's wrong. At this stage, all features are fully written and should function according to plan. No features get added, and no major changes to the codebase are done unless bugs warrant them. Testers are finally able to get into the full flow of things and throw all those tests they've been writing for months against this puppy. Devs...well, the main job they have at this stage is to hunt down and fix bugs.

I'll say that again, because it'll be important later - they hunt down and fix bugs here. That's really it. They tend to start working on design on the next revision at this stage, because they often have a lot of free cycles while waiting for bugs to hunt down.

Then we get to alpha stage, which is a fully functioning product with plenty of bugs in it. Followed by beta, which is a primarily stable build that may have some poorly-functioning features.

That's what beta testers get. They get a full-functioning product with possible problems in it. Actually, LOTS of problems - lots of little bugs that have been dropped down in priority compared to crashing bugs and bad features. Again, devs are to be fixing these bugs at this point.

Part of the process of fixing bugs is deciding when to fix them. Some bugs require so much work to fix that they are postponed, even if the solution is known and can be done, because they'll step on stability, or rely on a not-yet implemented feature, or aren't essential. Those get pushed towards a patch.

Patches are basically another product. They have to go through the same cycle of engineering anything else does. So, while testers are taking the latest super-stable build of 1.0 and making sure it runs, devs are fixing the bugs that are on their plate to be fixed for 1.1 and preparing it for testing. They're also adding features, enhancements, that sort of deal.

So really, them working on a patch? They've likely had a 'for patch 1.1' branch of the code tree for a year now. That's how these things work, and honestly that's a good thing. The devs are still working furiously, and let me assure ya that as soon as any bug pops up that is truly important in the 1.0 testing, devs will jump on it to solve that sucka. But in the meantime - in the weeks that regression testing can take - the devs work on the next patch.

Totally normal phenomenon, and totally not indicative that anything is wrong with their engineering process or that they are dumbasses of any kind.

[Harry Seldon]

Fantastic. Maybe we can direct them to the Death by a Thousand Cuts thread to pick up some pointers on includes for the patch. I'll admit, it makes me feel better about purchasing the game knowing they're at least considering adding in some of the features we've been begging for.

[TCO]

Originally posted by kalbear
So, to clue folks in in the process of the generic software engineering group:

There are developers. They have a few jobs. Some program. Some do artwork/content. Some write stories.

This is all work done from about the beginning of the project through the middle. Design is done first - layout, specs, that sort of thing - and then work fleshing out features, adding things, changing things...

Meanwhile, you have testers. While this early dev work is going on, they're busy writing test cases based on what the specifications say should work. They're writing tools to help auto-test the thing. They don't tend to get to do a whole lot of testing at this point, because, well, there's not a lot of stability to test. Maybe component-level testing - the graphics engine, art display, sound, menuing...but nothing concrete, usually.

The next stage is called 'feature complete'. This means that no new features should be added to the existing framework. Code is still being tweaked, changed, modified, and sometimes totally written. Features can be stubs at this point, that do nothing. Artwork can have placeholders (like the Ithkul, for instance). So long as all the features are actually present, that's the important thing.

Well, not really. The important thing is that nothing new is being designed right now. The product is being performance tested, memory tested, conformance tested. During this time, the devs are fixing a large amount of bugs and spending time finishing up the features left. Hopefully more of the former, less of the latter. Testers are getting closer and closer to full testing, where they have a complete product to test against without having to worry about 'is this turned on yet' or not.

Then 'code complete'. This is often referred to as an alpha product, though that's wrong. At this stage, all features are fully written and should function according to plan. No features get added, and no major changes to the codebase are done unless bugs warrant them. Testers are finally able to get into the full flow of things and throw all those tests they've been writing for months against this puppy. Devs...well, the main job they have at this stage is to hunt down and fix bugs.

I'll say that again, because it'll be important later - they hunt down and fix bugs here. That's really it. They tend to start working on design on the next revision at this stage, because they often have a lot of free cycles while waiting for bugs to hunt down.

Then we get to alpha stage, which is a fully functioning product with plenty of bugs in it. Followed by beta, which is a primarily stable build that may have some poorly-functioning features.

That's what beta testers get. They get a full-functioning product with possible problems in it. Actually, LOTS of problems - lots of little bugs that have been dropped down in priority compared to crashing bugs and bad features. Again, devs are to be fixing these bugs at this point.

Part of the process of fixing bugs is deciding when to fix them. Some bugs require so much work to fix that they are postponed, even if the solution is known and can be done, because they'll step on stability, or rely on a not-yet implemented feature, or aren't essential. Those get pushed towards a patch.

Patches are basically another product. They have to go through the same cycle of engineering anything else does. So, while testers are taking the latest super-stable build of 1.0 and making sure it runs, devs are fixing the bugs that are on their plate to be fixed for 1.1 and preparing it for testing. They're also adding features, enhancements, that sort of deal.

So really, them working on a patch? They've likely had a 'for patch 1.1' branch of the code tree for a year now. That's how these things work, and honestly that's a good thing. The devs are still working furiously, and let me assure ya that as soon as any bug pops up that is truly important in the 1.0 testing, devs will jump on it to solve that sucka. But in the meantime - in the weeks that regression testing can take - the devs work on the next patch.

Totally normal phenomenon, and totally not indicative that anything is wrong with their engineering process or that they are dumbasses of any kind.

Very educational. Thanks. When does "funness" get tested. Does the rule of no new features get bent a little because of funness issues discovered late in testing? And is this an issue only for games or would there be similar function issues in a non-game piece of software?

[Craig P.]

Funness got tested back in April, was found to be lacking, and much chaos ensued.

[Zed-F]

Non-game software works similarly, in that design for the next release often begins while testing of the current release is wrapping up. In most respects, game software development process is not radically different from non-game software development process.

[kalbear]

My post was about generic software engineering. Games fall into this roughly well, especially now considering the complexity of said games. There's a slightly added consideration that I'll talk about in a bit.

Ideally, funness is tested from alpha on, and is heavily looked at during beta stages. Useability testing is done a lot here, for instance.

When something big happens to change the product because of outside stimulus, it's often back to the drawing board. It can be a LOT of effort to go and change things once you're in beta stages, and this is the main reason that you don't want to do it at this point - because it means there's a lot of wasted effort and work going on.

There's also plenty of other considerations in the real world that occur to screw this up. Companies have external pressures to finish a product build, even though they know that it's crap or not right. Marketing said 'we'll be done by X time' and we need to make that time. Or there's a big tradeshow. Or the VCs are saying that they need something to say in a press release or they'll drop funding. "When it's done" is a very abnormal situation in the software world; only some game companies get that luxury.

Games are more complex in another way - they're almost entirely user-interface based. Windows is by comparison easy to program for - there is a set of components that one uses to make a UI, they all work through the exact same keyboard/mouse shortcuts, they all have a generic feel. Games use many different input systems, output systems, use hugely varying graphics. sounds, and are totally non-standard in their application. Each time someone invents a game, they're basically starting UI development from scratch.

UI is easily the hardest thing to test in the world in terms of software. And that goes for ANY software.

Games are almost entirely UI.

Thus, we get very large teams of people to do the testing, and it takes a while. Again, MOO3 is totally normal in this respect; if they didn't do this, I'd expect and likely get a very substandard product with many many bugs.

[Zed-F]

I'd say that HW Interface testing can certainly be more complex than UI testing... but most applications written for PCs don't have to deal with that, or at least not in any great measure.

[kalbear]

HW anything testing is usually MUCH easier to test, because it's simulatable. Unless you're talking useability testing, but that's another type and that falls much more into UI testing. UI testing, whether it be software, hardware, or, well, non-computer ware, is difficult because of the difficulty in simulating reasonable scenarios and the multiple choices a person has all the time.

It's especially hard to do so with good coverage.

If you're talking about testing the actual interface - the pin outs on joysticks, the buttons on mice - that's not nearly as hard, though it can be expensive to create a simulation.

[Zed-F]

I'm talking about embedded systems, where you have computer hardware built to perform a specific purpose, and have to write the software to control the hardware. This can be simple or complicated depending on the nature of the hardware, but the kind I'm talking about is definately complicated. I would classify the software that controls these sorts of systems into User Interface, Application layer, HW control layer, and Base/OS layer. Of the four, in the systems I deal with, the HW control layer is usually the one that gives the most trouble. This is because, oftentimes, the HW does not behave as expected, and in our case, because of the sheer amount of HW controls that need to be monitored/set.

HW testing simulation will only take you so far, especially when you're talking about custom ASICs, custom boards, etc. where you have to actually try everything out to make sure it behaves as it's supposed to. Simulation also is not very useful at testing real-time factors like race conditions, because the fact that you're simulating in the first place tends to alter these factors, for instance by making your code run faster or slower. This is not to say that simulation is valueless, but it's only a small part of the total testing solution in this case. In converse, in the application or UI layer, if something works in simulation, odds are it will work on the real system, as they tend to be more tolerant of realtime issues.

In comparison to the HW interface, the user interface for these sorts of systems tends to be relatively simple, with a limited number of things the user can do, and a limited number of ways of accessing the system. As a result, the UI layer usually has fewer problems to deal with. Moreover, in many cases, we have an offboard system manager that works through the UI layer on the embedded system but presents it in a more user-friendly way and provides some additional management functionality. These offboard system managers are usually smaller projects and are completed with fewer problems than the embedded systems they control.

[Asmodean]

MY God, kalbear. You're like an oracle. Hat's off to you.

Asmodean