COG unfortunate experiences?


#1

Ever played a COG that was just TERRIBLE? Have you ever been infuriated by some idiot in the comments? Ever majorly screwed up on a COG game that you made or maybe lost progress on the coding?

Share these utter tales of crappyness please.


#2

Rise of heros sucked donkey kong balls


#3

“Infuriated by some idiot in the comments” – no thank you. Ragging on published games is fair play (although really, do we need another thread about it?), but keep it civil when it comes to commenters.


#4

I think many of the “Hosted Games” are more fun and certainly a better value for money; some of the latest official games just don’t have the spark that dragon, broadsides, romance and vampire did. Probably because it’s outside authors, not Adam/Dan/Jason.
But yeah, that’s my only gripe really.
I guess my suggestion is, make it hosted/official based on game quality, not author experience.
Oh and we could do with a select few more commands in choicescript, *goto_sceneref for e.g.


#5

@Harlox, I intensely disliked Heroes Rise because of the way it railroads you into behaving stupidly to justify its heavily contrived plot, but I’ve already griped about that elsewhere in this forum.

@CJW Yep, I’d dearly love to see arrays added to choicescript, and I’d also really like to be able to use curly braces in more types of statements, like in printable ones.


#6

I don’t like rise too but the worse are the faerie game is horrible!
also what gripe mean in English in Spanish mean flu so I’m confused :confused:


#7

To the City of the Clouds was just ghastly, and The Fleet was too blunt.
@MaraJade A ‘Gripe’ is a complaint, effectively.


#8

I don’t like the forum software… but I think noone does.

And I don’t like how clumsy many games handle sexuality.


#9

@loelet - Good point, the forum software could do with an upgrade or a replacement, but I guess it’s far from a top priority for them :stuck_out_tongue:

@P_Tigras Oh, yes… Well, I could literally go on for hours about new features/commands I’d like.

I just today forked/made a pull-request for the *goto_sceneref - it took me all of five lines and four minutes to do and seems to work perfectly, I don’t understand why things like that were excluded. You’d think there was a special reason - and there might be - though if there is, it beats me.

As for arrays, you can actually simulate them (or well, objects) with *setref and *gotoref etc (I do this in the inventory system) - so I can live without them for now. Don’t get me wrong, I’d like to see them, but I did look at it myself and it wouldn’t be a ten minute task, so I can understand their absence thus far.

What would be nice is an official command for creating dynamic variables during gameplay… As it stands any *systems* are limited to the amount of variables you pre-define, without the use of *script.

Your comment about curly braces intrigues me, could you expand on that? I’ve never been in a situation where I’ve wanted to use them that I can’t.


#10

Heroes Rise: Chugga-chugga-chugga-chugga-CHOO-CHOO!

City in the Clouds: Way, way too immature and full of random, brainless sex (and that was just the demo).

Also, I agree with the problem with the forum software. Specifically, it puts all the posts in all the various categories together on the front page, cluttering stuff up and making it impossible to sequester the random spam from the actually valuable posts (and because off-topic posts aren’t segregated, this encourages random spamming everywhere as a part of the forum culture, so people take the excuse to start threadcrapping in threads where actual work is being done).

Can’t we adopt something like phpbb?


#11

@MaraJade: As @Drazen has explained, gripe is a synonym for complain.

@CJW: I’m not sure if you realize it, but you answered your own inquiry regarding curly braces. If we could use curly braces in a *temp statement, we would then be able to create dynamic variables via a loop. Currently, it’s fully possible to construct a string dynamically via ‘&’ and to indirectly reference it via curly braces. What we lack is a way to make that string a variable name. If *temp {newtempvar} were to work, we would be able to use loops to dynamically generate as many variables as we need, and this particularly annoying issue would be solved.

@Ramidel, @Drazen: I didn’t care for City in the Clouds either. I was one of the beta-testers and just couldn’t bring myself to finish it. At least I finished Heroes Rise, although my feelings for CitC were more along the lines of apathy than the anger I felt towards Heroes Rise. And that in a lot of ways is worse. The problem with HR is that it succeeded in making me care, and then chained me to my seat as my character did one stupid thing after another against my will. The fury I felt toward HR after it railroaded me is unique and unmatched by anything else here.


#12

I don’t like that Hosted Games are hidden on the frontpage behind a link called “Make your own games”.


#13

@P_Tigras

This would be easier, it doesn’t use {} but rather just works like *set_ref, only with variable creation.

E.g.
ChoiceScript


