Yet Another Bulletin Board

Welcome, Guest. Please Login or Register.
Mar 29th, 2024, 11:40am

Home Home Help Help Search Search Members Members Login Login Register Register
Pizza Business Forum « Post reply »


   Pizza Business Forum
   General
   Development
   Post reply ( Re: ingredients storage & multiple restaurants )
Post reply
Subject:
Full name:
Email:
Message icon:
Add YABBC tags:
Add Smileys:
Message:

Disable Smilies:

Check this if you'll be adding code (or don't like smileys).

shortcuts (IE and NS6 only): hit alt+s to send, alt+p to preview, or alt+r to reset


Topic Summary
Posted by: Jeff Koerner Posted on: Mar 30th, 2003, 4:35pm
    having a central warehouse for ingredients would make the purchasing porcess quicker if you have a lot of restaurants, but how many restaurants do you think the average player will have? maybe just a few, since even having just one is supposed to be fun. so I think the player can deal with buying seperately for say, 3 different restaurants. in fact, it would make more sense to do it this way if you are using different strategies at different restaurants. for example, you could go to the restaurant where you're selling Octopus on every pizza and see how much they have in stock and maybe decide to buy more. But if you only have one main list of ingredients, then the player has to calculate how much octopus she's going to need for the sum of all her restaurants, which is probably going to require looking at the statistics of each one individually and adding them up. In short, if you have to think about each restaurant individually, then why not have you buy stuff for them individually?
    I think the repitition of searching through lists and clicking on items and then specifying how much to buy has been eased enough by the use of contracts. in fact, this might be a little TOO easy...why don't we make the deliveries happen on a regular basis like they would irl, say, on every thursday? if you tried to place a seperate order every time you thought you might need some of this or that, there's no way you could get a truck to deliver you just a couple onions and some cans of sauce! you have to PLAN AHEAD, and that's part of the game: if you guess wrong, then you might run out of something and have to wait until next week and piss off a few customers in the meantime, or else--what we did where I worked-- go to the grocery store next door and purchase something(at a higher cost/product than if we had bought in bulk).
     Trying to make the buying process simpler is a great idea, but having a central warehouse would only be useful if you displayed all the info about each of the supply/demand for each ingredient and for each restaurant on the same screen. there's no need to have an actual warehouse in-game when all you want to do is centralize the buying process; just centralize the information from all restaurants and display it all together on the buy/sell screen. It could display the data for the total franchise in addition to the details of whichever restaurant you're 'in' at the moment, but the buying would be only for that specific restaurant.
 
this could be stored in a big walk-in refrigerator that every restaurant has. this could be an actual room where the player can visually see how many boxes of different stuff he has. another advantage of this technique is that employees could steal the products from the walk-in...well it might not be an advantage for the player, but it would add both fun AND realism to the situation. I think the possibility for retaliating against a dishonest employee would add a lot of appeal to the game. also, it's more intuitive than having an imaginary warehouse with infinite trucks that always have drivers on-call and travel at faster-than-light speeds.
Posted by: ares32585 Posted on: Mar 31st, 2003, 3:48pm
Alright, I can see what you're saying about having each restaurant handle its own ingredients.  
 
However, we want to make sure that the player won't be overwhelmed this way if he has, for example, 6 restaurants or 10 restaurants, etc.  We don't want to be limiting the number of restaurants that the player can run because the ingredient handling becomes overwhelming.  
 
As for the deliveries not being instantaneous and available whenever the player wants, I would agree with you that this idea has merits.  We should just make sure that this adds another aspect to the game and is not just put in to make the game more "realistic."  
 
If we do have the player have a refrigerator for storing ingredients, should this be automatically given to the player (i.e. for free), or should he have to buy it.  If he has to buy it, what happens when he doesn't have one in a restaurant?
Posted by: Jeff Koerner Posted on: Mar 31st, 2003, 9:22pm
you're right, if someone wants to have a dozen restaurants then they ought to be given that chance, it would suck to not expand your franchise simply because the interface is too awkward. they should be able to run as many restaurants as they possibly can.
 
