by swannodette on 12/19/16, 11:30 PM with 76 comments
by reitzensteinm on 12/20/16, 12:42 AM
I would be very concerned about straying too far from the garden path while also trying to ship a commercial game.
Unity's GC isn't even generational, a very bad mix with garbage heavy Clojure code. Expect confusing, bizarre and transient performance and memory use issues. Debugging will be a nightmare.
And on top of that, Stack Overflow doesn't have an unlimited supply of Clojure JVM answers; Clojure .Net through IL2CPP? Forget it; you'll have to figure everything out yourself.
It's generally a mistake to make the initial development more pleasant at the expense of long term maintainability; and I think that's the trade off on the table here.
by spacepluk on 12/20/16, 7:05 PM
I'm one of the programmers at Mooi Studios. We intentionally avoided being very specific in the article because we were expecting some skepticism :) Because of this it might sound like we made this decision without putting any thought into it, and that's not the case at all.
I don't want to argue about what is the best tool for the job, because honestly I don't think anyone can say something like that and be 100% certain about it. All I can say is that I've tried those tools before, and I'm pretty sure I don't want to write software that way anymore.
We are aware of the challenges, and we know that using C# would be easier in some ways. But enjoying what we do is a big deal for us, and we're willing to do some extra work to get there.
Ultimately, whether our games succeed or not has little to do with the technologies we use. I just finished Hyper Light Drifter which is probably one of my favourite games of all time, and they made that with Game Maker.
Anyways, for now we're only using Clojure to replace C# for game scripting. We're not writing a full game engine or anything with it (yet, hehe). We believe the differences in performance for these purposes should be neglible, and initial testing seems to confirm that. The gains in simplicity and workflow are real and are huge. And most importantly we're enjoying every minute of it.
Cheers,
by seanparsons on 12/20/16, 12:19 AM
Now if I could use Haskell in Unity3D then I'd get hella excited, but there's a lot more barriers there methinks.
by everyone on 12/20/16, 2:59 AM
Can someone tell me do they think the practice described in the article is a good idea? (The writer says they are just learning so their opinion is not very valuable to me (When theyve cranked out a bunch of games on various platforms and encountered all kinds of horrible shit and overcome it, it would be more valuable to me))
I'm all too familiar with OO's many foibles and I'm interested in functional bur have never done any.
One thing I've heard though, is that OO is bad for most stuff except games. Where you actually have this world with all these entities composed of various objects going around in it about their business. Its does make sense to have a 'Cow' object that has state + methods to get it to do various things like 'moo'
Additional: Looked around a bit and the Arcadia repo says.. " Arcadia is alpha-quality software, and shouldn't be used for anything important yet. " I'm also try as hard a possible and use as much standard, vanilla Unity stuff as possible, as the more weird custom plugins and whatnot you use the more heartache you get when it comes to building and releasing + updates on a million damn phones or PC setups. Anything not standard has to justify its existence against very jarsh criteria.
I will download and mess with this though. I'm actually really excited to do some functional programming!!
by jheriko on 12/20/16, 1:07 AM
a long time ago i used to write code in something called 'AVS' for Winamp... it also let you modify code at run-time, but it was certainly not functional.
you can actually do the same things with C#... and unity does let you do it out of the box to some degree. there is no reason why that couldn't be further developed though.
by fatalogic on 12/20/16, 1:43 PM
Perhaps through their trials and tribulations they will gain the knowledge to aid in the development of Arcadia/ Clojure + Unity. I just feel like there is a lot of well meaning but discouraging comments here but I think people often forget the science part of computer science. Sometimes you just have to experiment and fail and experiment some more to push a paradigm farther.
I don't know how successful they will be with this approach and maybe they will end up ditching it but even if they fail the first time they have the opportunity to gain valuable experience.
by optionalparens on 12/20/16, 2:09 AM
Game programming like most programming largely requires choosing the right tools for the job. While I agree it is important to factor in the skills that you team has, the choice of Clojure + Unity + this write-up seems like retro-fitting for the wrong reasons. Regarding Clojure, I can appreciate what Arcadia is trying to do, but it seems like an odd choice for an unskilled game dev for anything but messing around/intellectual fun at this point. This is both because the software is quite honest and labels itself alpha, and because Clojure and Unity is not necessarily the best combination IMO for many reasons. The primary reason I'd contend this is because it is a huge pile of abstractions of abstractions with not enough payoff. Even just browsing Arcadia's source, I can also already see a few bits of code that aren't optimized as well as they could/should be for something like this. I can only hope the article author is not serious about pursuing a commercial quality game of significant complexity and power with this approach (i.e. not necessarily AAA level, but upper-tier indie).
As for functional programming in games, it is a big subject and an interesting one, not to mention a worthy pursuit. Indeed, huge amounts of the trends in game programming for the past two decades at least have been moving to functional paradigms. Entity systems are a great example of this. One way to think about Entity Systems in particular in relation to a functional language like Clojure is that it essentially allows you to think about your game state as a reduction of states (entities with attached components and systems operating on them) over time. Furthermore, as multi-core programming becomes more important, some of the constructs that make concurrent programming, or even parallel programming easier are commonly found in highly functional languages. Clojure is no exception and has many things are amazing to this end, but not all are necessarily useful in the context of a non-trivial game. There are many more things I could touch on, but suffice to say that programmers are bending over backwards to make C and C++ in particular, followed by C#, Java, Swift, and other languages behave like functional language. Ironically, I think part of the problem with most functional languages is that people are pulled from the other end and forced to make these languages behave like C++ to get acceptable performance and other traits.
Despite many OO/imperative languages used in game dev moving towards more functional trends, the promises, power, and tools that most of these languages provide are vital. There are too many reasons to list (some good, some bad) why C and C++ are still dominant in this world for serious game dev work, but a few include existing tooling, full control of memory, ability to work around language induced performance roadblocks, possibility of portability, optimization per platform if required, bountiful workforce, and low-level integration points with hardware, SDKs, and tools. That's not to say other languages don't have these things, but rather they have some critical flaws in some of these areas that make life harder than it needs to be at the cost of actually getting a game completed, which in the end is one of the most important things.
I know it's frowned upon, but I'm splitting this rather large comment into two parts.
by Maultasche on 12/20/16, 11:50 PM
From what I understand, functional programming usually avoids side effects, so mutable data structures are replaced by immutable data structures. So instead of modifying an existing data structure, a new data structure is created containing the modification.
So how does this work with games? When you modify the game state, is the entire thing copied into a new game state? Doesn't that really slow the game down when the game state is large and changes are frequent? Is there some trick to this that avoids unnecessary copying?
by agounaris on 12/20/16, 12:18 PM
It's kinda of sad when people treat functional programming not as paradigm but as a solution to their problems. Sometimes I feel that they think they will let all of the bugs, design decisions etc just go away, only by using FP.
by automatwon on 12/20/16, 5:25 AM
I don't know if functional program is SIMPLE as much as it is CONCISE.
I didn't see the word monad, fold, or reduce anywhere in the article. Is a functional programming language used with side effects and all? There's no acknowledgment of scenarios where managing the state the functional way can be unnatural, and require an intellectual hop. Or, alternatively, that this game in particular lends itself more naturally to the functional paradigm.
by AdeptusAquinas on 12/20/16, 12:45 AM
Biggest problem with Unity and C# is the delay in adopting the latest language version - last time I checked Unity was C# 5, not 6. Hopefully Unity adopts .NET Core soon, getting around this problem.
by throwaway7645 on 12/20/16, 12:03 AM
by SomeStupidPoint on 12/20/16, 12:03 AM
That said, Im a big fan of functional languages for game scripts (and got in to that myself using LISP on text MUDs).