Day-To-Day Work Logs and Woot! Engine Stuff!

Exciting! This rules.
And is quite unexpected. Does this mean there is an alpha going on right now where people like kazeto and essence and fax are all testing it?

So uh yeah... we can sign up for the mailing list at the new web page, but will cutting edge information make it to us via mail before we could get it here in this forum. As forum regulars, I feel like the regularity of posts by members of gaslamp keep us very up to date.
Although the video of the squid monster sure was sick.

And yes I signed up for updates anyway!

 

The other ones, perhaps. But I can give you a guarantee that I am not, because I don't really have enough time to spare for that and because I have a mindset of a "maker" and not that of a "gamer" which means I couldn't break the game as creatively as people who alpha-test and beta-test should try to break it.

I wouldn't complain if they asked me to help with that, honestly. But since there are people eager to do it I'm probably not on their list of volunteers because of the above.

 

Wow. Such excite. Beta!

I can almost guarantee I won't get in, at least not around the start, but it makes me happy to think there will be some blessed (blesséd?) people enjoying the game at some point. Very hopeful about it though!

I've been kind of ranting to my friends about this game for the last "x" months, with very limited response. However, now that the trailer and website is out, I've manage to convince them that it's exciting, and to sign up for beta as well. They're probably bored of my excitement, but whatever!
Praise be to Quag'goroth!

 

People who make things for games, be it in-game resources (The fiddly bits we the player get the mess around with), writing or programing/coding often make terrible testers, especially of their own product. There are two main reasons for this I believe. The first is the ever-popular adage, "I am my own worst critic." It is very true that people often criticize their own work harsher than they would anyone else's, trying to bring it as close to perfect as possible. They will see flaws or blemishes where no one else does and have to correct them right away, in more extreme case scrapping a project entirely and starting over. This creates a cycle of endless overcorrection until the final product is a distorted facsimile of what it should have been. The second reason is the creators often find it hard to push a product to its limits. They know the rules that a product is supposed to follow and they test to those rules, usually failing to catch the many outliers that a customer invariably finds because of their lack of intimate knowledge.

These dont just pertain to video games either. I've probably alpha or beta tested a hundred or so games in my day but I've tested thousands of pieces of software and hardware. You need someone who can not only think like a tester (if I apply pressure here will it break? Where are my notes?) But also someone who can think like a customer (hurp durp hurp durp *break*)

 

Pretty much that.

Albeit I'm wondering, did you mean for your text to change font size like that or is it an unfortunate accident we aren't to speak of?

 

This is true not just in games programming. I was a programmer and systems analyst for many years, and while a programmer ought to do SOME testing before he puts it into the hands of someone else, he's certainly not the best person to do the testing.

Based on my experience: back when I was a young, and fairly new programmer, I was asked to test an actuarial program that was to be used in the field by insurance salesmen to illustrate/project life insurance cash values, death benefits, etc. for specific insurance products going forward in time, based on a widely adjustable set of assumptions and inputs. While I was a programmer, with good math skills, I had virtually no knowledge of actuarial equations and so on. I knew enough of the lingo, but didn't have a great understanding of it. Which, as it turned out, made me a perfect tester.

Anyway, in almost no time at all, I came forward and mentioned that with the inputs I was using, that the resulting numbers were getting incredibly huge to the point that the illustrations could not fit on a formatted 132-character report and be readable. The actuaries looked at my report and laughed and said 'no one in his right mind would use such inputs'. So the problem stayed unresolved. The product was sent out as-is to the clients.

Not 3 days later, we got a phone call complaining about the exact problem that I had noticed. It turned out that the insurance company that had paid for the program was using the insurance product to fund the building of a nuclear power plant. In fact the numbers that I had used for testing were quite conservative compared with the ones that the insurance company had intended to use in reality.

When you test, sometimes the less you know about the program you are testing, the better.

 

That is really interesting!

I actually work in the insurance industry...and I often think I have just the opposite problem. Our software seems like it never gets polished and so all the little things add up to make the software downright frustrating. In testing they can shrug it off..because that is all they are doing.

 

A mistake, the sort that happens when you are using your phone to post because you are sitting in a doctor's office waiting for an appointment.

 

Sorry about the temporary hijack (and I promise to return you to your regularly scheduled discussion). But I just want to add that my story has nothing to do with the polish (or lack of it) that the programs actually had. Part of the problem was that they let the actuaries program, and the other part was that deadlines came out of fantasy land, so even though most PROGRAMMERS (as opposed to the Actuaries), would have liked to rewrite just about everything from scratch, we were mostly tasked with program conversions (from VAX to PC), adding a UI, and putting bandaids on spaghetti code, and dealing with a whole lot of last minute, no-time-to-test change requests from Actuarial and/or Accounting (and sometimes Legal). Usually they would result in dumb errors like division by zero when the month changed, or really stupid calculation and rounding errors put to the 12th power (no joke) causing your calculations to blow up, and so on. (Omg, that I practically blew up the printer trying to produce proof to my boss that the reasons why the numbers were off by factors of 10 or more was because of a rounding error at like the 6th or 7th decimal place because of the stupid way of storing monthly actuarial tables and raising those numbers to the 12th power.

But back to the original topic. I just agree in principle, that it's always a good idea for other pairs of eyes to look at the code and to test, test, test. The more complex the code, the less likely the programmer will have thought of everything that could go wrong.

 

Dammit Haldurson, stop having interesting off-topic anecdotes

 

It gets worse when they aren't the original programmer working on an older block of code either. Especially when the notes in that random shorthand that programmers use for themselves that is completely incomprehensible to the rest of us, especially us in the test lab, trying to figure out just what the heck this dang thing is supposed to be doing!

 

I noticed in the latest screenshots that the steamer landing boats have no means to pilot them. How do they steer and operate them?

 

They don't. All destinations are chosen by Quag'garoth.

 

There's a colonist clinging to the bottom to manually steer, as the chief engineer has developed an irrational fear of rudders.

 

Looking at the older blogs it looks like it's going to be a running gag with machines not having little means or no way at all to steer or control them. The paddle boat, the steam lorry with only two levers for control in the driver's seat. I am ok with this now.

Also Quag'garoth never went to driving school, I wouldn't trust his abilities there.

 

But then again, you know, Titanic had controls and it didn't help it. So why would the little boats need any sort of controls?

 

if anything, not having controls at all would've saved the Titanic

 

Exactly! That is why none of the little boaties will have controls.

 

I just assumed that they were all controlled by enslaved frog people, the unholy spawn of Quag'Gorath, swimming with the boats strapped to their back.

 

Maybe they're not water-boats, but sentient-gelatinous-blob-boats, riding the ripples wherever Blob'Gorath pleases.