Tips on approaching new project

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

Tips on approaching new project

Post by togFox »

I want to make something similar to the 2012 game Faster than Light (FTL) as I enjoy the 'crisis management' this game presents.

I have learnt from previous projects and proof-of-concepts that I tend to start with elementary graphics and slowly build up the back end and front end but then I think of a brand new idea that just breaks my framework or code and then I get cranky and lose productivity.

This time, maybe because it's better, maybe it's just an experiment, I'd like to code a large part of the back end mechanics. I'd like to define classes and algorithms and functions. Things that interact with other things with no or bare minimum GUI. I'd like to see if I can do space ship combat mechanics without investing hours into GUI's and art work and graphics which aren't my strong point anyway. I want to see if I can do flood-fill and path-finding and I want to be sure that most of the events I want to do can actually be done before I invest weeks in a GUI.

I'm thinking maybe a combination of console and printing raw numbers to the screen. Maybe super elemental use of love.draw.rectangle etc to help see the mechanics working. Not sure about inputs and commands and manipulating things. Maybe text prompts via console that won't mean anything to anyone except me but I can still prove the mechanics are sound.

Has anyone taken this approach before and is it viable? If it does work then I'm hoping it is a good way to make a super clear separation between mechanics and graphics. Might even make it possible/easy for a graphics person to do graphics thing while I can do the back end thing.

Thoughts? Dumb idea?
User avatar
ivan
Party member
Posts: 1736
Joined: Fri Mar 07, 2008 1:39 pm
Contact:

Re: Tips on approaching new project

Post by ivan »

It's not a dumb idea, but your scope is way too large. I've been making games for a while and I think FTL is a fairly large project for one person. Not impossible but it would take you years. Start with something small like just the combat mechanic and try to build a game around that.
togFox
Party member
Posts: 407
Joined: Sat Jan 30, 2021 9:46 am
Location: Brisbane, Oztralia

Re: Tips on approaching new project

Post by togFox »

Thanks. Keeping the gui to simple rectangles and circles and re-using libraries I'm familiar with is my strategy for getting something up quickly. (though ugly)
User avatar
Gunroar:Cannon()
Party member
Posts: 606
Joined: Thu Dec 10, 2020 1:57 am

Re: Tips on approaching new project

Post by Gunroar:Cannon() »

I say start with a flexible code base. OOP (just classes) for almost anything helps to make the code more organized and easier to add new functionality , or even a total revamp, without breaking the whole game/code. Here are 2 examples I have of using oop(that I know of, not that they're examples of good projects..heheh...no way ... heh):
This one you've seen is made by me. It's a less organised OOP structure, the basics. A bonus example like this is also the bump.lua demo.

Then there's this one I've seen , which uses a more organised setup that can easily grow to become a big game without hassle.

One good-to-know method is what kikito(guy who did bump.lua) wrote about seperating functions. It really helps when you want to change one little thing, then don't have to go looking for it in a for-loop 300 lines long :rofl: .

And if you just get text prompts you can print out the actions and stats (each turn) and see if things are going well and entertaining. The simple gui also works, as long as you don't do anything "png" :ultrahappy: ...or "jpg"... ... or "bmp"...or ...you get the point. But I suggest that if you want to do pathfinding a simple graphics scheme would be good to check how things work.
-It might look like nonsense :roll: but there's so much proof.
-Some more if you pls... :? .
It has to be real then, all that talk about the end :shock: .
-How to be saved :huh:
togFox
Party member
Posts: 407
Joined: Sat Jan 30, 2021 9:46 am
Location: Brisbane, Oztralia

Re: Tips on approaching new project

Post by togFox »

Thanks for the links GR.

I have a space ship!! Onwards and upwards!!

Image
User avatar
Gunroar:Cannon()
Party member
Posts: 606
Joined: Thu Dec 10, 2020 1:57 am

Re: Tips on approaching new project

Post by Gunroar:Cannon() »

There we go :awesome:
-It might look like nonsense :roll: but there's so much proof.
-Some more if you pls... :? .
It has to be real then, all that talk about the end :shock: .
-How to be saved :huh:
togFox
Party member
Posts: 407
Joined: Sat Jan 30, 2021 9:46 am
Location: Brisbane, Oztralia

Re: Tips on approaching new project

Post by togFox »

So here is my spaceship with debug information turned on. There is a person moving around by me typing into the console (off screeen). You can see smooth movement and the 'person' (circle) is navigating corners using jumper.

(no sound)
https://youtu.be/wFDEqBcp2sE
(takes about 5 seconds to start)

I've seen blogs and articles around the place but how does one stop the cutting of corners like the one seen here? I was thinking of getting some really brainy forum user to do a custom heuristics (with jumper) that permits diagonal movement UNLESS a corner tile is unpassable, in which case, recalculate with the diagonal option disallowed.
User avatar
Gunroar:Cannon()
Party member
Posts: 606
Joined: Thu Dec 10, 2020 1:57 am

Re: Tips on approaching new project

Post by Gunroar:Cannon() »

How about Djiskra(?) Maps? Overkill maybe? I'm not brainy so...if no one says anything you could make a new topic :P . I don't even know how they(djks maps) work myself but you could learn, seems useful for weighted paths, and Brogue maker explains how he used it
-It might look like nonsense :roll: but there's so much proof.
-Some more if you pls... :? .
It has to be real then, all that talk about the end :shock: .
-How to be saved :huh:
milon
Party member
Posts: 213
Joined: Thu Jan 18, 2018 9:14 pm

Re: Tips on approaching new project

Post by milon »

togFox wrote: Mon Jul 05, 2021 6:03 am I've seen blogs and articles around the place but how does one stop the cutting of corners like the one seen here? I was thinking of getting some really brainy forum user to do a custom heuristics (with jumper) that permits diagonal movement UNLESS a corner tile is unpassable, in which case, recalculate with the diagonal option disallowed.
You can use A* or Dijkstra or whatever, and just specifically check the corners anytime you're considering a diagonal move. I haven't looked at your code, so maybe I'm missing something, but that should be easy enough to do. There's an A* thread kicking around somewhere if you want an example. (A* is another pathfinding algorithm in case you weren't aware.)
togFox
Party member
Posts: 407
Joined: Sat Jan 30, 2021 9:46 am
Location: Brisbane, Oztralia

Re: Tips on approaching new project

Post by togFox »

I thought about your suggestion and realised there was a way. I use JUMPER which uses A* by default but that doesn't matter. The pathfinding module returns a list of waypoints to traverse. For each tile on that path, I do as you suggest - check corner tiles for walls and if so then disallow that diagonal movement and instead permit only up/down/left/right movement.

Works a charm. Thanks for the idea. :)
Post Reply

Who is online

Users browsing this forum: No registered users and 29 guests