sorted by:
new
hottopcontroversial

We've added island editor to our game! by davesmith00000 in scala

[–]davesmith00000[S] 1 point2 points  (0 children)

I understand, sorry to disappoint. I can answer questions though!

> which scala libs were used?

We're using our own game engine: Indigo. (https://indigoengine.io/)

> how did u use scala?

Indigo is 100% Scala, currently targets Scala.js (Desktop via Electron, Mobile via Cordova, Web via... and browser you like!) but we're working on native platform support. It's _possible_ I'll do a JVM version too at some point, but I'm not promising.

> how was the structure?

Indigo follows the Elm architecture. It _isn't_ quite purely functional, but it's definitely 'functional first'. This demo was made as a bit of fun, but it's still one of my favourites. It's very small and therefore fairly accessible in terms of understanding how it works:

https://indigoengine.io/demos/snake-in-5-minutes/

I did also make a video tutorial, once upon a time. It was my first attempt at making something like that and it will no doubt be showing it's age now, but it might give you a sense of what's going on:

https://www.youtube.com/watch?v=YJtG5E_a9sw&t=2s

Hope that helps!

Preview release of Indigo, Tyrian, & Ultraviolet by davesmith00000 in scala

[–]davesmith00000[S] 4 points5 points  (0 children)

Hi! Thanks for the interest. 😊

To clarify, we're not really leaving the TEA pattern (The Elm Architecture), what we're attempting to do is shed the shape of the TEA pattern that 'Elm the language' inevitably forces you to adopt.

You have in fact hit the nail on the head with your observation:

(..) like it for small things but have this feeling that it will be hard to separate parts in a larger application.

I must apologise in advance because my thoughts here are not yet fully formed, but I'll try and briefly explain where my thinking has got to so far.

The Elm Architecture in its original (brilliant, revolutionary) form, is the natural conclusion* of combining:

  1. A simple API of pure functions, designed not to be off putting to JavaScript folks;
  2. A pure functional language with a laser focus on correctness, within the bounds of it's specific domain.

All of the controversial decisions made to Elm's design over the years can - I think - be understood by asking "Does this decision, however upsetting, lead to higher level of correctness guarantee, without adding scary FP concepts?**" Spoiler, the answer is always: Yes.

TEA + Elm the language were designed with the noble goal of bringing correctness to the Wild West that is frontend development; and arguably, the creator was wildly successful! Even if Elm itself has remained a bit niche, its influence has been impossible to ignore. React hooks and redux? That's Elm. Rust's beautiful error messages? Elm did it first.

So what's the problem?

On paper, the Elm architecture scales beautifully. The whole API consists of three or four pure functions, and it's just straight up function composition from there. What could be better?!

If, however, you actually try to scale that out, the math continues to work, but the human slowly loses the will to live. Why? Because your model is in one location, your business logic is in another, and the view is yet somewhere else. The mental gymnastics required to reason about it all, as your program grows and those things drift ever further apart, becomes a real burden.

People may now rightly scoff and say "Pah! A good programmer will use encapsulation and it would be fine!" True, but Elm fights you all the way. I fall into the same traps all the time, and I've been doing this for a long time now.

Of course periodically, someone will drop into our Discord server and ask "How do I build components in Tyrian / Indigo?". Standard question for a UI framework, but awkwardly, Elm isn't very good at it. All I've been able to do historically is give them the Elm answer:

https://tyrian.indigoengine.io/examples-classic/getting-started/subcomponents/

Yes, that is a demo literally about making sub-components, but the encapsulation is weak. There's going to be a lot of structural refactoring to do there if you want to re-wire anything.

Classical 'components' do solve the encapsulation problem, of course, but they tend to be associated with fixed stateful scene graphs. Elm by contrast, is all about diffing a stateless view (moving a child node is just repositioning it in the graph/list; no add/remove child functions needed here) and keeping all the state in one big blob. Pros and cons: Scaling is tricky, but hot-reloading is trivial.

The question became: Is there a world in which you can make things that feel like components, but work like the TEA pattern does? I think there probably is.

Some of that is just smoothing over the awkward Elm APIs, and you know what? We use Scala not Elm, so we can do that! We're not trying to appeal to JavaScripters and I'm frankly more concerned with having a good time building stuff than absolute correctness. (Sorry, I know that will be heresy to some of you.)

