09:11 <Nistur> mornin'

09:25 <beneroth> Hi Repper Nistur

09:25 <beneroth> this is a repler hood

09:25 <beneroth> you better be interactive

09:31 <Nistur> so, for our game's backend, we're starting off using GameSparks... but we're intending to replace that in March-ish time with a home rolled system, technology TBD... I suggested lisp but it didn't get a particularly positive response :'(

09:35 <beneroth> [OT] security audit of protonmail: https://eprint.iacr.org/2018/1121.pdf ping rick42 ping tankf33der

09:35 <tankf33der> beneroth: yea, read

09:36 <beneroth> Nistur, ah this. I saw this before. Didn't consider it serious for programmers or something bigger than small games...

09:36 <beneroth> Nistur, tell me about it, when you know something about it :)

09:38 <Nistur> beneroth: GameSparks is used for a lot of mobile games. I can give you at last... 5 I think games of reasonable size which use it

09:38 <Nistur> it's by far a perfect system, but it DOES mean that you don't have to write a lot of boilerplate yourself

09:39 <beneroth> aye, fits my expectations :)

09:40 <beneroth> reminds me of the old hobby gamedev joke: do you want to write a game or a game engine? :)

09:40 <Nistur> the answer is, of course: yes

09:41 <beneroth> so true!

09:42 <Nistur> but it looks like we will be rolling a custom node.js solution after softlaunch to replace GameSparks, so we can re-use the majority of our backend code. I thought this was likely, but there was always a TINY hope that I could persuade people to use (pico?)lisp :P

09:43 <Nistur> if it wasn't for how busy work is getting now, I would consider seeing if I could roll my own solution in my free time

09:47 <beneroth> argh node.js

09:47 <beneroth> suddenly GameSparks looks like the best technical solution

09:48 <beneroth> NPM is cannot be trusted. Node.js is a mess with many holes. :(

09:48 <Nistur> GameSparks uses node.js :P

09:48 <beneroth> argh

09:49 <Nistur> so yeah, not _overly_ keen on that, but we have looked for a better solution that would give us what we want in the (very) short time we have

09:49 <Nistur> after March we will move away from GameSparks, and the tech is still TBD, but if we have a sizable codebase in node.js... it does sort of make sense to keep with it...

09:50 <Nistur> although we've had recommendations of Java and C#... but they would obviously require a lot more re-writing

09:51 <beneroth> unopotimized node.js is probably even more performant than unoptimized Java/C#.. I would believe

09:51 <beneroth> why move away from GameSparks?

09:52 <Nistur> it doesn't give us as much flexibility as we need, there are a few features, such as player generated content, which are difficult to do, when there are problems, they are slow to fix them...

09:54 <beneroth> how much did GameSparks invest (time,money,people) into creating their thing? why do you believe you can do the same + additional stuff with less - nevertheless also rewritting probably a lot of the code interacting with the engine anew for your new system.

09:55 <beneroth> maybe your business deciders have good arguments for that point. maybe.

09:58 <Nistur> beneroth: we're working with another studio who have made a couple of similar games. They have evaluated GS in the past, but opted for writing their own systems (in Java, which is why that was suggested)

09:59 <beneroth> the main benefit of Java is that it's rather easy to find programmers for it, imho

10:00 <beneroth> the JVM has some merits. Clojure and Clojure-Script (compiles to JS) on top of java runtime might be something worthwhile for that use case. you could use datomic as distribute backend database.

10:06 <beneroth> talking your shop crowd into picolisp is probably not even worth to try. and a scalable game backend is not a tested use case for picolisp. My end-goal something like that, but I would expect some scaling issues when purely using picolisp - can surely be solved by good architecture, but there is nowhere much prior experience to build upon for this use case. also, the main power sof picolisp are quickness of development and high maintainability, not pure pe

10:06 <beneroth> rformance, so maybe a mix of picolisp (e.g. for game logic, validations in pilog, etc) and other software (for connection pooling/processing, scaling on demand) might make more sense.

10:06 <beneroth> with other lisps its another picture again, obviously

10:09 <Nistur> yeah, I don't think the picolisp suggestion was actually ever a real one :P I like the idea of course

10:10 <Nistur> but yes, getting lisp programmers of any flavour is difficult I believe, especially ones interested in the long hours, low pay of gamedev :P

10:11 <beneroth> for now I decided to work on the app/game engine based on picolisp instead of writting a game :)

10:12 <beneroth> hm, well the guys interested in gamedev are mostly people more interested in interesting work than good (or even fair) compensation. and I would guess there is a big overlap with lispers in that :D

10:12 <beneroth> so with some luck you could get better programmers just by attracting lispers :)

10:26 <Nistur> :P

14:51 <viaken> Nistur: Godot?

14:52 <Nistur> viaken: ?

14:53 <beneroth> viaken, Godot is a game engine / game builder, not a server backend for a online game.

14:53 <viaken> Oh, I missed the use case apparently.

14:54 <viaken> Don't mind me. Clueless as usual. :)

14:58 <beneroth> np

14:59 <Nistur> clueless is apparently my middle name these days :D

15:02 <beneroth> if you know this you definitely have a clue

15:02 <beneroth> :P