Hacker News new | ask | show | jobs
by smcin 868 days ago
You're using Typescript+CSS. Was hoping you'd support Python on the server, for game logic. Your timing is good because developers and publishers currently using BGA are unsettled and spooked by Asmodee's business model.

BGA Studio's stack is JS/CSS + PHP (client and server) + MySQL [0]

Yucata.de is JS + HTML + .NET 4.5 on the server [1]

(TTS was using Lua, which I looked into but seemed eccentric and limited, it's not even OO, why on earth choose a non-OO language for a boardgame).

Also here's a useful review of sites/frameworks from 2021: "VassalEngine: Survey of other boardgame software" [2]

Can you please please please integrate with Python on the server?

[0]: https://boardgamearena.com/doc/Studio

[1]: https://www.yucata.de/en/FAQ#t17

[2]: https://forum.vassalengine.org/t/survey-of-other-boardgame-s...

5 comments

> why on earth choose a non-OO language for a boardgame

Lua has usually been a very popular choice for game developers. One reason is that it gives you an easy way to embed a scripting language in your game.

You can do OOP without classes [0].

> Can you please please please integrate with Python on the server?

You expect the developer to port and maintain their entire project to Python because you can't be bothered to learn a new programming language?

[0]: https://en.wikipedia.org/wiki/Lua_(programming_language)#Obj...

>> > Can you please please please integrate with Python on the server?

> You expect the developer to port and maintain their entire project to Python because you can't be bothered to learn a new programming language?

They are literally begging, 3 "pleases", rather than "expecting".

I remember a book on the shelf at home in the 90's entitled "Object Oriented Programming in Macro Assembler".

And indeed, C has function pointers, so you can do OO. Just not some of the more fun stuff.

I clearly didn't "expect" the developer to port or do anything, I requested they consider also integrating with a (server-side) language that's in general more widespread, more expressive, more userbase, more libraries, more powerful developer tools. Per the examples I cited, boardgame platforms put most of the game logic on server-side, for complex games. The client-side checks that moves are not illegal, cheating or nonsensical.

I wasn't aware Lua had become widespread in game programming [0] (or more specifically, scripting on top of a game engine written in some other language); but supposedly not mainly due to whether Lua language has adequate features, but in part as a reaction to (client) performance of the Lua VM vs Python (VM maps to register set rather than stack-based; lower memory usage; coroutines); on client rather than on server. Some discussion in [0].

I did in fact in 2020 look into implementing a friend's boardgame in Lua on TTS vs in Python. That programming only confirmed my experience that line-for-line, Python is more expressive, IME more productive to develop in, also has much stronger library support.

Why is the basic documentation [1] on whether/how to implement OO Lua so contradictory and all over the place? When I look for a how-to document, I want a clear how-to, I don't want to see Lua's own users in a decades-long debate [2][3][4][5][6]. Or [7]. Or a lua-users.org/wiki that isn't even accessible via https [8]. (If I should be using a more accurate term than "OO", then just tell me what that is, instead of ad-hominems.) So for example, do we need polymorphism, mixins, the ability to call super, serialization (probably can do without that), etc. Should we sacrifice other features for more deterministic GC and performance? What are the compelling reasons for server-side Lua? on a feature-by-feature basis vs say Python?

(There's also a constituency who insist that Tcl is object-oriented, FWIW.)

Probably the best way to keep this discussion on-focus is to define "What is the consensus on an adequate set of OO features that's considered necessary for server-side game logic programming?" (that's a rational discussion, not "can't be bothered to", which is just ad-hominem).

As to TS, in my experience I don't find strong type-checking to prevent that many bugs, in codebases written by a small number of developers. I can program JS, so again if I saw a compelling reason to start using TS I would. (Sure, you could also crosscompile Python.) Again, that's not the primary issue, the primary issue is what server-side language once the game becomes complex and outgrows a pure TS implementation.

[0]: "Civilization V ditching Python for Lua" https://www.reddit.com/r/programming/comments/bp5m8/civiliza...

[1]: https://www.lua.org/pil/16.html

[2]: How can one implement OO in Lua? https://stackoverflow.com/questions/4799078/how-can-one-impl...

[3]: Is doing OOP in Lua considered bad practice? https://www.reddit.com/r/lua/comments/tbaxlo/is_doing_oop_in...

[4]: Really, how best to give Lua an object/class structure? https://www.reddit.com/r/lua/comments/tia21g/really_how_best...

[5]: Is Lua an object-oriented language? (SO, 2011) https://stackoverflow.com/questions/3477676/is-lua-an-object...

[6]: Why inheritance isn't as useful in dynamic languages, and other notes on OO in Lua (marc.info) "In short: inheritance is in most cases not a feature, just a simplistic method for expressing similarity." https://news.ycombinator.com/item?id=98529

[7]: r/ProgrammingLanguages, 2022: "If Lua is faster and smaller than Python, while being just as powerful and capable, then why is Python so much more popular?" https://www.reddit.com/r/ProgrammingLanguages/comments/tfurk...

[8]: https://wiki.c2.com/?LuaUsersWiki

And a 2017 beginner tutorial "How to Make an RPG : Classes In Lua - Creating your own class system."

https://howtomakeanrpg.com/a/classes-in-lua.html

Also a prior 2021 HN discussion on Lua vs Python vs TS vs Tcl, viz. embedding in games:

"Lua: Good, Bad, and Ugly Parts" https://news.ycombinator.com/item?id=29659336

Seems pretty trivial to support Python serverside. Python is very easy to run in a lightweight isolated container (and you can compile it to static executable). The game data that the engine makes available to the server side code looks pretty standard and doesn't look like a huge shim to maintain.

You could even cross compile the Python to typescript for a simplified server side environment (typy for example).

>Seems pretty trivial to .....

Then go do it. If it's pretty trivial....

Anything is trivially easy when you aren't the person that has to do it.
The reason the server isn't in Python is because in boardzilla, you don't express your game twice, once for the client and once for the server. Instead, you express the game once in typescript, and that code is actually used on both the server and client. The client is operating a lot like the server, just without the hidden information.
What is your reason for wanting Python on the backend so strongly? TypeScript is a very logical choice given that it runs on backend and a wide variety of frontends (not only web, but game engines like Unity too). And its type system is better than Python's.
See reply above.
What is Asmodees business model and what does it have tondo with BGA?
Asmodee is hedgefund-owned French board game company. Drive by the injected money they have been 'consolidating' the board game publishing industry. For instance they bought the rights for Settler of Catan.

A lot of people fear that they will raise prices or reduce the offering to return money to the investors at some point.

Asmodee owns BGA, also owns a huge amount of game publishers. I have a decent collection and then looked at my games and noticed that Asmodee published like 70% of my games.

Just feels like we're reaching a point where if you want to get a game published at a larger scale and distributed, you'll likely really be incentivised to go through Asmodee.

there is nothing wrong with Typescript, but it is the react part that worries me. Wouldn't you want something more light weight on the front end than react for games? Like svelt, marko or solid?
The React aspects are really minimal, all the animation logic is by outside of React. We're really just using it for the jsx syntax to make it easier to return markup-looking components.
I get you, jsx is the most useful part about React. However, there is nanojsx now, which would be great to for mobile. React tend to push out large bundles. For example, MatterMost, it is great open source initiative, but the React front end often lags it quite a bit on older computers.