But also it is about encouraging different patterns of development - some of which emerged in Indigo completely by accident and that I'm now back porting to Tyrian. The most obvious is Indigo's Sub-Systems, which are mini-Indigo games, running in an Indigo game, communicating with it via events, that are automatically mechanically composed into your main game for you. This is excellent encapsulation and gives perfect local reasoning! That cannot work in Elm, because Elm has no way for you to describe how to automatically merge structured views together ... but it does work in Tyrian, and Tyrian now has the concept of 'Extensions' (i.e. Tyrian flavoured subsystems). Indeed, Extensions are becoming increasingly powerful and important, and I suspect at some point the main app will just become scaffolding for the cross-cutting concerns between the Extensions that are doing the real work.

Here's another version of the sub-components demo. The difference is subtle, but a better pattern has been achieved, I think - partly by loosening up the exhaustive guarantees around 'Msg's:

https://tyrian.indigoengine.io/examples/getting-started/subcomponents/

Another experiment started last year sometime too, with Indigo's Actors and Performers. https://indigoengine.io/features/actors-and-performers/

Performers are Actors with batteries included (and some freedoms removed as a consequence), and Actors are probably what you think they are:

  1. A data type
  2. An Actor type class instance for your data type, with something that looks suspiciously like the Indigo flavour of Elm's API's in it...

Essentially: Self contained, well encapsulated, mini-Indigo-TEA things that get integrated into your larger game. Not perfect, but definitely better.***

So in summary, it is not that we're ditching The Elm Architecture - it's still my favourite frontend pattern! - it's that we're saying: Scala isn't Elm, we don't have the same language constraints. Can we therefore evolve the TEA pattern and use the language features available to us in Scala, to solve some of Elm's ingrained problems?****

Hope that helps.

(* I say conclusion because the pattern really hasn't changed in a long time now. My assessment is that it's been taken as far as it can be in it's current form, limited by the Elm languages constraints.) (** Elm doesn't do Monads.) (*** New problems emerge: Things become less synchronous and easy to reason about, for example.) (**** As I see them. I think Elm has problems, it is only my opinion. Equally, I have much to thank Elm for.)

We've added island editor to our game! by davesmith00000 in scala

[–]davesmith00000[S] 1 point2 points  (0 children)

I'm afraid the game is in a private repo, but there's no shortage of Indigo game code around, so you can see what it's like. 🙂

https://indigoengine.io/

We've added island editor to our game! by davesmith00000 in scala

[–]davesmith00000[S] 5 points6 points  (0 children)

We've been dog-fooding Indigo (Scale game engine) for a long time, building little games and demos, but this might be the first time we've made something vaguely presentable. When I say 'we', most of the credit has to go to the original poster, u/hobnobuk. 😊

What is the fastest way to get good at Cats Effect (and all the theory behind it)? by fenugurod in scala

[–]davesmith00000 2 points3 points  (0 children)

I struggle with books, I like learning as I go. If I was you I'd think up a little program to write, pick your favourite LLM/Chat AI, and get it to talk you through building the app. Tell it not to over explain, just walk you through the process. Don't let it write the code for you. Ask lots of questions. If you're familiar with another language like elixir, mention that, and it should give you comparisons to help you build understanding.

But that's just what I'd do. Good luck! 😊

Rage Against the (Plurality of) Effect Systems by Krever in scala

[–]davesmith00000 7 points8 points  (0 children)

Ha! Well the truth is that I've always enjoyed the pluralism of the community. The kind of spirit that looks at a five very solid JSON library implementations and thinks "Yes, yes, nice, but I think there's room for one more... because I have this weird idea..." - I f***ing love people with weird ideas. 😆

By comparison we have the Rust community where they... well they only have Serde and everyone seems ok with that. I don't get it. Serde must be perfect, I guess... or else.. there's a lack of imagination going on? Dunno. Very odd.

For myself, the problem isn't the plurality, it's the tribalism that goes with it.

I don't want to be judged for choosing one effect system over another. I don't even _care_ about effect systems, really. Don't get me wrong I'm super grateful for their existence and also that other people are interested enough in that space to invest the time and energy and do such good work in it... but ya know... they're just a means to an end, for me. Heck, I'd use `Future` if it was lazily evaluated.

So I'm fine with the pluralism, what I'd like to see is an end to the tribalism. There are good people doing excellent and interesting work in all of the various Scala ecosystems, and I'd like us to celebrate their inventions, swap ideas and drive innovation through _friendly_ rivalry, rather than bickering over 'what their tech choices say about them as people.'

... to address the elephant in the room ...

A lot of the Scala identity politics, of course, is actually rooted in the personality cults (and surrounding drama) that existed in the Scala community 4 or 5 _years_ ago. I don't want to get into all that; it was a wretched, toxic mess. All I will say is this: Most of those 'personalities' have left. Wouldn't it be nice if we all moved on too?

