Author Topic: <-- Archived -->  (Read 32214 times)

0 Members and 1 Guest are viewing this topic.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #45 on: June 02, 2013, 03:55:29 AM »
One more thing is small weapon's stats. The game already has cheap and crappy ones and expensive and quality ones.
If there will be no difference for non warriors between them, why pay more?

They improve attack and maybe other stats, do they not? Better chances if customer is not scared off.
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #46 on: June 02, 2013, 05:29:18 AM »
You mean those oversimplified brawls? So they include a comparison of stats after all?

Oh, and if there are no guards, I believe you missed Psychic and Charismatic traits for go business as usual.
« Last Edit: June 02, 2013, 05:30:50 AM by DarkTl »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #47 on: June 02, 2013, 08:38:48 AM »
Oh, and if there are no guards, I believe you missed Psychic and Charismatic traits for go business as usual.

Ok, I'll add that.

You mean those oversimplified brawls? So they include a comparison of stats after all?

That's the only thing it includes.

Simplified for example means a more complex scenario with luck involved as well a as a number of possible outcomes (Victory/Defeat/Overwhelming Defeat). It's a separate function and can be improved to include more things like traits, items etc.
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #48 on: June 03, 2013, 01:38:45 PM »
Jobs are Events

An event is something that happens in a certain location to one or several characters there. In that sense, stripping is an event where a stripper performs for a number of clients in a brothel. In fact, many ingame scenes are events or series of events: girlmeets and interactions with girls, random encounters or other random events and probably more (travelling through town maybe?).

Treating all these scenes as events or series of events would give as a stanardized way to display these scenes (standardized interface between game logic and screens), which would reduce code complexity. Depending on how similar we can keep the differenct event types to each other, they could potentially share a lot of concepts, systems and code.

What do you think?


Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #49 on: June 03, 2013, 02:13:57 PM »
Jobs are Events

An event is something that happens in a certain location to one or several characters there. In that sense, stripping is an event where a stripper performs for a number of clients in a brothel. In fact, many ingame scenes are events or series of events: girlmeets and interactions with girls, random encounters or other random events and probably more (travelling through town maybe?).

Treating all these scenes as events or series of events would give as a stanardized way to display these scenes (standardized interface between game logic and screens), which would reduce code complexity. Depending on how similar we can keep the differenct event types to each other, they could potentially share a lot of concepts, systems and code.

What do you think?

With other words you want to create a class Event(object) then inherit from it like JobEvent(Event), then inherit again StripperJob(JobEvent) and so on. Same for girlsmeets and interactions (Interaction(Event), DateInteraction(Interaction)) etc. etc. ?

That would go against a promise I made to myself when I've started this project: To use inheritance as little as possible.

I want every game element to be truly unique, even if it requires more code and inheritance gets in the way because it's just so damn useful and allows to create new game elements faster (but more similar to one another).

Also, it is prolly easier to create girlsmeets and interactions in RenPy rather than in pure Python anyway.

I will try to rewrite one of the jobs as a class this week (will have VERY little time for coding, and None tomorrow or the day after) and see if it looks better/is more convenient (which it prolly is). Otherwise I feel like we're entering into a 'daisystikes' loop where we try to improve code that already works flawlessly to improve readability and make it look more professional instead of adding new things to the game...
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #50 on: June 03, 2013, 07:22:46 PM »
Well inheritance would obviously be good choice to implement this, but it is not necessary. At the core of my proposal is the suggestion that the game logic objects for all these event-like scenes provide a common interface. With 'common interface' I mean that all of them have certain methods and attributes, e.g. an attribute called 'imgpath' that contains the path to the image of the event, or a method called 'run' that executes the game logic of the event. The common interface could also encompass constructor arguments, e.g. a location and a list of characters that participate in the event. This convention would make it easier to code screens for event-like game scenes.

Quote
I want every game element to be truly unique
I'm not sure I understand what you mean by that. If every game element is truly unique, it does not share stats with other game elements. I'm sure you don't intend to do that. If they do share stats, why shouldn't they share code to work with these stats?

Quote
Otherwise I feel like we're entering into a 'daisystikes' loop where we try to improve code that already works flawlessly to improve readability and make it look more professional instead of adding new things to the game...
I recall a post were you wrote that you rewrote the code for a job for the 5th time and it still was not working the way you wanted it to. I would not call that 'working flawlessly'. In addition, the current jobs provide very little variation in their text descriptions, so they get repetitive very fast. Don't get me wrong, you did a tremendous job in creating very specific descriptions for many different situations and I like that a lot. However, many of these situations are pretty rare, so as a player you read the same descriptions for common situations very often. As a result, I wanted to see if I could provide more variation for common situations. It took me a while to find the code for the jobs inside the brothel class and then I was faced with a big wall of rather unstructured code. Reading and understanding it was not easy and adding even more code to it would make the situation even worse. That's not 'working flawlessly', and so I proposed to turn the jobs into classes. I will be glad to help with that, but if you don't want to do it, I'm just wasting my time, so I have to ask first ;-)

I have not written new elements to the game for now because I'm still trying to understand what is already there. The existing code is not really easy to understand, you know ;-) Rewriting and documenting elements is a torough if slow way to learn what we already have and it makes it easier for others to contribute.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #51 on: June 03, 2013, 09:41:06 PM »
Well inheritance would obviously be good choice to implement this, but it is not necessary. At the core of my proposal is the suggestion that the game logic objects for all these event-like scenes provide a common interface. With 'common interface' I mean that all of them have certain methods and attributes, e.g. an attribute called 'imgpath' that contains the path to the image of the event, or a method called 'run' that executes the game logic of the event. The common interface could also encompass constructor arguments, e.g. a location and a list of characters that participate in the event. This convention would make it easier to code screens for event-like game scenes.