yeah, making a simulation 'realistic' simply for the sake of realism is a bad idea, but there are certain general concepts that should be consistent with reality, or else you're going to end up with people finding completely unrealistic approaches to solving problems, which is not something that you want. for example, if ingredients never expire, then there's no risk in buying them: you just keep them until they sell so why not buy as much as you want? that's no good. or 'why plan ahead' since you can have anything available at the click of a button? that's also not good. but it's even worse if we complicate the matter so much that it becomes a long task just to get some ingredients together. there has to be a balance between what you'd expect in real life, and how much time the player is going to want to spend micromanaging.
 
and I hadn't even considered the idea of a restaurant without a refrigerator. that would be like a bicycle without brakes, it's something you use all the time. maybe we should allow for this possibility anyway, or maybe we should just lump the cost of the refrigerator into the money needed to start out a new restaurant and include it automatically.
Posted by: ares32585 Posted on: Apr 1st, 2003, 1:54pm
Quote:
yeah, making a simulation 'realistic' simply for the sake of realism is a bad idea, but there are certain general concepts that should be consistent with reality, or else you're going to end up with people finding completely unrealistic approaches to solving problems, which is not something that you want. for example, if ingredients never expire, then there's no risk in buying them: you just keep them until they sell so why not buy as much as you want? that's no good. or 'why plan ahead' since you can have anything available at the click of a button? that's also not good. but it's even worse if we complicate the matter so much that it becomes a long task just to get some ingredients together. there has to be a balance between what you'd expect in real life, and how much time the player is going to want to spend micromanaging.

 
Once again, I completely agree with what you're saying here.  Some foundation of reality is necessary for a game like this:  the player has to feel that this might be what it's really like to run a pizza business, even though it might be inaccurate in several aspects.
Posted by: inconspicuous Posted on: Apr 3rd, 2003, 12:47am
well, I'm not so sure that we need to accurately recreate the reality of running a business since games are mostly about fantasy anyway. what we should create is a feeling that is similar to what the player imagines running a business could be like, or what they wish it could be like. what I meant before was that if our model doesn't reflect the real world, then it's not going to behave like the real world either. this isn't a problem as long as we're aware of how and why the game is different from reality; the way the game is played is only going to be determined by the things we choose to reflect in the game model. so I was just emphasizing that having ingredients that never expire is going to allow for some very unrealistic strategies and I don't think that it was intended to have that effect.
Posted by: johnny Posted on: Apr 3rd, 2003, 7:55am
I would like to include the expiration of ingredients and the 'ordering' of ingredients. I love the theoretical concept of that idea; however, it just does not appear to work within a realtime simulation.
 
The fact that the player will be working in a time frame within a ratio of a dramatic proportion may create more fusteration and less fun for the player. In Pb1.0, we included the expiration of ingredients, and it was defenantly hard to keep up with - how may ingredients are left - etc etc. I can not imagine the large amount of time the player would have to commit just to manage ingrientents on a day-to-day basis considering that he may have more than one restaurant.  
 
On the other hand, the concept can be done. It won't be easy; we would just really have to work on impleneting the manager employee to actually 'run' the restaurant without the player's presence or interaction.  
 
But, personally, I would see this as a simple way to rapidly expand the restaurant franchise. Then it would become a 'build it and forget it' type of situation. I would suggest that we do not initially include it in the game, but we could leave some room for it later.
Posted by: inconspicuous Posted on: Apr 6th, 2003, 10:44pm
well, I think that some people won't mind spending the  time to choose what toppings to put on their pizzas since part of the fun is supposed to be having customized products--to me, that level of detail seems necessary. there is still, of course, more than one way to implement the idea of managing ingredients, or even of representing custom products.
 
first of all, yes it is tedious to specify x amount of y ingredient for every order, especially the way the interface is set up at the moment which requires clicking several times and opening up a new 'order' screen each time. But it's a cool idea, and you've already spent time to develop it this far. if something isn't fun to do, then the solution is not to spend time developing AI that will take over the boring job, the best solution would be to stream-line the buying process by making it quicker to adjust and automate so that it adds fun to the game rather than becoming an annoyance.
 
again, I suggest that players make adjustments to ordering only once a week. that gives them 7 whole days of play inbetween each ordering session. even at an average rate of just a couple minutes per day, that makes them at least 14 minutes apart. that isn't unreasonable, as long as it doesn't take more than a couple minutes to order, and  that would make the amount of time spent on ordering roughly 1/8, or 13%.
 
