Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Parsely]

Fun fact: moats were actually where the castles' sewage ended up. That gives another aspect to their defensive value that's not often depicted.

I mean, some defensive moats of castles did double as sewers, true, but moats are pretty big and castle populations even during a siege are pretty small and don't produce much sewage, so I doubt if it was concentrated enough to turn the moat into stinking river of shitty water, and prior to the popularization of germ theory if a body of water didn't smell and look nasty I doubt people would have found it very repulsive or seen it as a threat.

That is a fun fact though.

[McTraveller]

I have so many various pieces of code that implement various game/simulation mechanics or core infrastructure like data management, etc.  But I can't figure out a good theme or anything to tie them all together into a game/simulation or other type of "package".

[itisnotlogical]

How do you mean? Like as a library that can easily be imported into new projects? What sort of features are covered by these pieces? If you can't put them all under a single category, maybe you can break them up into several so that they're more narrowly defined?

[McTraveller]

No I mean I can't ever decide on if I want to make a simulator, or a game, or whatever. So I have all these libraries to do things like make tectonic terrain on a sphere, or manage large data sets, etc.  But I never get past the "tech demo" stage 

[itisnotlogical]

It seems like you and I have the same problem.

Whenever I abandon a project, or realize that I've unintentionally abandoned it, I copy all the useful files out of it and put them in a folder called "Favorite Assets" adjacent to all my IDE- and language-specific folders. I have a crappy A* implementation in there, some generic save/load game code, an inventory system I wrote for an RPG, and a few more game-specific things that might be useful in the future.

[Reelya]

That sounds like a scope issue. I recommend the Extra Credits channel for a lot of interesting game-dev related topics.

Here are the relevant episodes about managing scope for beginning or solo devs.

https://www.youtube.com/playlist?list=PLhyKYa0YJ_5C6QC36h5eApOyXtx98ehGi

[McTraveller]

Haha yeah I used to have grand visions for massive scope things, like many folks I remember thinking "I want a full universe simulator building thing where people can do whatever they want, massively multiplayer, with real-life physics!"

Now I just have "uh... I can draw a sphere with (up to) millions of triangles, and it has realistic terrain."

But it's literally just that - I am trying to think of "what can I do with that terrain" and that's where I fall over.  I'm more caught in that "this is kind of a hobby thing, but I want it to be more, but am not sure where to go next."

It probably also doesn't help that I have young kids, and a house, and other stuff that takes up lots of mental energy.  Being "stuck at home inside" doesn't really mean more free time 

[Reelya]

That's because you have the wrong perspective, you're doing the trees not the woods. It's like you're trying to invent a car, so you sit down and spend all your time developing really cool gaskets, then wonder why you never have a working car. A really shitty car that actually drives around is better than a non-working one that has really well engineered parts.

Make the woods.

EDIT: start with a smaller scope, first, for a finished thing. It doesn't matter if the thing is small. You just need to build things you can finish (in the first video they recommend scoping for a full thing in no more than one month). Then, you see what needs to get done to make that thing, and you schedule for those things. Then, you make your crappy thing and put it up on itch.io, and forget about it.

That 'build a complete universe' thing is the very trap that the videos warn you about not doing. Everyone wants to do that stuff, and everyone fails.

For example, why not build a simple Masters of Orion clone. You can use your planet-drawing code in that. But, you have to schedule how much of Masters of Orion you can build in 4 weeks. In the first week focus on being able to produce fleets (of ONE type of ship) and move them around, 'capture' planets, but keep it as simple as possible: visiting a planet counts as capture, and if two fleets encounter each other, there's a very simple numbers-based battle. In the second week, flesh out a ship-design system, third week, flesh out a colony/production/tech system. fourth week, factions/diplomacy/end game, polish and upload. Things like adding in a graphical mode for the battles, that should be a whole new project in itself, so treat it as such.

