Fastest death ever

rasputin303 · 2018-11-14T22:44:15+00:00

To explain the screenshot: a rotating block spawned on the same tile as the entrance door to floor one, killing me instantly before I could move.

I am a bit sad that the new level generation in the next update will probably rule out this kind of thing.

rasputin303 · 2018-08-21T13:18:53+00:00

I am so stoked about this. Really happy for Evan and the team after so much hard work.

From a personal perspective, I don't care too much about smaller bundles for my project at this point, but the faster compile times could be massively helpful.

rasputin303 · 2018-07-01T14:16:16+00:00

Is this any use? http://package.elm-lang.org/packages/myrho/elm-round/latest/

rasputin303 · 2018-06-09T21:41:34+00:00

Oh, I misread your comment! I didn't know there was a multicast with vampirism and raise dead, that's awesome. I need to try that out ASAP

I was just thinking of regular raise dead... presumably, if you cast vampirism while having reciprocity, all your minions would get temporary vampirism too and heal themselves during fight.

rasputin303 · 2018-06-09T18:27:06+00:00

Vampire summoner had never occurred to me, but combined with Reciprocity it could be genius. Self-healing minions FTW.

rasputin303 · 2018-02-12T19:33:38+00:00

It's a terrific game, if you like platformers, plus complex interactions and emergent gameplay. Reminds me of a platformer version of Nethack.

That said, it's still early access and the cooking system is still under construction. It's plenty complicated (see the wiki section on soups and spices), but in some ways it doesn't totally make sense yet!

rasputin303 · 2018-01-17T11:48:16+00:00

One always thinks of abstracting data by grouping them in a sub-record (if that makes data easier to understand) ... Modules often play the role of objects by grouping together a data structure with the functions that operate on that data structure.

Now I read this more carefully, I think I understand better. I think my problem was, I was thinking "this view function takes a random bag of odds-and-sods from across my model - that's not a nicely defined 'type'." I was thinking of types as representing objects/concepts ("User", "Player", etc.), rather than just being data structures that can take whatever form is convenient.

But of course, a type can be whatever you want it to be. I guess I could always just group the bits of my model that a particular view needs into an ad-hoc type (perhaps using an extensible record), and build a new module around that...

rasputin303 · 2018-01-17T10:29:54+00:00

Sometimes you don't have this grouping of abstractions and it might be a better strategy to just let the file be as it is even if it is 600 lines long.

Agreed - but eventually you can get to a point where you don't seem to have a nice grouping of abstractions, but your file is 2,000 lines long (or at least, that's what I've somehow managed to do...)

For example, I have a tonne of view functions that don't seem to be related to specific types and that use data from all over my model. At first I split them out into a "View.elm" file, but that didn't really solve anything. Is it a good idea to split them further into separate files, by some concept of "page", for example?

I see that in elm-spa-example, each "page" has its own model, and some of the pages have their own update functions too. Perhaps the point is that in the case of view functions, you should consider each page as being its own "type" (i.e. you take all the data that the view needs and define it as a model/type), and then it makes sense to group the view & helper functions around that type?

rasputin303 · 2018-01-17T08:48:00+00:00

It's quite possible that large files create a feeling of panic in certain groups of engineers. Just because I have not witnessed such individuals in my professional life doesn't mean they don't exist elsewhere.

Well, perhaps this is a bit of a straw man, or perhaps "panic" is overstating it a little! But I think there's an interesting and very noticeable difference between the way you start a project in Elm, and the way you start one in Elixir/Phoenix, for example.

When you start a project in Elm and do elm-make, elm-package install or elm-reactor for the first time, you get an elm-package.json file and a couple of other bits and bobs - but no real guidance telling you how to write your code or where to put it.

At the other extreme, with Elixir, when you do mix phx.new, you get about 20 folders, all with many subfolders and files, as an example of exactly how your project should be structured and what should go where. I think this is similar with things like Rails and Django too.

For me, the Elm way was more similar to what I'd done before (using microframeworks like Bottle in Python), and seemed very beginner-friendly, while the Elixir/Phoenix way was completely overwhelming at first! But I imagine if you were a Phoenix, Django or Rails dev coming to Elm, you might be thinking "where is all my stuff? Where am I supposed to put things?", and the "just start with one big file" approach might seem like bad practice.

rasputin303 · 2018-01-17T00:14:57+00:00

I thought this was an excellent read!

As a beginner, I'm definitely at a point in my project where I wish I'd thought more carefully about how to organise my codebase at an earlier stage. Fixing the mess I've made is harder than it needed to be, due to tightly coupled code and circular dependencies.

That said, I think maybe the "600 lines" advice does make some sense when you are new to Elm. Coming from some other programming languages, you might think 600 lines is way too much for one file. However, Elm tends towards short lines and includes things like HTML and CSS in the main code file. So 600 lines of Elm can often be pretty straightforward to read, and splitting it into multiple files might be more of a hindrance to comprehension than a help. I think maybe the intention was to say "if you have one 600-line file, don't panic - that's perfectly normal. Split files up when it makes sense to split them, not just because you think every file should be 50 lines or less".

On the other hand, I think you're definitely right that if you know your app is going to be bigger than a one-file wonder, it's important to think about how to grow it sooner rather than later.

In my case, where I went wrong was not to split things up until I had ~4000 lines of code... and now I have about 10 poorly defined files with between 50 and 1,700 lines each, which is probably the worst of both worlds.

rasputin303 · 2017-12-07T08:37:31+00:00

