Get started exchanging ideas about knoh HOT 13 CLOSED

OK, I'll address your points in order:

• I've tried prototypes of this in JS, Lua (Löve) and C++. I've had different problems with each, and I've finally decided C++ is the best suited for me because the inflexibility of the language (or rather, the strictness), helps me establish the game logic better. I don't have prejudices against languages, I always choose what works best for me given the circumstances.
• I have no idea what temporal logic is. Sounds interesting, could you tell me more about it?
• This is an open-source clone of a freeware game that doesn't use any art, trademarks or code from the original. It cannot be argued that it could hurt Zachtronics in any way and is certainly within the law. Aside from that, I'd like to consider it a tribute, rather than anything else. I'm going assume trying to get a statement from them would do nothing more than bother them needlessly.
• I don't understand your point. This is a hobby for me and I don't intend to monetize it in any way, nor to approach it as anything different, as that would really defeat the purpose of a hobby.

Take a look at the code (or even compile yourself a build) and see what's in there. The basics of the UI are already functional, and I'll be working in the simulation logic next.

I have no problem in you working in your own Javascript project in parallel, or even you using the clumsy graphics I've made for your own purposes.

from knoh.

Yeah, great man! That's the kind of response I was hoping (or poking?) for!
So here we go:

I've tried prototypes of this in JS, Lua (Löve) and C++. I've had different problems with each, and I've finally decided C++ is the best suited for me because the inflexibility of the language (or rather, the strictness), helps me establish the game logic better. I don't have prejudices against languages, I always choose what works best for me given the circumstances.