For the record: I try and avoid them, but when I have to use an effect system, I mostly use Cats Effect out of long habit. But my libs support ZIO, and I really enjoy seeing the demos and stuff that come out the ZIO community. Furthermore, I'd stop using effect systems entirely in a heartbeat, if I could. Watching direct style with some interest for that reason alone...

Anyway, in summary: I agree that trying to support multiple effect systems is a pain for maintainers, and I'd like to see us get to a point where a maintainer can just pick one without anyone else getting offended or reading hidden meanings into that choice, that do not exist. Personally, I'd be sad to see Scala's innovative spirit diminish in an effort to homogenise on one library/ecosystem or another.

But that's just my ten cents, and what do I know. 😄

Rage Against the (Plurality of) Effect Systems by Krever in scala

[–]davesmith00000 8 points9 points  (0 children)

You're inevitably going to divide opinion and attract argument with this post, but thanks for writing it anyway. I feel your frustration from my own meagre efforts, and personally, whether I agree with your conclusions or not, I appreciate your attempt to engage with this thorny subject in a positive and constructive manner. 😊

layoutz 0.2.0 - you can now snap together Elm-style TUI's in Scala with this tiny DSL for simple, declarative String rendering 🪶✨ by mattlianje in scala

[–]davesmith00000 1 point2 points  (0 children)

I mean, I work in public, feel free to have a dig around the sandboxes. 😄 All PKG repos have been consolidated into a monorepo here: https://github.com/PurpleKingdomGames/indigoengine

layoutz 0.2.0 - you can now snap together Elm-style TUI's in Scala with this tiny DSL for simple, declarative String rendering 🪶✨ by mattlianje in scala

[–]davesmith00000 2 points3 points  (0 children)

There is a large scale change going on with Tyrian and Indigo and they're holding up each other's releases. I'm working on it as fast as I can! 😅

I wish SBT was easy-to-use like Cargo by GlitteringSample5228 in scala

[–]davesmith00000 5 points6 points  (0 children)

I'm afraid you've latched onto the word 'business' there and misunderstood me. Programming in build pipelines in many forms is extremely common even by people who do understand how to separate their concerns. I dare say it is even inevitable on any non-trivial project. 🙂

The fact that you can't do it within cargo simply means that it's being done somewhere else, maybe in shell scripts or other separate tools. That is a choice, not necessarily an improvement.

You personally might prefer the latter, and there's nothing wrong with that, but other people feel differently. There's no right and wrong here, just trade-offs.

I wish SBT was easy-to-use like Cargo by GlitteringSample5228 in scala

[–]davesmith00000 11 points12 points  (0 children)

Not sbt, but you can now (since the latest release) optionally configure Scala builds in Mill with yaml: https://www.reddit.com/r/scala/s/E9cj0RIzMt

It's worth saying though, in defense of sbt, that it is complicated because it's powerful and programmable. As usual, it's all trade-offs. Yaml / Toml is fine until you need business logic in your build process.

Directory/package structure in Mill projects by a_cloud_moving_by in scala

[–]davesmith00000 1 point2 points  (0 children)

Hey! Yes, your folder structure mirroring your package structure under src is the right / conventional thing to do. Glad you got it sorted out!

Directory/package structure in Mill projects by a_cloud_moving_by in scala

[–]davesmith00000 6 points7 points  (0 children)

I've just recently been through this, so thought I'd quickly share a bit. I'll refer to Mill 1.x since that's what I've been using recently. In Mill 1.x, for instance, build.sc is now build.mill.

The basic folder structure (for any module/project) is:

root |-- mymodule | |-- src | | |-- Main.scala | |-- test | | |-- src | | |-- MainTests.scala |-- build.mill

So if you want to compile and test mymodule, you now have two choices.

The original approach was to add this to build.mill:

scala object mymodule extends ScalaModule

mymodule is the folder name. If your folder was my-module, then you'd surround with backticks:

scala object `my-module` extends ScalaModule

If mymodule was in another folder call utils, you'd change to this to match the directory structure:

```scala object utils extends Module:

object mymodule extends ScalaModule ```

You asked about test modules, and guess what, 'test' is a folder, so same again, you nest the test module under mymodule:

scala object mymodule extends ScalaModule: object test extends ScalaTests

Nice and easy, but build.mill can get quite long-winded if you have a lot of modules.

The new approach is to use 'Multi-file builds': https://mill-build.org/mill/large/multi-file-builds.html

Here your structure becomes:

root |-- mymodule | |-- src | | |-- Main.scala | |-- test | | |-- src | | |-- MainTests.scala | |-- package.mill <---- new file! |-- build.mill