If we expand the contract feature and make it so that there is a whole screen devoted to the weekly shipment of goods along with the statistics for how much of each item was consumed last week, then it becomes possible to tell at a glance if you need more of something. highlight the stuff you ran out of in red or whatever.
 
the problem with the current interface is that the actual buying is a seperate window which must be opened and closed for each item bought. it may make sense from a programming perspective to associate a new window with the idea of changing the parameter of a function, but to the player this means that to change merely a few numbers can take as long as 30 seconds! no one is going to like doing that. so there must be a better way. for example, do you think that the 'how many would you like to purchase' box could become a whole column of boxes right next to and in line with each ingredient, so that you have the ability to change the number for each ingredient without changing screens? in addition, maybe the total cost of the contract or individual order could be shown somewhere? I'm not saying for each item seperately, because that's over-kill, but the player should be able to quickly see how much her expenses are rather than just seeing the money subtracted from her cash. if it's not included here, it should be included somewhere else in the office statistical charts, but ideally it could be shown in both places.
 
computing the expiration of ingredients could easily get out of hand when you have hundreds of individual ingredients per restaurant. so don't calculate them individually. do it by shipment date.
have an expiration function that is set to run X amount of days after a shipment arrives, where X is the time it takes for the food to go bad. then when that day rolls around, you take the # of each type of ingredient that was ordered at that time and subtract the number of ingredients that were used for each type. the tricky part comes when multiple orders overlap. e.g. you have several orders of something at once, some of which may expire today and some next week. this isn't as hard as it sounds to keep track of: if the expiration function returns a negative value--more ingredients were used than were ordered--then that means some ingredients from another order have also been used in addition to all of them from the order in question. the absolute value of that result signifies exactly how many of these ingredients from the second order have been used up to that date, and they need to be added to the # used when you calculate the next order. let's say an order of 20 pepperonis arrives today. it expires in 8 days, but just a few days later another shipment of 20 pepperonis arrives. after the initial 8 day period is up, the expiration results show that 28 pepperonis have been used. since it returns "-8", then the result is =< 0, and all of the products that would have gone bad have instead been sold: nothing is being marked as expired for pepperonis. now we just have to set the # of used pepperoni products to '8'. this is important because if it were reset to zero, then 8 pepperonis would be missing from the next calculation. 3 days later we calculate the number of pepperonis used and it says 12 + the original 8 = 20. the function returns 0 and all the product has again been used. you can see what would happen if that 8 wasn't preserved. so, that's a very simple function to add if I've communicated it correctly.
 
hm...you know, if we force shipments to arrive weekly, then that would coincide perfectly with the 7 day shelf-life that ingredients currently have, and would simplify the above function.
 
Also, currently, an expired product disappears without a trace. I'd like the expired products to remain in stock, but be visually identified as poison. the reason for adding this complexity is that then a customer could get food poisoning, either as a result of negligent employees or malicious players. and who wouldn't think that was funny? Grin
Posted by: ares32585 Posted on: Apr 7th, 2003, 1:58pm
Well, firstly I just want to clear up a few things that I think you might have misunderstood a little.
 
The 2.0 version of the game is completely separate from the 1.0 version of the game:  we will be working from a new codebase.
 
Secondly, this game runs in real-time.  That is, while the player is performing various functions and activities, the game engine is still running (unless, of course, he paused the game).  Basically, the player should be able to perform all these activities without needing to pause the game.  The player should not be forced to pause the game to perform a task that is time-consuming.  If that's the case, then we've made one of the tasks too complex.
 
Lastly, just so you have some idea of the time compression we'll probably be using in the game, here's roughly what it will probably be.  1 second real-time = 1 minute game-world.  However, that does not mean that the people in the game will be moving at hyperspeed.
Posted by: johnny Posted on: Apr 7th, 2003, 2:39pm
It might not be best to restrict the player to when he may purchase ingredients. It takes control of the situation away from the player, and I feel that that is never a good thing.
 