The above would be "MooClone v0.1 - Minimum Viable Product'. Done get bogged down getting any one system "perfect" - randomly scattering stars around is good enough for v0.1, but you could spend a whole month just perfecting a galaxy-generator if you wanted. It would be a waste of time and lead to abandoning another unfinished thing however. Another goal should playable demo at each milestone. e.g. focus on a playable prototype from day 1, but one that can be finished, and the goal is that at each milestone you're left with a game that's still playable and ideally finishable. If part of one milestone is a situation where putting this system in will break the game until later on, then leave that thing out and make it it's own milestone in a future development round.

You can then scope out another one month project which takes you to 0.2, but since you already uploaded v0.1 you could take a break and work on something else instead.

[McTraveller]

The reason I've not done, say, an MOO clone is that there are a million of those out there.  I don't want another MOO.  I want the type of other game that is (sadly) just not doable in a month.

And my day job is good enough that I don't have to make anything.  Necessity being the mother of all invention works the other way too - not enough necessity means sometimes it's easier to just go play DF or some other PC or console game 

[Reelya]

The point isn't to build the MOO clone, the point is that if you don't/can't complete small projects, you certainly can't complete larger ones. It's a learning exercise. It's also a learning exercise in building all the parts and scaffolding that go into a proper game. Things like menus and controls, screen flow, game states, the game loop. You can then completely gut the MOO clone and use what's left as a framework to scope bigger things.

Normally, I'd tell people to start with Tetris or Space Invaders, but since you mentioned you could render planets I said to do a MOO clone. The point isn't to produce more Tetris clones, the point is that people need to start somewhere realistic, not pie in the sky bullshit. Saying you don't want to build simpler things before building the super-cool thing is pretty much the attitude which means you should probably resign yourself to never actually completing anything.

Grasshopper you just don't understand anything of what I just wrote.

[McTraveller]

Oh, know* I understand fully.  My wife groans at the pile of unfinished projects I have.  I have no delusions really about why I can't finish things

Also - I have finished a handful of small projects, and have been involved in some fairly large collaborative ones.  Not sure why there is the assumption I haven't already done that.  The most notable collaborative effort is

Spoiler (click to show/hide)

Civ  I actually personally dislike that game though... 

*not a typo

[Telgin]

Just vaguely on the subject of Masters of Orion, after playing Stellaris so much lately I've been kicking around the idea of possibly trying to make a space empire building game like it but taking the DF philosophy of focusing on gameplay and mechanics more than graphics.  Especially after my last game project became 10% coding working and 90% graphical asset creation...

I haven't really thought much about the implementation yet, but was considering some kind of client/server model where a thin client polls data from the server to display the UI elements.  That would make it easier to come back later and make the game pretty if I ever got a fully functional version running, or allow community modders to make UIs or something in ways they can't do for DF without unofficial hacking tool interfaces.

As far as the server implementation goes, I'd probably write it in C++ after shooting myself in the foot several times trying to do things like this with Python and hitting performance bottlenecks.  I know that if it ever needed to be multithreaded that really needs to be done up front, but that would greatly complicate the design.  Maybe a very simple initial version to proof of concept everything should come first before trying to do that.

[mko]

In case of client/server - what is your plan for covering costs of the server? I was always scared by that part, especially by risk of a bug/DDOS causing a runaway bill.

[Reelya]

He's not talking necessarily about a webserver, he's talking about client/server architecture. In that, you have a process running the game, and other processes talk to that. The other process may or may not be on the same machine. The advantage of this is that your single-player game can become a multi-player game with basically zero modifications, you just have a hook for remote processes to also talk to the server-process.

https://www.gabrielgambetta.com/client-server-game-architecture.html

So, in the client/server model every player is a client, but that includes the person who's computer is running the game. The advantage is that your program is agnostic as to where the game is actually running.

[mko]

He's not talking necessarily about a webserver, he's talking about client/server architecture. In that, you have a process running the game, and other processes talk to that. The other process may or may not be on the same machine. The advantage of this is that your single-player game can become a multi-player game with basically zero modifications, you just have a hook for remote processes to also talk to the server-process.

Oh right. Thanks for reminding me that client/server may happen fully locally (or within local network) and that Internet is not mandatory.