Earlier quoted context omitted.
I've been working on a project for a long time. It's not even yielding income, though I hope it will. A friend referred to it as a passion project. That hurt for some reason. I can't explain why.
I think you're interpreting his meaning in saying that incorrectly. You're not an employee for somebody else (correct? It's your own project) - it's not a salaried or hourly position where somebody else is currently signing your paycheck. You obviously don't hate it (I hope? If so, not sure why you wouldn't have canned it yet) Thus, this is what most people would refer to as a passion project. You may have a differen…
How Dwarf Fortress is built
171–180 of 407 posts
Re: How Dwarf Fortress is built
#172Earlier quoted context omitted.
I've been working on a project for a long time. It's not even yielding income, though I hope it will. A friend referred to it as a passion project. That hurt for some reason. I can't explain why.
Yeah I agree with this, I would feel hurt too. For some reason the word "passion" has this hidden connotation for me which makes me feel like the project isn't serious, isn't making money, isn't popular, and is just eating up all my time as it is something I constantly obsess over. In the case of Dwarf Fortress, I would say for him it is "the sole project he's been working on for 20 years now, which takes up $large_n…
This is spot on. If only you would articulate my feelings for me all the time, that would be great!
Re: How Dwarf Fortress is built
#173I love the idea of Dwarf Fortress and I think the internet purest mission is to disseminate works of passion such as this, not to sell me ads instead. That said, I can't get past the ASCII interface -- I'm a huge fan of IF games (which used to be called "text adventures" in the olden days) and I can deal with spartan UIs, but for real-time strategy/sandbox games, I absolutely need some sort of graphics. Tiles, at lea…
Re: How Dwarf Fortress is built
#174Earlier quoted context omitted.
Damn you sound exactly like me...when I work for my own projects they usually die off quickly once I figure out how to do it (without actually implementing it but I'm pretty sure it can be implemented in this or that way). But if it comes from a friend, or a colleague then I'm super focused on it until it's done. It's almost as if I do projects to show off to other people or I like to serve other people.
Part of the issue is that it is difficult to come up with problems worth solving. I think Joel and Fogcreek is a great example. He started out with the premis that you don't need an idea for a successful software company, you just need to find great devs and create the best working conditions and then success would come. This was a novel idea at the time since Apple was the only FAANG that even existed and this was t…
Re: How Dwarf Fortress is built
#175To me what was most surprising about Dwarf Fortress, given the complexity, is that Tad didn’t use git or any other code repository until more recently.
I mean using SCM became the norm in maybe last 10-15 years ? When this was started I don't think using SCM was as ubiquitous as it is today, not to mention on a solo project. If you've been hammering away since then I can see how you might have missed it.
Re: How Dwarf Fortress is built
#176This is a little bit of a hijack but if I wanted to start coding games as a side project, where would I start? Which platform? Mobile, PC, console? Any good introductions on the subject of solo game development? I know I can google this, but I trust HN users more than the Google algo.
The reason for this is: we all want to make beautiful AAA games. But if you have no clue where to begin, it means that you need to develop your intuition for the game logic first – otherwise, you would probably know what to look for :)
If you start by downloading Unity or similar, now you'll be bogged down trying to learn all its systems (without a clear understanding of _what_ you need to learn and what you can ignore, for now). You'll also be bogged down by the need for assets. Sure, you will have a full blown 3D engine, but it's still incredibly boring when all you have is a bunch of cubes or premade assets, so you are right back to square one. Only with more complexity. A lot more - the more visually complex the game, the more code you will have to write that's only concerned about visuals. Getting a character to, say, swing an axe and make it look right and that it is actually hitting something involves a surprising amount of work. Yeah, you could use existing sample games nowadays, but that isn't really teaching you much.
Then it depends on how much background you have. If you were, say, a front-end developer with any experience, you could use that to add some basic visuals. Think Tetris. You can do a lot with very rudimentary tools, as long as everything is kept simple.
At some point, you might _need_ to display graphics (maybe that's the whole point of your game idea). I say "might", because Dwarf Fortress, which is the subject of this thread, never really did. In which case you have some more decisions to make. Is it a 2D game? Maybe use something like Pygame, Löve (for Lua), etc.
At some point you'd be looking into Godot, Unity or similar. And guess what, you could take your basic text-based game, and re-use parts of it as the brains for your game.
Don't get into the game-engine building rabbit hole. It's very fun if you are into that, but know you are unlikely to release anything by going that route. Ask me how I know.
Platform: start with whatever machine you use for development. Presumably you know a lot about it, don't start a side-quest :) Specially, avoid consoles for now. Cross-platform development is getting easier than ever - sometimes all you need to do to start running your game on mobile is to click a dropdown. But that simplicity is deceiving, there's lots you'll have to learn about other platforms. Stick with what you know, until you are comfortable.
I'll let others provide reference material, my sources are outdated as I'm past my Gamedev.net days (for the time being).
Re: How Dwarf Fortress is built
#177Earlier quoted context omitted.
Why would that be surprising? For a single programmer working alone Git is an incredibly complicated tool. P.S.: A lot of you are confusing "complicated" with "difficult".
What? How it more difficult that CVS or even RCS that lies under CVS? That would have been the OS tool back in 1998.
Re: How Dwarf Fortress is built
#178It did not work. The version didn’t allow for the new adventurer to become a resident of the original base.
Futzed around with dfhack to force residence permissions and so on, ended up breaking the game and changing the species or some other weird bug.
But I did learn that adventure mode mine carts are ridiculously fast. As in survival is highly unlikely fast. There was a lot of saving and reloads due to the difficulty of banking turns at speeds that outran cheetahs.
Re: How Dwarf Fortress is built
#179Earlier quoted context omitted.
"Tool" is still a class, with perhaps very generic polymorphic methods (e.g. do_default_action() ). The problem is not polymorphism per se, but rather about having a deep class hierarchy aka lasagna code. My policy: OOP is like salt. Use little and that's great. I only allow a single inheritance layer, and ideally no inheritance at all.
My policy is OOP is like Heroin. Don't even start.
Re: How Dwarf Fortress is built
#180Earlier quoted context omitted.
I have used Git when working with FOSS projects, and I tried using it for my own but it never took. The sort of workflow it is built for just isn't how I like to do things when I work on my own.
Solo workflow is as simple as write code, git commit, repeat. Throw in a git push every once in a while. All on master, no branching or forking.
You can try and convince me until you're blue in the face dude, but I've tried it and I just don't like it. End of story.