I think it would be really cool of serving the customer a pizza with food poisoning. Hahaha. I can imagine the customer taking a bite, grasping his throat, knelling over, and dying. How bad would that hurt the business. Talk about bad publicity, a decrease in popularity, bad bank credit, and lawsuits galore. And it would all be because the player neglected to replace that lazy cook with a decent one.
 
So I think that the expiration could be handled on the global level. Say each peporoni has a shelf-life of 7 days in the warehouse, then it would automatically be tossed out after the time has expired. The player will be notified with a message in the news ticker consisting of the number of food expired and a skull and crossbones. Upon clicking the text in the news ticker, the player will be shown what was expired and how much of those type of ingredients still remain in the warehouse.
Posted by: ares32585 Posted on: Apr 7th, 2003, 2:47pm
Esentially, the player's interaction with ingredients would be this:  the player must purchase the necessary number of ingredients to supply his various restaurants.  They can be purchased at any time and are stored in a central warehouse.   Ingredients are also directly used from the warehouse, that is, the player does not have to worry about getting ingredients from the warehouse to the restaurant.  
 
This simplifies the ingredient system in the game, but also provides similar dynamics to the system which you proposed:  the player must be sure to have enough ingredients in his warehouse.  If he buys too few, he can always remedy it, but it's likely that a few sales will have been lost before he is able to buy more.  Secondly, if he buys too many ingredients, he is wasting money, as the ingredients are expiring without being used.
Posted by: inconspicuous Posted on: Apr 8th, 2003, 11:32pm
thanks, that does clear some things up!
 
I was imagining that the game would progress from day to day by stopping inbetween days rather than playing continuously, which would be a little disorienting: the  restaurant would open, the player would go through the whole day, and then the restaurant would close. Incidentally, how long is it going to be open for? maybe the player could choose to try and run a business that was open 24 hours/day but it would probably cost a lot. anyway,  this leaves a small gap of time inbetween closing and opening where 'nothing happens'. I suggest that we use this 'downtime' for recalculating the game world. This would include all the things that were too complex to handle in real-time. for example, you weren't planning on recomputing the popularity in real-time were you? so I think that all the things which relate to how the 'city' changes from day to day should be done here rather than in real time. it would allow you to program in functions that would analyze what happened during the whole day rather than at each instance, which would free up more processor time for all the normal gameplay elements: moving customers and employees around. I also think that the building phase should be done here rather than in real time, unless you can figure out a way for people to smoothly carry on business while rooms disappear or are added, and while a TV set just happens to appear where a customer was standing...you get the idea. it just seems like it would be easier to program that way, updating the employee's/customer's model of the building once per day, but if you think it's important for the players to be able to build whenever they feel like it, then realize that it's going to complicate things a bit. All of this should really only take a few seconds to calculate, and we can play an animation or something to distract the player, like a person placing a 'closed' sign in the window and walking outside , then locking the door, etc. basically, my concern is that it might be too demanding to have to recalculate AI strategy, city dynamics, etc. on the fly while the game engine is still running at full speed.
Posted by: inconspicuous Posted on: Apr 9th, 2003, 12:03am
glad you like the idea of a customer getting food poisoning, cuz I was really hoping to get a chance to animate that!
 
I agree that we shouldn't take control away from the player, but the reason I suggested that ordering be limited to once/week was to force the player to plan ahead a little. in real life, ordering shipments usually happen every week, but in the game we could let the players place an order whenever they wanted to as long as we preserve the notion that they still have to plan ahead. this could be done by making the ingredients arrive THE DAY AFTER they're purchased, so that there is a minor inconvenience for not planning ahead, but one which can be solved by the next day rather than having to wait an entire week to remedy.
 
I like the idea of a scrolling newsticker on the screen, and would like to hear more details about that. if you don't read a message, can you scroll through a log to see what you missed? what kinds of events are 'newsworthy'? how do you differentiate messages about specific restaurants(if you have a franchise)?
 
I'm not sure what you meant when you said that the expired ingredients would be tossed out automatically. I was thinking that it would be the manager's job to do this, so that if you had a good manager you wouldn't have to worry about anything. besides, players aren't going to want to take on the job of throwing the bad ingredients out. their job should be to make sure that the manager is throwing them out by checking for expired ingredients still in the warehouse after they've been notified that some of them went bad. is this what you meant?
 