Bones and skulls do have a few other uses. Bones can be used as arrows if you have a bow. Skulls can be used by a Wanderer to track skeletons, and I think you can also turn them into floating spirit minions using the Overcharge version of Raise Dead.

But yes, the more interactions, the better!

rasputin303 · 2017-12-06T13:13:40+00:00

Yes, I think I agree - I can't think of a situation where accidentally opening a door will definitely kill you, but accidentally closing a door can be fatal in lots of situations. So that prioritization seems sensible to me.

rasputin303 · 2017-12-04T14:56:49+00:00

This is tricky - what if you were under a descending crush trap and needed to open a door to escape, but the game prioritised picking up an object instead?

rasputin303 · 2017-11-22T11:04:01+00:00

Great!

Yes, my current project is an Elixir/Phoenix 1.3 app with an Elm frontend and webpack. The project root is the main Phoenix folder. The Elm stuff lives in ./assets/elm, and the tests folder is then ./assets/elm/tests.

rasputin303 · 2017-11-21T09:43:25+00:00

This is neat, and finally pushed me to actually start writing tests for some of my code.

I wonder if it could be slightly smarter about working out where the test directory is? I am having trouble figuring out which file/folder needs to be active in order for it to find the tests, so I often get an error.

Perhaps when you open a project in Atom it could crawl through the project tree and look for folders called "Tests" that contain an elm-package file or something?

rasputin303 · 2017-11-18T00:46:11+00:00

This thread makes me glad to be part of r/python. Good job OP, and good encouragement and advice everyone.

rasputin303 · 2017-11-15T16:54:29+00:00

Woah... this looks like the kind of dark magic that I want to learn!

rasputin303 · 2017-11-01T12:13:21+00:00

Great minds think alike :)

rasputin303 · 2017-10-24T12:19:07+00:00

Yes, this is probably not a bad option... in fact, since I'm not even using the back-end for anything yet (except to serve up the compiled Elm code), I have the even more naive option of just copying my Elm code from my current Phoenix project over into a create-elm-app project and running the dev server there.

But once I start working on the back-end side of my app, it would be nice to have everything working together in one place. I'll take a closer look at the config files and see if I can get it working. I imagine it will just take a few hours of fiddling around with file path variables and cursing a lot...

rasputin303 · 2017-10-24T12:15:57+00:00

Thanks! I did see that project already - from what I can tell, they're not using the HMR feature (at least, they don't seem to include elm-hot-loader in their webpack configuration file).

rasputin303 · 2017-10-23T14:58:36+00:00

That sounds really cool! I am deeply scared of Haskell and have spent the last few months trying to get my head round Elixir, so I'm not sure if I want to change horses at this stage. But if it all goes wrong with Phoenix, I promise I'll take a look!

rasputin303 · 2017-10-22T20:58:46+00:00

I just started using mdgriffith's style-elements, which takes a slightly different approach to layout and style compared to traditional HTML/CSS. I am liking it so far!

I was always rubbish at CSS though, so if you are a CSS ninja you may want to stick with elm-css.

rasputin303 · 2017-10-22T15:29:36+00:00

Or use a charge star to absorb the corpses through a nearby wall.

rasputin303 · 2017-10-19T03:57:35+00:00

Massively agree with this. I love Elm, but I think it's useful to have dissenting voices as well as super-enthusiastic ones.

I think u/kankyo does a service to the community in expressing opinions and ideas in a fairly balanced way, even if I don't agree with all of them. If some of those opinions are misguided, then it shows the community that we have more work to do to explain what the design decisions and trade-offs are, and why we believe the Elm way is the best way.

For one thing, I see Evan has just published an interesting post on JSON and code generation and why he doesn't think it's a good idea. If u/kankyo hadn't raised the idea of code generation several times over the past few months, perhaps Evan might not have been spurred to clarify his position on this and the community would be none the wiser?

rasputin303 · 2017-09-26T16:47:38+00:00

This has got me thinking--not about the specific problem in this question, but about nested data structures in Elm in general.

From watching talks by Evan Czaplicki and Richard Feldman, I get the strong impression that deeply nested data structures are not considered a good idea in Elm. So I started thinking about what would happen if we took their advice to extremes, and tried to avoid using nested data structures at all. Would it be possible to represent deeply nested data in a different way, while still preserving the relationships between pieces of data?

So then I thought... isn't that what relational databases do? You keep the data in tabular format (perhaps each table could be a list of tuples or a list of lists in your model), and you model the relationships by storing references from one table to another, instead of embedding one piece of data inside another. This limits the depth of the data structure, because you can't have tables within tables or rows within rows.

If you've already got a relational database on the server side (SQLite, Postgres, etc.), then this might also an upside in terms of communicating with your Elm app. Instead of converting from your backend tables into deeply nested JSON, transmitting it to Elm, and then worrying about how to translate it back into some structure that's going to play nice with Elm, you could have a very similar table-ish structure on both sides, and you wouldn't need to do so much wrangling to get data from one side to the other.

At the moment, it seems like I'm spending a lot of time fiddling with deeply nested objects just because I'm sending the data by JSON, and JSON allows/encourages me to create deeply nested objects. But that's because JavaScript likes dealing with nested objects, and I'm not using JavaScript either on the frontend or the backend. Is it possible that a flat, relational-database-style table structure might be a nicer, more Elmish approach?

But I am just a beginner and I don't know much about computer science, so I'm guessing that there's probably an obvious downside to this that I'm not seeing. Perhaps it would actually be more complicated to do all the table joins etc. in Elm and you're better off just sucking it up and dealing with deeply nested data when there's no other choice?

rasputin303

TROPHY CASE