I said this in a previous comment on a different story, so I'm going to copy-paste the content of that comment with some minor edits:
The bfnightly tutorial is a very good tutorial, but I do want to warn that it's not always terribly idiomatic Rust: Herbert was using the writing of the tutorial as a way of practicing Rust, so there are places where the explanations aren't quite correct and other places where the code isn't what an experienced Rust programmer would write. An example that jumped out at me (this from Chapter 1.7) was the use of
&s.to_string()
which is an expression that could be shortened to just s. (Specifically, s has type &str, calling to_string() on it converts it to a String, and borrowing it allows it to be coerced back to a &str but now with unnecessary copying.) Elsewhere (this from Chapter 1.2) it has explanations like
> Copy and Clone allow this [type] to be used as a "value" type (that is, it just passes around the value instead of pointers)
which is also not a correct explanation, or at least is a misleading one: things can still be passed by value even without Copy and Clone and without any pointers at all. (Arguably, he meant, "You can share the value without using borrows," but that's not what the explanation said.)
That said, all this is nitpicky (and I suspect that Herbert would be receptive to feedback along these lines—I just haven't had a chance yet to provide it!) because the tutorial's explanation of roguelike-writing is still very good, and in fact I've been following it as a rough guide for writing a tutorial on top of a different Rust library myself! But I do want to warn about using it as a model for learning Rust specifically.
Thanks for that! (I'm Herbert, made the tutorial; took a weekend away from the computer and it hit HN - nice surprise!). I definitely need to go back and fix a lot of my early Rust (it gets better) and some explanations like that. I welcome bug reports and PRs on the GitHub ( https://github.com/thebracket/rustrogueliketutorial ) if you find more.
They mean a nonlinear (or nonaffine) type, as opposed to a affine type - that can only be passed by reference if you don't want to get rid of it yet - which they would presumably call a "reference" (or "by-reference") type. It's a correct explanation, but ambiguous (not misleading, but perhaps confusing) terminology.
Clone doesn't have anything to do with that though. Copy types are passed 'by value' without a move (so are not affine). But a Clone type doesn't change anything except to add the clone() method.
Thanks for the explanation. I'll get that clarified/cleaned up in the tutorial soon. Tracking it on the associated Github as issue #73, so I don't forget.
Are there commercially successful roguelikes that use ascii art only? Dwarf Fortress is the only one I know of and it's getting an official makeover for the Steam release.
I don't know about roguelikes success (Cogmind comes to mind), but I can tell you that ASCII games can be successful if you have a good idea. For example, I spent about 2 months making Rogue Bit just over a year ago:
That's not really ASCII art. I mean it is, but iirc it's custom shader code in Unity made to look like retro style ASCII art. So it's actually way more difficult to make than a grid of ASCII characters.
Although I get where you’re coming from, I disagree with the assertion that this makes it “not really ASCII art”. At the end of the day modern terminal emulators use a graphics API at one point to render characters on the screen. You wouldn’t say that iTerm2 isn’t a “real tty” because it has a metal backend (in this case, iTerm2 is also using a custom shader to render ASCII/unicode — more complex than this game of course). Where do we even draw the line? Is ASCII art only legit if it can render natively in a traditional terminal? How about only one without hardware acceleration? POSIX compliant? Further down the rabbit hole we could draw a line in the sand at tty’s with no window manager.
It would still be trivial for the developer to add an “textshot” feature to export a frame to .txt, so I’d still qualify it as fitting the ASCII art aesthetic.
I was at first confused. Of course "real ttys" have some metal in their back end! (I'm too young and my default mental image of a "real tty" contains a CRT, but there's probably even more metal in a teletype.)
> it's actually way more difficult to make than a grid of ASCII characters
Any pointers on how to set up a grid of ASCII characters? That'd be what I would use tcod for. It seems like it should be easy, but I guess I don't know how to look for it.
Showing gameplay would be pointless because 99% of the gameplay is in player's head, analyzing the code, maybe even writing some down on paper. If you just look at the screen, it doesn't make much sense.
It's hard to pick any point in that 75 minute video that would be a good trailer material. There's nothing visually spectacular except some static ASCII art and there's no surprise mechanics that would draw attention. The game itself isn't about ASCII art anyway, so having that in the trailer wouldn't make you learn much.
But then again, it isn't a game for everyone. It's for people who are into hacking, computer internals, binary/hexadecimal numbers or assembly/machine language.
I think a gameplay trailer could be made from content from that video, by stringing together a series of short clips. Show the player moving around, manipulating things. Each clip a few seconds in length. Similar to the trailer for Exapunks, you could display text like "Solve puzzles" "Manipulate bits" "Hack your way to safety" (or whatever makes sense). Maybe end with a sequence where something drastic happens (the player does something and the whole screen changes), fade to black.
I think it'd be useful to show the player what the gameplay is actually like. Sure, it's not for everyone, but you can still show what it is.
> I would guess about 2,500 copies based on your Steam review count.
I have 4 games on Steam, and "review to sale number" ratio is all over the place, so it isn't that easy to use for estimation. You can get some idea, but 2500 is nowhere close really.
> Did you sell a lot more on Switch or something? I really would be surprised if an ASCII game could sell 20k on Switch.
About 2/3 of the sales were on Switch. I was surprised as well. I meant the game to be Steam-only, and then some of the players asked for a Switch version. I was blown away after the first month of release.
IMHO, turn based (or just slow paced) puzzle games are awesome for Switch because of the portability. In the evening when the kids have finished playing their Zeldas and Dragon Quests, you can lay back and solve a couple of puzzles until it's time to sleep. Looking at my personal play times, the game I play on Switch the most is "Baba is You".
No doubt. I have a one year old and playing Slay the Spire on Switch is the greatest thing ever because I can just fit it into whatever I'm doing. Maybe I should pursue this console harder...
I know that review ratio isn't perfect but it's still a good rough estimate. It did in fact clue me in that the majority of your sales were probably from Switch.
So amazing, all these smart people making commercial games in such a short time, and then there's me still working on the same old thing year after year, even though it was released a long time ago xD
It's got features from festivals like IndieCade, and had really good Steam reviews during Early Access, so getting a dev. kit was relatively easy.
Rogue Bit came afterwards.
BTW, I tried to check out your game, but your websites (both .com and .us from HN profile) seem to be unreachable? If you're pitching to Nintendo, you need to make sure everything works and you present yourself as an established studio.
I see, I'm definitely not anywhere near this established yet, the process is more formal than I thought. I'll try another pitch when I have more objectivity (solid website, steam reviews or similar) to present.
And thank you for the heads up, that means a lot to me -- There is intentionally nothing there at the moment.
Both Cogmind and Caves of Qud have optional tiles that look like little more than ASCII.
Door in the Woods is ASCII only and has sold ~5,000 copies in about a month. In fact this game has inspired me to try to work on a pure ASCII roguelike for my next commercial project.
ADOM (Ancient Domains of Mystery) was ASCII-art-only through 1.1 and on the strength of that fan base raised a bunch of money on Kickstarter to add a visual layer (the ASCII-only version is still there and updated as the story continues).
Not sure if that's a "YES" or a "NO" given your question.
DCSS isn't commercially successful, but I think it has the potential to be if it went that direction. The tiles version is probably most popular though:
This is great, thanks for sharing it. I started a Rust project awhile ago to do something similar but based on a boardgame. It was fun but I didn't keep up with it. I'll try to get back at it using this as inspiration!
Yeah, I agree - this is a terrific read, and seems like a nice way to jump into Rust, a language I am eager to explore .. lots of strange new idioms, and from the perspective of a rogue-like, nicely done .. will give me a bit of Rust chops anyway! Thanks!
I always enjoyed https://tomenet.eu/ !
As most roguelikes it takes a little time to get into it, but it's really worth the effort (especially playing together with a friend).
It's got a quite small but friendly community and should run under Mac OS (opensource)!
Not exactly roguelikes, but MUDs [1] are multiplayer games with a roguelike feel, but they are more like the ancestors of MMORPGs, TBH.
A telnet program should basically be enough to start playing. There are some "MUD client" programs that enhance the interface (dunno about MAC OS), and some sites offer enhanced web interfaces as well.
One of the most popular, Aardwolf [2] is very newbie-friendly.
Thanks, I am old enough to know of MUDs "first hand". But what I am looking for is a way to play casually with exactly one friend (who lives hundreds of Kms. from me) and not to spend more than 1 hour in the game at the time.
Replying to myself in case this could be of interest to someone else.
After a long debate I convinced my friend to try Torchlight 2.
We played for maybe 90 minutes yesterday and so far it seems to be at least ok for both of us.
We used Discord voice chat to coordinate.
(I think it can scale to up to 4 different cooperative players - of course it is not turn based but from my previous experience with Torchlight first edition I think it is playable even if your reflexes are just average).
Torchlight, and really all diablo-likes, has the problem of being too simple/easy, with higher difficulties primarily item-gated more than whatever skill/strategy; its long term value comes from multiplayer + grinding/trading qualities of random drops, and less so from well, playing it as-is.
As a result, they've never really satisfied my roguelike itch tbh.
Also, if that multiplayer + grind/trade/build characters + sets is the main value you get from Torchlight, then probably consider path of exile, which pretty much optimizes purely on the multiplayer aspects of Diablo 2 (Torchlight lacks some purpose imo; they set out to do a better Diablo 2, but didn't really pick a place to optimize, and didn't do well enough at optimizing everything, and didn't really remove any fundamental flaws)
I agree with your description. Torchlight II was a compromise - The original idea was to play Divinity Original Sins but I pushed us towards a simpler (and less expensive) game because I suspect neither of us would be able to devote enough mental effort and/or sustain interest for a long time.
If my suspect is wrong, we will try to move on to something more complex.
Are there any AAA studios using rust yet? I personally think it's not going to happen any time soon, but I'd be glad to be proven wrong.
My theory that it won't happen without some form of inheritance-like structure. Games, like many forms of simulation, are inherently stateful and tends to fall hard on the OO-side of the Expression Problem spectrum. Traits tend to give you the best of both worlds, but in very important aspect it falls short: the traits themselves do not have data members. I saw a proposal where you could link object data members explicitly to data members that the trait required, which would probably fill that gap...but I don't think it has gone anywhere. Anybody know what I'm talking about so I can look up the progress?
Ready at Dawn's (Lone Echo, The Order 1886) CTO said that going forwards everything new would be in Rust in 2018[1] (however, looking at their careers page all the dev jobs are asking for C++ and don't say anything about Rust). EA's SEED research division was also experimenting with Rust.
As someone who's poked around in the current Rust gamedev ecosystem a bit, the publicly available libraries and frameworks aren't quite there yet for mid-large games (and are probably 1-2 years away at least for serious 3D development), though recent developments like the Legion ECS[2] (Amethyst, imo the most promising Rust 3D game engine seems like it will be switching from specs to Legion[3]), and Ultraviolet[4] (linear algebra library specifically for games & graphics which is faster than the alternatives for both runtime and compile times) are very promising.
I think as ECS becomes more in vogue for AAA game development (I write almost entirely ECS C++17 on a big-budget project at work, for example) we’ll see Rust becoming more utilized.
`specs` takes advantage of Rust’s compiler to provide very clean separation of concerns, opportunities for parallelism, and a clear path for unit testing. It just takes longer for entrenched technologies to change in the big-budget space.
Hmm, I guess when I say “ECS”, I mean a setup where entities are solely IDs, components are data without functionality, and systems are stateless operations on entities that have certain components “attached”.
I’d contrast this with a more traditional “OO” game or Unity’s actor/prefab way of doing things.
Follow some of the rust gamedev discussion and it does surprise me that people are trying, albeit with small things.
Triple-A is an entirely different beast, given that for some AAA games development started before rust even went v1.0 (2015). There's a big risk to be the first into this field, struggling to see why any large company with proven track records and developers who can produce what they need would decide to take the chance on a different lang without seeing smaller ones succeed with it first.
I write rust professionally and people seem to strangely hype the language for many of it's non-usecases. A jackhammer should not be used to change your car tires.
Personally doubt the benefits outweigh the extra energy expenditure required over traditional options but good luck to them I guess, especially in an ever-monetised MMO world rife with cheating.
It's the standard "mdbook" that ships with Rust, also used for the Rust documentation. I pretty much suck at HTML, so I went with the easy markdown option and am enjoying the benefits!
The bfnightly tutorial is a very good tutorial, but I do want to warn that it's not always terribly idiomatic Rust: Herbert was using the writing of the tutorial as a way of practicing Rust, so there are places where the explanations aren't quite correct and other places where the code isn't what an experienced Rust programmer would write. An example that jumped out at me (this from Chapter 1.7) was the use of
which is an expression that could be shortened to just s. (Specifically, s has type &str, calling to_string() on it converts it to a String, and borrowing it allows it to be coerced back to a &str but now with unnecessary copying.) Elsewhere (this from Chapter 1.2) it has explanations like> Copy and Clone allow this [type] to be used as a "value" type (that is, it just passes around the value instead of pointers)
which is also not a correct explanation, or at least is a misleading one: things can still be passed by value even without Copy and Clone and without any pointers at all. (Arguably, he meant, "You can share the value without using borrows," but that's not what the explanation said.)
That said, all this is nitpicky (and I suspect that Herbert would be receptive to feedback along these lines—I just haven't had a chance yet to provide it!) because the tutorial's explanation of roguelike-writing is still very good, and in fact I've been following it as a rough guide for writing a tutorial on top of a different Rust library myself! But I do want to warn about using it as a model for learning Rust specifically.