LÖVE

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?

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.

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)

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 .

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" ...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.

Thanks for the links GR.

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

There we go

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.

How about Djiskra(?) Maps? Overkill maybe? I'm not brainy so...if no one says anything you could make a new topic . 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

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.)

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.