Sure enough. Q is what are the circumstances? Entailing: what effort who's to put into it?
Anyways, so this tells me that statical typing is of real importance for you. Is it also having a class system built into the language? You mention JS and Lua which are both prototypal (as opposed to class-based) and dynamically-typed (NOT: weakly-typed; they're dynamically but nevertheless strongly typed).
From my experience, statical typing and / or classes do NOT really provide that much more safety and scalability as they (in school, university, mainstream) always tell you. It's much more a matter of being-used-to, and experience, than of the language itself.
So you've done some things in such languages (like I've done some things in C++) but not really "big" stuff (like I haven't in C++)? Correct?
Would you be willing to give a JS approach another try, say if I put up something to look at?
Btw: by Lua I mean that Brazilian thing. What did you mean by "Lua (Löve)"? Same thing or not?

I have no idea what temporal logic is. Sounds interesting, could you tell me more about it?

It is, and I will! Actually, that's my main point/idea in improving Kohctpryktop. It's moving from some fuzzy, statistical kind of verification to definite, precise specification of what the circuit is expected to do, down to the ticks level. Including the precise definition of allowed margins wrt timing (!). It's doable in principle, my endeavour here is to find out if it's practically applicable in a game like that (and see what size is manageable). Another challenge will be to find a way for users (fans) to create such specifications without having studied logic and without having to write crazy cryptic formulas - a challenge indeed.
Concretely, I'm thinking of CTL (computation tree logic), implemented using BDDs (binary decision diagrams).
(just to give you some starter, of course I'll be happy to go into a more detailed discussion)

This is an open-source clone of a freeware game that doesn't use any art, trademarks or code from the original. It cannot be argued that it could hurt Zachtronics in any way and is certainly within the law. Aside from that, I'd like to consider it a tribute, rather than anything else. I'm going assume trying to get a statement from them would do nothing more than bother them needlessly.

Hmm, you're probably right - "open-source clone of a freeware game"... But still, I'd really like to "have them in" in one way or another. Be it only to gain some publicity for our own thing here. Anyways, I'll put aside my qualms for now.

I don't understand your point. This is a hobby for me and I don't intend to monetize it in any way, nor to approach it as anything different, as that would really defeat the purpose of a hobby.

Hehe, I don't understand that either, sorry :) I do not and did not mean to monetize this in any way. Not sure which point of my post you're referring to. I do, however, want to approach it seriously and develop some software in a professional manner - which, for me, does not conflict at all with doing it as a hobby ;)

Take a look at the code (or even compile yourself a build) and see what's in there. The basics of the UI are already functional, and I'll be working in the simulation logic next.

I will, promised. Be prepared to be bothered with stupid newbie questions how to get things to work...

I have no problem in you working in your own Javascript project in parallel, or even you using the clumsy graphics I've made for your own purposes.

Yeah, but how much better would it be if we worked on the same thing in the same language together? Still not out of my reach. Yours?

from knoh.

Add-on re temporal logic (quoting myself):

[...] It's doable in principle, my endeavour here is to find out if it's practically applicable in a game like that (and see what size is manageable). [...]

In fact such or similar techniques have been employed in the hardware industry for a long time (> a decade for sure, maybe two). However, there's always the problem of state-space explosion. And putting timing into the equation makes it considerably worse. I know of some attempts of formalizing timing (ie not just "a before b", but rather "a before b in such and such a margin of some atomic time") but to my knowledge that's nothing like mainstream, yet...

from knoh.

I use Javascript in my day job for website development, so you could say I've done "big" things with it. Löve is a game development framework for Lua.

I generally feel more comfortable using Java, C/C++, C#, Objective-C and such when the project is open-ended because the highly structured nature of the language forces me to follow certain patterns even if I don't know when I'm going to end up.

Temporal logic sure sounds like something interesting, but how would it translate in terms of gameplay, specifically?

from knoh.

I use Javascript in my day job for website development, so you could say I've done "big" things with it. Löve is a game development framework for Lua.

Yep, answers my question. Thanks.

I generally feel more comfortable using Java, C/C++, C#, Objective-C and such when the project is open-ended because the highly structured nature of the language forces me to follow certain patterns even if I don't know when I'm going to end up.

Ok, I'm getting an idea. "Highly structured nature" - is it static typing or classes? Or is it the combination of the two that makes it suitable for you?
Then they're all in the C family, ie rather procedural, imperative. As opposed to functional. Is that also a a preference of yours?

Temporal logic sure sounds like something interesting, but how would it translate in terms of gameplay, specifically?

I'll have to think a bit more about how to best explain, you know. But I'll just try a start and hope that you'll tell me where I should go faster and where to add more detail.

Basically, it's about the verification part of the game, and the scoring. And it will allow for much improved feedback to the player. <- That's the tagline.

...

Well, right now I think it's better to open a separate issue for it :)

from knoh.

I feel very comfortable with static typing in particular. Classes are nice too.

from knoh.

Ok, I see. One last question on this (last one, promised):
In your JS, have you found yourself writing excessive

if (typeof arg0 !== 'string') { throw ... }

...or, maybe, someone had to tell you that you're doing so was excessive?

Plz forgive me my curiosity. It's about gauging each other's prefs and habits. I, personally, value patterns (you mentioned them already). I do not, however, appreciate so much being forced. I know it's a trade-off. And when it comes to collaboration some "outside forces" can actually simplify things, I know that too.

from knoh.

I've never abused typeof. In fact, I rarely use it in Javascript. I like static typing, and when I need it or want it I use a statically typed language. When I work with a dynamically typed language I use a style that is consistent with that, I don't try to force the language to behave in a way it was not designed to behave.

from knoh.

Ok then. Thanks for your patience :)

from knoh.

Ay, too sorry. But I have to ask:

Which of the features of C++ are you explicitly refusing to use?

I mean just the first that come to your mind right away, and of which you can honestly say that you know - and can explain - why they must be avoided.
If there aren't any such then that's fine, too. Plz just be honest and straight.

from knoh.

I'm not sure I understand. I'm all right with any and all of C++. I'm not saying that I'm aware of everything it has to offer, but I don't feel there's anything there that I would refuse to use.

from knoh.

Ok fine, thanks.

from knoh.

Feel free to re-open and ask any general questions that you might have about me or my way of approaching things (in case they're not worth a separate issue).

from knoh.