Well, this would make sense for girlsmeets at least. Those are rather poorly implemented right now and I wanted girls not in service of the player to 'live a life' so to speak so they would have to be rewritten, but it's a large and complicated system that would have to be concepted first.

I'm not sure I understand what you mean by that. If every game element is truly unique, it does not share stats with other game elements. I'm sure you don't intend to do that. If they do share stats, why shouldn't they share code to work with these stats?

They can share some stats, like player and girls. Schools and brothels have close to nothing in common for example.


I recall a post were you wrote that you rewrote the code for a job for the 5th time and it still was not working the way you wanted it to. I would not call that 'working flawlessly'. In addition, the current jobs provide very little variation in their text descriptions, so they get repetitive very fast. Don't get me wrong, you did a tremendous job in creating very specific descriptions for many different situations and I like that a lot. However, many of these situations are pretty rare, so as a player you read the same descriptions for common situations very often. As a result, I wanted to see if I could provide more variation for common situations. It took me a while to find the code for the jobs inside the brothel class and then I was faced with a big wall of rather unstructured code. Reading and understanding it was not easy and adding even more code to it would make the situation even worse. That's not 'working flawlessly', and so I proposed to turn the jobs into classes. I will be glad to help with that, but if you don't want to do it, I'm just wasting my time, so I have to ask first ;-)

What I've meant by working flawlessly is that they do not crush the game and can be added to easily. I want to redo jobs myself because I wish to add to them, as well as rewrite a number of things.

I have not written new elements to the game for now because I'm still trying to understand what is already there. The existing code is not really easy to understand, you know ;-) Rewriting and documenting elements is a torough if slow way to learn what we already have and it makes it easier for others to contribute.

Fair enough :)

I gtg, will not be properly back until tonight and will be off tomorrow as well, but I'll check in from handheld device every now and then.
Like what we're doing?

Offline mijh

  • Newbie
  • *
  • Posts: 11
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #52 on: June 04, 2013, 06:30:47 PM »
Jobs are Events

An event is something that happens in a certain location to one or several characters there. In that sense, stripping is an event where a stripper performs for a number of clients in a brothel. In fact, many ingame scenes are events or series of events: girlmeets and interactions with girls, random encounters or other random events and probably more (travelling through town maybe?).

Treating all these scenes as events or series of events would give as a standardized way to display these scenes (standardized interface between game logic and screens), which would reduce code complexity. Depending on how similar we can keep the differenct event types to each other, they could potentially share a lot of concepts, systems and code.

What do you think?

I don't think this necessarily makes sense...

UI code is always messy, because its defining custom elements and interactions. You can see that most UI screens are quite different from eachother, and all have custom display logic for interaction.

Although there is hardly any game exploration UI or gameplay at the moment, so maybe you are talking more about that, in a similar style to what happens in a lot of SlaveMaker.

I do think the "Next Day" UI in general could be reworked, as well as the logic underneath it, because it fails to display any decent amount of text...
« Last Edit: June 05, 2013, 09:57:38 AM by mijh »

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #53 on: June 04, 2013, 07:23:07 PM »
mijh, I was not talking about UI code, I was talking about game logic for event-like scenes, which I think should provide a standardized "interface" (=method names, attribute names, constructor signature) so the UI code can, for example, always use the same attribute to get a path to the event picture. It's not that important, especially if Xela really intends to not share code between game objects.

Code: [Select]
Schools and brothels have close to nothing in common for exampleWell, let's see, what do they have in common?
Both are...
...locations. They are located somewhere, maybe in the middle of town, maybe on the outskirts. You can go there from locations adjacent to them. They can be in a nice or in a rough neighborhood. You can meet different kinds of people there.
...buildings. They consist of rooms, have at least one entrance and at least one floor. They can be new, old, damaged, large or small and are subject to harsh weather, natural disasters or fire. They are owned by someone.
...offering some kind of services. They might be famous for the quality of their work or infamous for their lack of skill. Their clients might be rich or poor, civilized or savage and many other things.
...work places. They have employees which might be skilled or unskilled, enthusiastic or complacent, common or rare and so on.
...points of interest. People might talk about them, know the owner or famous employees.

Of course, which of these attributes are important for the game elements Brothel and School really depends what you can do there in the game. However, I'd be surprised if there are almost no similarities.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #54 on: June 05, 2013, 04:14:22 AM »
I meant that currently they have nothing in common.  In the future they might and one can find similarities in almost anything if they tried hard enough.

Basically if you asked about unification of elements in the game, I don't care for it.

Lets try keep objects in game separate grom one another. Most important containers in the game are globals and really easy to work with, there is no pressing need for it.
Like what we're doing?

Offline mijh

  • Newbie
  • *
  • Posts: 11
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #55 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.
« Last Edit: June 05, 2013, 12:17:13 PM by mijh »

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #56 on: June 05, 2013, 02:36:23 PM »
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.


 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...
Like what we're doing?

Offline DarkTl

  • Hero Member
  • *****
  • Posts: 4737
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #57 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.

Offline Xela

  • Global Moderator
  • *****
  • Posts: 6893
  • "It's like hunting cows"
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #58 on: June 05, 2013, 06:06:44 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.

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.
Like what we're doing?

Offline rudistoned

  • Full Member
  • ***
  • Posts: 229
Re: -PyTFall- Dev Thread: Next Day/Jobs Concept
« Reply #59 on: June 05, 2013, 10:43:10 PM »
@DarkTl
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.
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

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.
That's one of the (less important) reasons why inheritance makes so much sense to me ;-)
« Last Edit: June 05, 2013, 11:35:42 PM by rudistoned »