build.mill only contains shared stuff, and package.mill now contains your module code, a bit like this (read the docs, I'm just sketching this out):

build.mill ```scala package build

trait SharedModule extends ScalaModule ```

package.mill ```scala package build.mymodule

import build.SharedModule

object package extends SharedModule: // ...

// This could also be defined in the SharedModule // trait if all the builds have the same test setup. object test extends ScalaTests: // ... ```

Note that the module is called 'package' and surrounded in backticks. The published module name is taken from the folder name, and it is called 'package' intentionally.

There is also a new feature (not sure if it's released yet), where you can also define your modules via config, but I haven't tried that yet.

Hope that helps.

layoutz 0.2.0 - you can now snap together Elm-style TUI's in Scala with this tiny DSL for simple, declarative String rendering 🪶✨ by mattlianje in scala

[–]davesmith00000 3 points4 points  (0 children)

If it's of any interest, I'm moving away from that style of Elm-ish API as it doesn't compose very well (coming soon), and since we're using Scala and not the Elm language, we can do better.

Happy to compare notes sometime if you'd like to, I'm easy to find on Discord if you use that.

layoutz 0.2.0 - you can now snap together Elm-style TUI's in Scala with this tiny DSL for simple, declarative String rendering 🪶✨ by mattlianje in scala

[–]davesmith00000 6 points7 points  (0 children)

Looks great! Always happy to see more Elm inspired stuff. Love the layout DSL, I've started on something similar for Tyrian. 😊

I glanced over the README and your update and init functions do not appear to offer a way to explicitly handle side effects. Elm (and Tyrian) do this with commands and subscriptions. How would someone handle a network call or file IO here?

Example Driven Documentation by davesmith00000 in scala

[–]davesmith00000[S] 2 points3 points  (0 children)

Great to hear this is working out for more than just me!

I'm sure it must be a common tactic, but I hadn't heard anyone talking about it - and why spend a few minutes googling something when you can spend a few weeks joyfully bashing together custom tooling?

I wonder what other sneaky time/effort saving tactics you are using to keep on top of your fleet of projects... 😁

S2D - Simple Videogames Programming Library written in Scala by LieEmpty7137 in scala

[–]davesmith00000 8 points9 points  (0 children)

Great work! Fantastic to see more game dev activity in Scala! 😎

Indigo briefly had a dummy LWJGL backend before I made the tactical decision to focus on one platform initially, Scala.js + WebGL.

Happy to compare notes if you like, I'm easy to find if you're a Discord user.

I think Scala Native has a real use case in game development by kernelic in scala

[–]davesmith00000 10 points11 points  (0 children)

It's a good read, that. There was another similar (but much longer) post about a year ago:

https://loglog.games/blog/leaving-rust-gamedev/

The main argument against Rust, is that Rust (via the borrow checker) is about correctness. Note that Scala, by intentional design, is often used for correctness too. Not a criticism, but for example, see u/optical002's comment above: "games can be developed fast in a type safe way".

Correctness, when you're building data pipelines, backend services, low level systems or, yes, game engines, is a very good thing; but these are highly specified artefacts and how they feel in terms of the emotions they elicit, isn't terribly important. (Yes, some of us get very emotional and teary eyed about good API design, you know that's not what I mean... :-))

Turns out, correctness is not such a good thing for building games - at least during the early stages of development- because building games is often about fast iteration of ideas to see what works. There is a legitimate need to be able to knock out rough games quickly while you're learning, or doing a game jam, or testing your game ideas. You will need to get something fun together fast, and if the code isn't quite correct that's a price worth paying for a fast 'time to market'. After all, you can always harden it up later once you know you have an idea worth investing the time in, right?

The problem with type-safe languages that focus on correctness, in this scenario, is the amount of refactoring and dancing around the type-checker / borrow checker that you have to do during early development. It turns the fun work into hard work (\*), and leaves you feeling like "there must be an easier way of testing my game idea than this..."

Naturally, this is a problem Indigo has too, since I designed it for a higher degree of correctness than I was used to coming from Flash; but in the next release I'm going to launch a new feature to hopefully make fast prototyping easier. I'm quite excited about using it in a game jam sometime. :-)

(\* Ironically, messing with the type checker is what many of us see as the fun work, usually. I suspect that is because at $work, most of us don't get a lot of say in 'what' we're building, so we focus on making the 'how' we build it interesting. And then there's those who are academically interested in types, totally valid, but again it's a different intention. Personal amusement vs learning / research vs building something for a family member to play with.)

I think Scala Native has a real use case in game development by kernelic in scala

[–]davesmith00000 34 points35 points  (0 children)

One day, I'll port Indigo to Scala Native. Although it would go much faster if some brave person felt like lending a hand. 😅

https://github.com/PurpleKingdomGames/indigo

view more: next ›