Starlight.jl – A game engine written in Julia
github.com
github.com
> Where did the maintainer get so much money for bounties?
> He didn't. He is taking a calculated risk that 1) being in debt to contributors is better than being in debt to, say, a credit card company and 2) that the rate of issue resolution will not exceed his income. Note that this means you may not get paid immediately. But on our honor, you will get paid.
The author is a grad student, I hope he does not find a few of those $5k bugs knocked out in a month by hungry devs!
So they have the opportunity to control how much bounty is actually “out there” at any given moment, beyond simply a posting the list of bounties in existence. If it’s too many bounties closing at the same time, or more total payout than they’re willing to accept, they’ve given themselves enough control to manage it.
Of course, this requires them to manage it effectively but it’s not fundamentally a bad idea
Edit: it seems like a large chunk of the read me is dedicated to this. Seems weird. I don’t think the author is trying to be deceptive; really the opposite, but it doesn’t seem like it’s a good project to get involved in for bounties. More importantly There’s just not enough information on the product itself. I presume it’s just new.
The bounties are also curious; the contributing.md doc has a $100 bounty with no real definition to what it is; I’m guessing part of the bounty is to define what it really should be, but it looks like the bounty system has been applied without fully thinking through the process of what exactly constitutes a bounty (or the corresponding value to a bounty)… probably because money isn’t really on the table
If you added some Agents.jl integration, it could become a killer backend for ABM (Agent Based Modelling), maybe better than Agents.jl's CairoMakie backend. But of course simulations are not games (or at least until a Twitch stream starts playing with it)
Thanks for creating and participating in this thread, there's a lot of valuable information for me here in the form of y'all's thoughts and opinions.
I thought I'd make an appearance and address some of the questions and concerns that have been raised here.
With respect to actual money being on the table and my ability to pay, not only is actual money on the table but I have already paid out more than $1000 USD in bounties to different contributors. Conceptually the bit about not being able to pay immediately boils down to "potential paying issues are infinite but my resources are not". So far I haven't had to deal with a contract being completed and not having the money to pay immediately, but if that situation were to arise (and as the project grows the probability that it will occur increases), my approach would be to put away a portion of my paycheck each month to save up to pay the bounty. If this happened with multiple bounties at once, I'd pay them in order by date of completion.
With respect to the proposal/approval system, this is something I came up with chiefly in order to prevent a "Wild West" scenario with different contributors competing for the same bounty. Not only does this eliminate that concern but it helps me establish relationships with contributors that in turn help ensure that quality work is done.
With respect to the quality of work I expect, yes I do reserve the right not to pay for contributions I don't like, even given a completed proposal and months of work invested. That's a worst-case scenario, but theoretically it could happen. It would be conceptually equivalent to, say, firing someone, or terminating a contract on a dedicated freelancing site like Upwork. Yeah that's a lot of power in my hands, but the open-source nature of this project ensures some accountability. If I treat people badly (and especially if I decide to use their work anyway) I risk losing contributors, and in the worst case I risk a fork under new leadership. In order to maintain a good project I have to maintain a good community, and whether I like it or not, that means I have a reputation to uphold. Which reminds me that eventually I'll need to establish community standards at some point. Right now I'm just ripping off Julia's. I may create a bounty issue for that, who knows.
With respect to some of the bounty issues not being well-defined, the answer is yes, whoever said that part of the point of proposals is helping me define issues was absolutely correct. This is especially true for things like the CONTRIBUTING.md, where fully defining the problem is tantamount to writing the actual document. Figuring out what makes an acceptable proposal is a tricky balancing act that I have to manage.
With respect to how value is assigned to bounties, unfortunately that is in fact somewhat arbitrary. Basing it on a combination of experience and man-hours required would look better on paper but ultimately not be much less arbitrary, especially given my own relative lack of experience. If anyone would like to offer a solution, I'm all ears.
With respect to Starlight's uniqueness and value, as well as Julia's suitability for game programming, that's something I'm still exploring. This project came about as a result of me trying to write graphics applications in Python and wondering whether a faster language with native matrices might be a better fit. Enter Julia. I'm with y'all in questioning some of its core paradigms, especially as a fan of Python's approach to OO programming, but so far I've found that working "with" Julia rather than "around" or "against" it tends to get better results than I could have achieved in a different language. All of that is to say that the sales pitch is something I'm still working on.
The ultimate motivation though is that I just like Julia and want to be able to make games with Julia. Just about every other major programming language has a major game programming toolkit available, why not Julia? Simply because no one's done it yet. I wanted Starlight.jl to exist but it didn't yet, so I decided to build it myself.
To be clear, I am not here to involved in any flame wars about language design. The answer to the question of "why Julia" is essentially "because no one's tried it yet". GameZero is a highly-simplified engine for students and teachers, so that doesn't really count. And AFAIK Gloria is not actively maintained, so it doesn't count either. Meanwhile the answer to the question of "is Julia ready" is "it doesn't matter because any work we do has the potential to influence the course of its development anyway".
See the repo for information on how to get in touch with me. I'm happy to talk "offline" about this.
P.S. Unity has been described as "a C++ engine with a .NET layer". Starlight is a C++ engine with a Julia layer, where the C++ engine is its own open-source project being developed in parallel by yours truly. It's called Telescope. If anyone's interested I can post more details about it.
P.P.S. The Agents thing is a good idea. I'm still deciding whether to go with Agents or Actors. Maybe we could use both? Either way the best thing to do is create an issue for it. :)
Julia is a fine language, but it's really not made for games... I feel bad they are paying people what sounds like more than they can afford to work on this. I hope it works out for them...
I’ve found it strange that so many people prefer it to Python, aside from performance magic. It seems so klunky to actually use.
what's the interface magic in Python? Class inheritance? I suppose you know that multi-dispatch is basically strictly more generic than Class-based OOP, so if you want to lock yourself down in Julia and have less composability that's always an option.
Multiple dispatch is a bad fit for most problems. It’s the hard truth many Julia users won’t swallow because LLVM can give them such good performance with such low programmer effort. I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch. It’s maddening. It’s the direct reason why so many Julia programs are unwieldy, and it leads to poor programming practices. I’ve seen plenty of mathematicians write shitty Python/Octave/R etc, I’m not saying that it can necessarily be prevented. Like I said, I’ve read a lot of shitty mathematician Python, and I can at least build the class hierarchy and transformations in my head and annotate my way to understanding. With Julia, I have to think multiplicatively about every call site because it could get called with a million different methods. It’s so annoying.
I don’t think Python will ever be half as fast as the fastest Julia programs, but that’s okay. A hell of a lot more games/products/everything has been shipped with it than ever will be with Julia 1.*
This is the purpose of the @which macro:
julia> @which diag(randn(3,3))
diag(A::AbstractMatrix) in LinearAlgebra at /opt/julia1.7.2/share/julia/stdlib/v1.7/LinearAlgebra/src/dense.jl:249
Because python is at least 3 decades old and julia is just a decade old. even python has a "hate" phase before it got widely adopted.
> With Julia, I have to think multiplicatively about every call site because it could get called with a million different methods. It’s so annoying.
whut?? are you saying this just to sound cool? because for me this is hilarious.
Pardon me if I don’t find your input valuable. I’ll check back with you in twenty years to see if you matter. ;)
I’m not sure what you mean by “sound cool” but you have a lot to learn. Julia’s types are not like templates or generics in other languages, they can basically fit into any method-shaped hole. So, at a call site, there’s no way for me to intuitively reason about the data at play, because some_method() can be literally anything. Combine that with a lack of interfaces, and it’s just mangled up code all over the place.
I’ve worked on codebases that stretch longer than my working career, I’ve worked on code where 100+ PhDs had left their mark in gnarly R/Matlab voodoo, I’ve worked on code that transacts hundreds of billions of tax dollars in a year, and much more.
Julia is a specialized tool for HPC, and the illusion that multiple dispatch without interfaces can be used to build reliable, understandable, engineerable systems will die as surely as the sun sets each night.
I’m not sure your background, and maybe HPC is your expertise or whatever. It seems like you need some better coworkers to learn from, or at least more variety in your intellectual diet.
It is, in my view, a fundamentally different programming paradigm that most of us have no previous built-up intuition for (unless perhaps you have spent lot of time with languages like Dylan or perhaps CLOS). But it is something you can learn and develop intuition for like anything else.
For those still learning, I may also mention `@edit`, which will not just show you the method, but take you directly to the source code of the method being called -- which is something that remains quite useful even when your intuition is fully-developed.
I totally get where you're coming from, as this is how I felt when I started out exploring Julia code. In previous languages, I preferred to use the simple tools I was familiar with (my editor and ack/ag/rg) to explore code, but that workflow was a frustrating no-go in Julia. The usual alternative in those languages was to change my entire coding experience with an IDE, or to accept some (slight) additional complexity with things like ctags. In Julia, neither of those is necessary, as the inbuilt tools like @which, @edit, methods(), and methodswith() do a good job of providing a non-intrusive, simple alternate set of tools. (Shoutout to the InteractiveCodeSearch.jl package too, which provides a nice interactive interface over these that sometimes comes in handy.)
Now, generated functions and @eval-ed functions, those are a bane of readability when you're new to the code. Thankfully, those are rare enough and usually in deep enough parts of the code that this does not pose a significant problem.
Which is strictly less powerful than creating a subtype...
what is this claim based on? hearsay?
> I’ve read some Julia source and its an awful experience trying to figure out what method is actually going to get executed because of multiple dispatch.
how is that difficult? you need to elaborate on that because having to "figure out" means you didn't really use Julia enough
Technically, you don't need to keep that in your head :-) The general approach is to define generic functions and also write docs about how to extend those functions to satisfy interface requirements.
Perhaps not too surprisingly, many of the Julia community people also want to have some official interface support directly from the language. Before that, several open-source projects were spawned to address that gap e.g. here is a shameless plug about my package:
Protocols. Though, yes, you can also use class inheritance.
> I suppose you know that multi-dispatch is basically strictly more generic than Class-based OOP,
Python is flexible enough that multiple dispatch can be done as a library without being a language feature.
So using a library to add multiple dispatch to Python is fair game but using one of the various Traits library in Julia to enforce interfaces isn't ? Why ?