Tips on approaching new project

[togFox]

For those following this thread, I'd like to do a FTL remake. I currently have functional:

- a ship (grid) in a 2D space.
- multiple crewpeople
- jumper pathfinding for those crew
- crew will walk around and avoid each other (collision detection)
- fire can spawn and grow and spread
- crew can extinguish fire
- rooms have oxygen
- a tile losing oxygen will deplete the whole room. This means:
- room detection
- tiles can be breached (as in - suck vacuum)

and something that might improve FTL: crew can build walls. This means the player can choose where walls go. You'd want a lot of walls and small rooms to contain fires and breaches but every wall and door impacts crew movement and ability to negotiate the vessel.

So far, there is no real GUI. Just love.graphics circles and squares but the drawing module is very nicely self-contained so I can get to that some other time. The fact I don't have a GUI means I won't post screenshots.

[Gunroar:Cannon()]

Wow, all that's already implemented. I still like screenshots, no matter how graphics unfriendly. Nice work, thumbs ...

[applebappu]

If you're still looking for general tips about project management, what I like to do before I write a single line of code or make a single pixel of graphics is to document everything.

I start up a folder, give it some temporary name, and put a text file in there with like an outline of what the game would be. I fill that in a bit at a time, and break it up into the smallest possible chunks as I go. It starts as a general thing, like "a systems-driven immersive sim with magic" or "a roguelike with an emphasis on nonviolent caregiving" and gradually narrows down and down to things like: listing every action the player is capable of taking, deciding on an organizational structure for entities (how many enemy types and what are they? equipment? what kinds? consumable items, etc), deciding on a control scheme, all of that. Just thinking it through, writing it down (or typing it up), as specific as I can possibly get.

Once that outline gets detailed enough, it basically becomes a to-do list of code to write and assets to create. If I'm unable to get past the design doc phase, that's a red flag that either I need to study some aspect of development more, or the project is too ambitious for me alone, or that I wasn't that interested in the idea to begin with, haha. Not that any of these things apply to your idea! I think you should at least make a run at making ANY idea that you have, and not arbitrarily limit yourself. Just be prepared to take single bites out of the elephant until you've eaten it all. And the first step is identifying where to start chewing; as specifically as is possible.

Of course you continue to revise that design doc as you go, too. Maybe you get partway into your combat model and decide that you're burdening yourself unnecessarily with extra features in there, and you make cuts. Whatever you need to do, it's a living document. But for me at least, it's of paramount importance to keep track of stuff like that in a tangible way.