Tips on approaching new project

General discussion about LÖVE, Lua, game development, puns, and unicorns.
User avatar
togFox
Party member
Posts: 770
Joined: Sat Jan 30, 2021 9:46 am
Location: Brisbane, Oztralia

Re: Tips on approaching new project

Post by 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. :(
Current project:
https://togfox.itch.io/backyard-gridiron-manager
American football manager/sim game - build and manage a roster and win season after season
User avatar
Gunroar:Cannon()
Party member
Posts: 1085
Joined: Thu Dec 10, 2020 1:57 am

Re: Tips on approaching new project

Post by Gunroar:Cannon() »

Wow, all that's already implemented. I still like screenshots, no matter how graphics unfriendly. Nice work, thumbs ... :up:
The risk I took was calculated,
but man, am I bad at math.

-How to be saved and born again :huh:
applebappu
Prole
Posts: 37
Joined: Thu Jun 24, 2021 5:49 pm

Re: Tips on approaching new project

Post by 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.
Post Reply

Who is online

Users browsing this forum: Semrush [Bot] and 55 guests