*temp new_variable
*set new_variable "foo"
*temp_ref new_variable
*setref new_variable "I'm the value of a variable that was set and created dynamically!"
${foo}

Scene.js Function


Scene.prototype.temp_ref = function temp_ref(variable) {
    var stack = this.tokenizeExpr(variable);
    var reference = this.evaluateValueToken(stack.shift(), stack);
    this.temps[reference] = null;
}

You’d also need to add “temp_ref”:1 to Scene.validCommands object at the bottom of the file.

…If it’s this easy to do though, why hasn’t it been done? I really want to know, there must be a reason, right? :expressionless:

@loelet I think Jason already said something on that in another thread last year, suffice to say, they don’t plan on changing it, but I see exactly where you’re coming from.


#14

@CJW I most definitely agree that there should be a way to do this, and I was just as surprised as you that there isn’t. I’m undecided on whether or not a new *tempref function is the optimal solution however, but I do grant that it would be a little more straightforward than coding *temp to handle both ${} and {} since it would just be a matter of reusing a bunch of functions that have already been created.

I do have some concerns regarding the overall temp_ref function you listed above however. The first is that it does not call validateVariable to ensure that the variable it is attempting to create is legal. So no error message will be generated when an attempt to create it fails. The second has to do with the relative merits of calling evaluateValueToken as your code above does, versus calling evaluateExpr instead as *set and *setref do, although *setref does call both. I’m undecided regarding this second issue however. evaluateValueToken often calls evaluateExpr while evaluateExpr always calls evaluateValueToken so that bit of cross-pollination obscures things a bit and I haven’t spent enough time tracing them both through to form a definite opinion. I’m thus interested in knowing if you considered using evaluateExpr instead, and if so, what your reasoning was for picking evaluateValueToken over evaluateExpr.


#15

@loelet This is my pet peeve too. I think another tab between Our Games and Blog called Hosted Games would be wonderful. The intentional hiding of the Hosted Games under Make Your Own games seems like a real shame.


#16

@P_Tigras You have a good eye… That is the bare minimum code that will *work*, as I just threw it together in five minutes (to prove that it’s not particularly difficult to implement).

I completely forgot to include any checks or error catches (shame on me).
Validation of the variable - at the least - should definitely be included.

As for evaluateExpr - it does exactly what it says on the tin, it evaluates an expression.
An Expression: A collection of symbols that jointly express a quantity.

*set var (5+10)
^That involves an expression

*temp_ref foo
^That doesn’t - and can’t - all you can specify is a single value.
There is never any expression to evaluate.

evaluateValueToken “turns a number, string, or var token into its value”
Though you may notice if the string or token involves parenthesis, it will pass on the value to evaluateExpr… ;D

– I understand this might sound like a poor explanation, especially when you look at the use “tokenizeExpr” <- Obviously there is an expression here.

“*temp variable” is, in itself, an expression. Once evaluated the command PLUS the value will equal a quantity (the new variable in this case). I’m sorry if this isn’t clear, I’m not particularly great at explaining these things.

Remember that *set and *setref ‘set’ variables and *temp creates variables, so it’s not a particularly good comparison!

*set involves two values: The variable to be set + The value it’s being set to.
*temp involves one value: The name of the variable being created.

Version of *temp_ref with var validation:


Scene.prototype.temp_ref = function temp_ref(variable) {
    var stack = this.tokenizeExpr(variable);
    var reference = this.evaluateValueToken(stack.shift(), stack);
    try {
      this.validateVariable(reference);
    } catch (e) {
        throw new Error(e.message);
    }
    this.temps[reference] = null;
};


#17

@CJW I can think of situations however where it is both convenient and efficient to create a variable from an expression. I very much want to be able to do things in choicescript like:


tempref "inv"&(1+currentInvSize)

So as long as it’s a legal variable name that is generated by the expression, I consider expression evaluation a desired ability. And as far as illegal variables like 15 (5+10 in your previous example) are concerned, that’s what validateVariable is for. Furthermore, evaluateExpr does allow for situations where there is only a single argument such as in a simple *if statement. So it is quite a bit more flexible than the manner in which it is used in *set and *setref.

Regarding the added try…catch, validateVariable already throws an error message internally which breaks out of the game, so it seems a bit redundant to add another.


#18

*set pointer “inv”&(1+currentInvSize)
*temp_ref pointer

Would work.

I understand the desire to combine the commands, but it’s only an extra line.

And yes, you’re right, it does. Though having multiple error catches isn’t a bad thing in my opinion.