Hi folks; author here. Definitely interested in getting feedback from playtesting either here or in the issue tracker.
As for status, the engine is probably at 85% completion or so; the remaining features are mostly just functionality that will enable additional programming challenges, like hooking in portal access control to an SQLite database or integrating a Forth interpreter for the finale. (There is already a lisp compiler functional in-game.)
There is still a lot to do in terms of story, programming challenges, and plotting though. I have a fairly detailed backstory and outline plotted out, (see the spoilers/ directory) but it's going to be a lot of work to flesh it out into the game.
My long-term goal is to make it a game that you can learn programming just by playing. I feel like most "learn to program" games end up feeling really contrived because they don't lay the groundwork to create a rich enough world to enable anything non-contrived. So my goal here is to create a fairly detailed simulation, and then find the places where you can use programming to overcome problems you run into.
Anyway, obviously the project is OSS, so if you're interested in contributing, please drop me a line.
thanks an awful lot. Will try this out. On a side-note: Great soundtrack recommendation. Bought the first Album already and am listening right now, while doing some data wrangling stuff.
Imho great stuff for blocking out phoning colleagues and focussing.
I heard about 0x10ᶜ after I had been working on Bussard for a while. There are similarities, but they are accidental. I specifically want my game not to include combat, and while early on I thought it would be an open-world thing, as it's progressed I've decided it would be a lot more compelling with a good story behind it.
I may end up having an assembly language in the game, but it would be one of many languages rather than the only one.
That's part of it, but it's also because I want to use it to teach people how to program, and Clojure is really not a good choice for beginners. Learning Lua is a lot easier because it is dramatically simpler. It's also much easier to sandbox, and that is a key part of the game too; there are several layers of sandboxing going on.
Very nice game!
Here are some thing I've notices during playing it.
* There is no usefull coding workflow. Thats how I do it: CTRL+o, enter filename, write some code, ESC, CTRL+ENTER, CTRL+UP, ENTER, oh an error, CTRL+o, enter filename, .... That is a little bit tedious.
* Without syntax highlighting, typos occur everywhere :)
* If there is an error in a script, the stacktrace shows a line number. But the editor does not have line numbers, so I have to count it manually. That sucks.
* Switching between modes would be nice. So switching from the mail view to the editor an back again (with the file and the mail opened) would be nice. A lot of time, there are some bits an pices in the mail which are relevant in the flight mode or in the editor (station names, some hints etc.)
* I've crashed the game and brought it to a point it can't be played any more. (https://p.fu86.de/1468240067-8920.png) (I think I've done ship.docs.msg1 = dofile(...), which caused the problem). Even if I wipe the savegame and use the stock config, the game crashed again after a few seconds.
This looks very cool. When I was a kid I spent many an afternoon programming robots in RoboWar, which used a simple stack machine processor with a bunch of special instructions and registers for doing robot-y things. I think I enjoyed that (and TIS-100 also, which you mentioned) because it provides all the fun puzzle-y nature of programming without having to learn a big API or complex language. Using a "foreign" language / machine architecture also helps separate the game from reality, which I think is important.
Oh yeah, the word "scoop" is used to refer to a collector for asteroid mining, though the manual also refers to "fuel collectors" that are intended to be Bussard ramscoops.
The physics are non-relativistic; correct. I have a section in my dev notes labeled "crimes against science" where I list out all the places I can think of that the game diverges from realism, (and avoid adding to the list) but I hadn't considered that yet since all the interstellar travel in the game happens through artificial wormholes: https://gitlab.com/technomancy/bussard/blob/master/spoilers/... (edit: spoiler warning for the link)
It would be pretty cool, but it would be a lot harder to pull off. At this point the thought of having to be responsible for another server doesn't sound like a lot of fun to me, and preventing users from writing programs that suck up all the CPU cycles is really tricky.
Plus I really want to focus on the storytelling aspects. Especially the end-game scenario (see spoilers/readme.md if curious) would be extremely problematic to implement in multiplayer.
> preventing users from writing programs that suck up all the CPU cycles is really tricky
I like the low level programming / virtual machine approach for this reason. You can provide the player with a machine that is severely limited in speed and size, which makes for a fun challenge and makes it easy to keep things bounded.
Sorry, not friendly a-tall. Never imagined a future vehicle would have a 1970s-era unix command line! Anyway said command line behaves oddly, cursor seems to get "above" the ">" prompt and then I can't type? I can see the point in that you can build up to some complexity without having to invest in a ton of artwork and pixel candy to create a believable GUI for the ship, but the cost in playability is high. I gather your implementation language is Lua... is there for Lua anything comparable to PyGame for Python where you could leverage some graphics?
In interactive mode, I zoomed out what seemed like quite a ways and didn't see anywhere to go.
Yeah, there are some prompt bugs on master; try the beta-1 release linked in my other comment for a more stable version. Will definitely be fixed before the next beta release.
Edit: if you can provide repro steps for the prompt bug that would be super helpful.
> I gather your implementation language is Lua... is there for Lua anything comparable to PyGame for Python where you could leverage some graphics?
Sure; I could easily create a GUI for the ship, but that would be a different game than the one I'm trying to make. There are plenty games like that out there already. I want something that feels more like TIS-100 than Endless Sky. (Not to knock the latter, but they already do a better job at making that kind of game than I ever could.)
On the other hand, part of the point of the game is that if some players want to play a more GUI-centric game, all that you need is already included to turn the game into that kind of game from the inside. All the HUD stuff and the graphics libs are exposed to the in-game Lua sandbox.
> I zoomed out what seemed like quite a ways and didn't see anywhere to go.
You have to use a portal to get to another star system.
Sorry I wasn't clear--I thought he was talking about a bug that had been introduced since the release, but it turned out it was the other way around. The bug was present in the latest beta-1 release but fixed in git master since then.
I hope to have a beta-2 release out in the next week or so.
Thanks; I'm quite happy with LÖVE. I've actually been quite impressed with how easy it is to work with the whole time.
Though speaking of frontends, it is actually also possible to get the game to open a socket and connect to it from Emacs, programming your ship from the outside. It's not very polished at this point, but I intend to expose the in-game UI over the nREPL protocol so you can code other clients for it if the in-game editor doesn't suit your fancy: https://gitlab.com/technomancy/bussard/blob/master/bussard.e...
As for status, the engine is probably at 85% completion or so; the remaining features are mostly just functionality that will enable additional programming challenges, like hooking in portal access control to an SQLite database or integrating a Forth interpreter for the finale. (There is already a lisp compiler functional in-game.)
There is still a lot to do in terms of story, programming challenges, and plotting though. I have a fairly detailed backstory and outline plotted out, (see the spoilers/ directory) but it's going to be a lot of work to flesh it out into the game.
My long-term goal is to make it a game that you can learn programming just by playing. I feel like most "learn to program" games end up feeling really contrived because they don't lay the groundwork to create a rich enough world to enable anything non-contrived. So my goal here is to create a fairly detailed simulation, and then find the places where you can use programming to overcome problems you run into.
Anyway, obviously the project is OSS, so if you're interested in contributing, please drop me a line.
Edit: if you're impatient and want to just download a single file and play, releases are at https://technomancy.itch.io/bussard