and what kind of display are you thinking about having for the warehouse? I thought each restaurant would manage its ingredients seperately, but that might be too hard on the player. either way, I imagined that the ingredients were stored in an actual room that would look like a walk-in refrigerator: visual icons for each topping would be arranged in stacks, with stack height corresponding to how many of each ingredient you had. or the icons could be painted on boxes, and each box would represent a certain number of those ingredients so that you could tell at a glance if your stack of cheese boxes was running low. and I imagined the poison sign appearing over this icon if something was expired. were you thinking of only showing the ingredients by a bar graph or something?
Posted by: ares32585 Posted on: Apr 9th, 2003, 1:23pm
Well, firstly restaurants will be open continuously.  That is, they will be open 24 hours a day:  they will never close.  This is so that there will not, in fact, be any "downtime."  We don't want to force the player to wait for anything when simply having the restaurant be open 24 hours a day would remove such a wait.
 
Quote:
so I think that all the things which relate to how the 'city' changes from day to day should be done here rather than in real time. it would allow you to program in functions that would analyze what happened during the whole day rather than at each instance, which would free up more processor time for all the normal gameplay elements: moving customers and employees around. I also think that the building phase should be done here rather than in real time, unless you can figure out a way for people to smoothly carry on business while rooms disappear or are added, and while a TV set just happens to appear where a customer was standing...you get the idea. it just seems like it would be easier to program that way, updating the employee's/customer's model of the building once per day, but if you think it's important for the players to be able to build whenever they feel like it, then realize that it's going to complicate things a bit. All of this should really only take a few seconds to calculate, and we can play an animation or something to distract the player, like a person placing a 'closed' sign in the window and walking outside , then locking the door, etc. basically, my concern is that it might be too demanding to have to recalculate AI strategy, city dynamics, etc. on the fly while the game engine is still running at full speed.

 
Well, having the game run at full speed the entire time will provide some interesting challenges.  However, I really do not like the idea of having a time period when the restaurant is "closed."  We discussed this on the IRC channel at one point earlier on, and we came to the decision that providing such a break in the day is unnecessary and somewhat jarring.  Once the player's having fun we don't want to suddenly stop the fun by having the restaurant close:  we want the player to be able to play continuously.
 
As for placing items where customers are, where employees, etc, this problem can be solved by simply not allowing items to be placed where people are currently at and not allowing items to be moved that are currently being used.
Posted by: ares32585 Posted on: Apr 9th, 2003, 1:28pm
Quote:
I'm not sure what you meant when you said that the expired ingredients would be tossed out automatically. I was thinking that it would be the manager's job to do this, so that if you had a good manager you wouldn't have to worry about anything. besides, players aren't going to want to take on the job of throwing the bad ingredients out. their job should be to make sure that the manager is throwing them out by checking for expired ingredients still in the warehouse after they've been notified that some of them went bad. is this what you meant?  

 
Firstly, we've decided to remove the manager as an employee from the game.  As we intend for the player to perform many of the functions in the game that a manager would in real life, it got to a point where there were no real tasks for the manager to do.
 
What we meant about having the ingredients automatically tossed out is that when the ingredients expired, they are simply removed from the pool of ingredients to be used.
 
The ingredients would never be seen being stored anywhere in each individual restaurant.  The player tells how many ingredients he has remaining in the warehouse by looking at some info that tells him that:  basically some sort of chart.  There is no explanation for how ingredients get from this central warehouse to each individual restaurant:  when a cook at a restaurant needs an ingredient, it's "magically" available at the restaurant.
 
Also, judging from some of your questions, I assume you don't have access to the updated design document in CVS, so I'll provide an updated PDF file of the most recent design doc, as many of the questions you bring up have already been pretty much decided and put in the design doc.
Posted by: ares32585 Posted on: Apr 9th, 2003, 1:33pm
Here's an updated game design doc:  http://pizza-business.sf.net/GDD.pdf
 
Also, keep in mind that we are open to making changes to anything in there if we decide that it would be in the best interest of the game.  So just because we may have discussed something on IRC and decided something, doesn't mean that we won't change that aspect of the game if we feel that something else will work better.

Pizza Business Forum » Powered by YaBB 1 Gold - SP 1.2!
YaBB © 2000-2003. All Rights Reserved.