PyTFall > PyTFall: Game design
<-- Archived -->
mijh:
If you want to eventually have a game with good gameplay, you need some non-hair-pulling process to move from "game doesn't crash" to "game has sane, understandable, non-bugged mechanics that I can understand and enjoy seeing work".
If you start off with complicated logic that is hard to reason about or abstract, you'll never have a way to move from the former to the latter. Btw, people have written long, abstract, best-selling books about this (good software design), it is one of the most talked about things because getting it right is A) hard B) pays off in spades.
One of the most important things that is common to, for example schools and brothels, is that they are both objects that add, hold, and remove girls, and they modify the girls they are holding. And well, stuff happening to girls is probably the core element of the game...
So indeed that speaks extremely strongly to the usefulness of a common interface for these things.
I also remember seeing conversations about girls "having lives" outside of the player control, e.g while they are in the world, etc. Having a common interface for these locations also would make this sort of feature far easier to implement.
Without it, you could fix one bug, or introduce one feature in x location, and then a week later wonder why y, z and w locations don't work as you expect. And then fix a bug for that feature in z, and then two weeks later wonder why there's a similar bug that's just come up in x again. You might remember that you fixed it two weeks ago in x, and then copy and paste the 'fixed' code back, but in the process forget that you changed x's behaviour subtly the week previous, and thereby introduce another bug with the c+p. The ability for this to happen when you have more than one developer also grows exponentially, especially when there's no formal testing process.
Xela:
--- Quote from: mijh on June 05, 2013, 10:06:18 AM ---If you want to eventually have a game with good gameplay, you need some non-hair-pulling process to move from "game doesn't crash" to "game has sane, understandable, non-bugged mechanics that I can understand and enjoy seeing work".
If you start off with complicated logic that is hard to reason about or abstract, you'll never have a way to move from the former to the latter. Btw, people have written long, abstract, best-selling books about this (good software design), it is one of the most talked about things because getting it right is A) hard B) pays off in spades.
One of the most important things that is common to, for example schools and brothels, is that they are both objects that add, hold, and remove girls, and they modify the girls they are holding. And well, stuff happening to girls is probably the core element of the game...
So indeed that speaks extremely strongly to the usefulness of a common interface for these things.
I also remember seeing conversations about girls "having lives" outside of the player control, e.g while they are in the world, etc. Having a common interface for these locations also would make this sort of feature far easier to implement.
Without it, you could fix one bug, or introduce one feature in x location, and then a week later wonder why y, z and w locations don't work as you expect. And then fix a bug for that feature in z, and then two weeks later wonder why there's a similar bug that's just come up in x again. You might remember that you fixed it two weeks ago in x, and then copy and paste the 'fixed' code back, but in the process forget that you changed x's behaviour subtly the week previous, and thereby introduce another bug with the c+p. The ability for this to happen when you have more than one developer also grows exponentially, especially when there's no formal testing process.
--- End quote ---
I would rather spend more time fighting bugs than have this game turn into an inheritance orgy like our battleengine (for example). Glancing through code of a bunch of different games coded in different PLs and a lot in RenPy/Python, I know that working on a project that is coded properly would be a freaking nightmare to me and this is an indie game that will be distributed for free so getting joy out of working on it is the main point...
DarkTl:
Sorry to interrupt as non-Python coder, just wanted to say that total inheritance has little in common with good sd. It could and will result in limited functionality and flexibility when you need it most. Especially because there is no clear, comprehensive, 100% ready concept of the game.
Xela:
--- Quote from: DarkTl on June 05, 2013, 04:24:00 PM ---Sorry to interrupt as non-Python coder, just wanted to say that total inheritance has little in common with good sd. It could and will result in limited functionality and flexibility when you need it most. Especially because there is no clear, comprehensive, 100% ready concept of the game.
--- End quote ---
True
Not the point I was trying to make. Right now I am confident that if we just head in the direction code development was heading, we'll have a solid, working and bugfree game in the end. Improvements like Rudi's objects instead of lists to improve code readability offer no disadvantages what so ever and just make things better. I am also more than ok with using inheritance for object that are a LOT alike like jobs for example. Locations or interfaces on the other hand are very different, I don't want or see the need to brothels, shops, school(s), market to inherit from any one class and even at the risk of not following accepted programming paradigms or patterns and increasing the workload. Better to code it in an enjoyable way and finish the project, than doing everything right and failing cause it gets to boring to develop.
rudistoned:
@DarkTl
--- Quote from: DarkTl on June 05, 2013, 04:24:00 PM ---total inheritance has little in common with good [software design]. It could and will result in limited functionality and flexibility when you need it most.
--- End quote ---
I strongly disagree. Every element in a python program, be it a number, string, class, function, instance or any other object inherits from the 'object' class. In Python, everything inherits from 'object'. Please explain how this limits the functionality and flexibility of python software.
Since I started this whole discussion, I would like to reiterate that I am not trying to force a design for this game that relies heavily on inheritance. I belief that some shared base classes would be beneficial, but in the end it's up to the main contributors to decide which design they want to use. Based on my limited knowledge that would make it Xela's decision, and I will not oppose it.
Nevertheless, I agree with everything mijh said in the last post. Not using inheritance or at least some standardization by convention will very likely cause problems with debugging and code improvement in general.
I also can really identify with this statement:
--- Quote ---this is an indie game that will be distributed for free so getting joy out of working on it is the main point
--- End quote ---
So with all that said, I would like to point out that I definitely enjoy using inheritance in my code.
@Xela
--- Quote ---one can find similarities in almost anything if they tried hard enough.
--- End quote ---
That's one of the (less important) reasons why inheritance makes so much sense to me ;-)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version