Zleef's Blog

HW 6

zleef — Tue, 03 Mar 2009 06:02:28 +0000

So I was really busy doing a serious update of the game, and wasn’t able to implement both the visitor pattern and state pattern. You can see the “planning documents below (sorry it formats it so weird on here, i’ll attach a pdf document for easier viewing) to see where i’m going with this. I really just needed more foundation for the game play.

The visitor pattern is used for printing out a specially formated list of the ingredients in a specific soup.

The state pattern will get added soon. What my initial plan for it is to use as a “game state” for displaying different menus depending on if we’re in the start scree, settings, or gameplay, etc…

I’m having a bit of trouble in the Preference class. Basically what i want to happen is when a customer is created they’ll get an instance of Preferences. When the preferences object is created i want it to go and look at all the ingredients that are used in the store (i.e. for a polymorphic approach i’d like it to – in the future, be able to have a number of soups created each with various ingredients. (side note on a side note: i’d like each ingredient to implement a set of “tastes” or something so that you could create additional ingredients and then from the interface there’d be a couple of things that you’d rate the ingredient on for example it might be like salty, sweet, savory, filling, healthy, tasty or something like that and then each ingredient would really only be an object that contained different values for each one of those). When the soup was added to the store, there would be a scan of the soup to see if there are any ingredients used in this soup that haven’t been used before, and if so add them to our list of supplies (store.Supplies) ). and then create a random number between 0 and 100 to use as its preference for this ingredient (i.e. how much it likes that ingredient) later in the game i’ll determine if the customer likes the soup by testing if the amount of the ingredient in the soup is within range of their preference. The way i’m setting this up is by using ai.Preferences.setPreferences() which will take in a list of all the supplies (ingredients used in the store) and then put them as the key in a hashmap along with a random int between 1 and 100 (which will be there actual preference). Where the actual problem is happening is when i go to get a preference (ai.Preferences.getPreference() ) it’s throwing errros about how it can’t be cast into an int.

I know this is kind of a belligerent explanation of the problem, but if you can make sense of it and offer any suggestions that’d be great. Thanks!

Additional Planning Documents (pseudo re-factoring)

zleef — Tue, 03 Mar 2009 05:41:52 +0000

The formating is horrible on the post so i attached a pdf of the actual document:

<< game-planning-document.pdf >>

======================

Setup

Player Options

Set Amounts of each Ingredients
Set Cost of Soup

System Options (Constants)

GAME_LENGTH //length in min. of the game.
NEXT_WAVE_IN //length in min. of how often a new wave of customers comes
IMPULSE_CHANCE_RANGE //what the random number range will be
IMPULSE_CHANCE //which number out of impulse range gives them a impulse buy
IMPULSE_AMOUNT //$$$ how much more the customer is going to spend with an impulse
PRICE_DEVIATION //determines the deviation of what a customer is willing to pay
PREFERENCE_DEVIATION //deviation of what cust. will like according to their set preference

======================

Start Simulation

Runs for two minutes
<>
Create a new store and add a soup to it.
Create a new customer driver.

======================

Create Customers

Every ten seconds a new wave of customers is created.
- Every customer is given a set of preferences, a possible impulse purchase, an “intuition,” and also a “life”.
  - The preferences will be a random int for each ingredient and the amount of money they’re willing to spend.
  - The impulse purchase will be selected at random at customer initialization.
  - Their intuition is a timer that determines when they’ll go up and order. If it’s set after their life has expired they’ll never order (i.e. they’ll just become a loiterer). We should run a test before the intuition timer is initialized to determine if they’re going to be a loiterer and if so don’t start the timer so we don’t wast resources.
  - The life is basically a timer that describes how long they stay in the restaurant. Once the timer runs out, they gracefully leave the restaurant by unsetting the intuition timer (if applicable), (exiting GUI [animation]), and removing themselves from the list of customers.
The number of new customers is based on a Random number between 1 & 10 and is weighted by popularity. So initially (at popularity 0), at max only 10 customers would show up.
- Popularity starts at 1 and then goes up indefinitely, it can’t be set at less than 0 so that it’s not impossible to recover from no one liking you (i.e. if you got negative -10 popularity then you would have zero customers coming in and have no one to increase your popularity).
  - This will be set very primitively: every customer that likes their meal will add 1pt to popularity, and customers that don’t enjoy it will decrement it by 1. If by some chance everyone of the ingredients matches the customers preference we’ll add 10.

======================

Interaction

Interaction will be what the customer does in the restaurant.
- - + interact()
    - this will control the process of interaction. it’ll first call wantsToOrder(), then order(), then finally consume().

- - - wantsToOrder()
    - This will decide it the customer wants to place an order.
    - It will consult the price. If the price is within their deviation it will decide its a good idea to buy it.
  - - order()
    - Create a new instance of the soup which will increase the total number of soups purchased and the revenue.
  - - consume()
    - Determine if the ingredient amount is within the deviation of customers preference for each ingredient (iterate through the list of ingredients and check each one.) If the majority of ingredients fall within the preference range then add 1 to the popularity, else subtract 1.

======================

Score

Total sales
Total Revenues
Customers vs Customers who Purchased
Customer Satisfaction
- “x” Customers liked your soup
- “y” Customers disliked your soup
- Your approval rating was (approved_customers/total_customers) * 100

======================

How to implement the decorator pattern:

zleef — Mon, 16 Feb 2009 20:42:04 +0000

Determine the class you want to be able to decorate, lets call this parent class: “A”.
Create a sub-class of A, to be the base-decorator class. In the constructor you should set a reference to the original object. The class should also shadow all of “A” ‘s methods by simply returning the reference to the original objects method plus any additional information you want to add to it (this is probably what you’re “decorating”).
Now you can create your decorators by extending the decorator base class. Here’s where you will actually probably be tweaking the original methods, or creating new ones that manipulate the original objects attributes.
To actually decorate an object you must first have an object created:
Object obj_a = new Object();
Then simply switch the reference to the decorator while passing the reference to the original object:
obj_a = new Object_decorator(obj_a);

My use of the decorator pattern

zleef — Mon, 16 Feb 2009 20:31:15 +0000

I’ll get this up later today, but if you run across this before… my implementation of the decorator pattern is in the Customer package — Impulse_Purchase

My adaptation of the Observer pattern

zleef — Mon, 26 Jan 2009 20:35:08 +0000

While there’s not a whole lot of excitement going on at the moment with my game, the foundation is now much more concrete. I’ve setup the program to have Customer_Driver notified when the popularity of the soup changes, which will eventually result in an adjustment of how many customers are coming. Currently you’ll see that the driver creates an instance of soup and customer_driver and then proceeds to update the soup’s popularity, which then prints out an acknowledgment from customer_driver that there has been a change.

How to implement the Observer Pattern:

zleef — Mon, 26 Jan 2009 20:27:17 +0000

Determine what object’s data that other classes need updates on (this object will be Observable).
Determine the classes that will receive the updates of the data change (these objects will be the Observers).
Have the Observable class extend java.util.Observable
Within the method that updates the data you wanted others to get notified (i.e. where ever it is that the data gets modified), place a call to setChanged(); and notifyObservers();
Have the Observer classes implement java.util.Observer
Create a method called update that does something once you get notified.

Game Refactoring

zleef — Mon, 26 Jan 2009 19:03:01 +0000

So after working on the second hw assignment I decided that my game needed to be simplified quite a bit. So i kept the restaurant/food theme but switched the actual game to a “Soup Stand.” The game play will be still that of a simulation — the player will create soups by changing the amount of ingredients in a particular soup (vegetables, meat, water, seasoning) as well as the price. Each customer that purchases the soup will “review” it which will affect the soups popularity. The more popular the soup the more customers that will come, and the more willing they will be to spend more money.

Here’s the little blueprint i did to help plan the class structure:

Soup

This class represents the soup object. It’ll hold all the information of the actual soup. The user will be able to change the price, and all the ingredients. The customers will have a preference on what they like in their soup, and how much they are willing to pay. The closer the actual values are to the customers preference the more popular the soup will become (resulting in more customers).

Price: float value
Vegetables: int value (1-10)
Meat: int value (1-10)
Water: int value (1-10)
Seasoning: int value (1-10)
Popularity: int value (1-10)

adjustVegetables(int change)
adjustMeat(int change)
adjustWater(int change)
adjustSeasoning(int change)
adjustPopuarity(int change)
getPopularity()
popularityChange()
-notify observers that there has been a change in Popularity.

Customers

This class is pretty strait forward. It’s the object to represent customers.

· spendingTendency: if they are willing to spend more money or not.

· vegetarian: Boolean

/** This basically determines if they are going to purchase a bowl of soup or not*/
Order()

Spend Money
Determined by how
Don’t Spend Money

/**Every customer will “review” the soup once they’ve purchased it. This will affect the soups “popularity”*/
Review()

Indifferent
Like
Dislike

Customer_Driver

This class will be the AI for creating customers (i.e. how many customers there are at one time, what the personality of the customer is, etc)

createCustomer()

dynamically create a new customer

creator_frequency()

observe soup popularity and determine how often to call createCustomer()

Tradeoffs of standard OO & Using the Strategy Patterns.

zleef — Thu, 15 Jan 2009 20:08:54 +0000

In the textbook, the character “Joe” was facing a problem with scalability. The SimUDuck application has reached a point in which Joe & the other developers must decide between functionality or manageability. If they wish to add new behaviors (such as ways of flying, or types of quacks) they must sacrifice manageability as they’ll have to go through each sub class and modify custom methods. If they were certain that the SimUDuck would not be developed further, then employing the Strategy Pattern could possibly be overkill. For it wouldn’t be all that bad to override the fly() method on one sub class (RubberDuck). But because the application still had life and was likely to become bigger with different types of ducks it would be much simpler to use the Strategy Pattern. In other words, when using the Strategy Pattern at the early stages of an application it might seem like overkill. However the true payoff of the pattern is how scalable it makes a program. Expanding in the future becomes a breeze….

Oliver

zleef — Thu, 15 Jan 2009 19:24:28 +0000

I just found oliver… “It’s” the cat observer found on the copyright page.

Executive Summary of Individual Project

zleef — Fri, 09 Jan 2009 08:29:57 +0000

Introducing “Gastronome,” the restaurant simulation game.

I almost never entered the world of computer science. Originally i had intended to enroll in the CIA, Culinary Institute of America –not the intelligence agency (not as much spying, but much better eats), but at the last minute switched back to the traditional educational route. While i’m far from Hyde Park, NY, I still greatly enjoy to cook.

I’ve always enjoyed the simulation games –Sim City, Red Alert (kind of a hybrid simulation/traditional game), and just about every ____ Tycoon game. Lately, i’ve really enjoyed the defense games where you are trying to stop some type of army from reaching the other end of a maze by strategically placing various weapons that freeze, blow up, shoot down, and otherwise destroy the villains.

As soon as i saw the project i knew i wanted to incorporate my passion for food into the game. I already have many ideas for game expansion, so i’ll have to make sure i limit myself to a achiveable scope.

Summary

The game starts off by setting up the game foundations — Name of the Restaurant and game difficulty (which would be how much money you start with, and speed) would be the only things for this version of the game, but i in-vision additional options such as restaurant type (dessert, mexican, bar, etc) where your menu would reflect the type of restaurant you are.

Typical game play would be configuring the following menu items to find a synergy of success:

Staff (waiter, hostess, bartender, head chef, sou chef, prep chef)This is where you would hire/fire people. Every position would have something like 3 upgrades that could be “purchased” for more money, or rather you would be expensed more on a regular basis.

Operations (hours, light level, music, decor)Here is where you setup the character of the restaurant. What time its open, how late its open. The ambiance,etc.

Ethics (3-second rule, pay off food inspector, professionalism, bribe food critic)Choose to be either ethical or unethical. Several different options that affect the short-term and long-term success of the restaurant. If they choose to do something unethical it will benefit them immediately (most times), but may come back to haunt them. For instance if you bribe a food critic you’ll see short term success, but later they might confess and give the restaurant bad press.

Menu (available categories[appetizers, entrees, dessert, drinks], available dishes) Here you can purchase new menu items. The initial menu would include one appetizer, one entree, and one dessert. Once they make money they can purchase more items.

Recipes (for all dishes purchased, tweak the recipe to use more or less of certain ingredients)Once they purchase menu items they can alter the recipe. It would be a sliding scale for how much of an ingredient (salt, eggs, milk, seasoning, produce –very generic things) goes into something.

Stock room (order ingredients for the food / beverages) This part might get omitted if it proves to be to difficult. The concept is that all the ingredients that a person uses in the recipe, would have to be purchased here. Therefore, if they don’t have enough on hand during a meal rush they wouldn’t be able to serve that dish anymore (which would irritate the customers, and they just generally wouldn’t sell as much).

The flow of the game would consist of the player configuring the restaurant settings, and then starting the day. the day would be dependent of how many hours the player chose to keep the restaurant open. the longer the restaurants open, the more it costs (all the staff is per hour) but you can also make more money if you have the right stuff. for instance, you can get away with being open later if you have more drink items on the menu. At the end of the day you’ll get a quick earnings/losses statement with a little break down of the numbers, and then you’ll be able to re-configure the restaurant settings. Durring business hours, no adjustments may be made to the settings, however they’ll be able to monitor how much ingredients is on hand and whats selling (and when it sells)…

Hierachies

Locations: the two main locations will be in the “control panel” portion of the game where the player configures all the settings, and then the sandbox where the game simulation occurs. As the control panel has already been described in pretty good detail, i’ll talk a little bit about the sandbox. First off, obviously the name will have to change to something more flatering then sandbox. But thats all i’ve got at the moment to describe it. The player will have the option to speed up the day so they don’t have to watch it crawl by. The game speeds will be normal (1 sec = 1 min), fast(1 sec = 10 min), instant(everything is instantly calculated and no animation occurs). When observing in normal or fast mode however, the player will see a layout of the restaurant and some sort of animation of customers walking to the table, staying at the table for the course of the meal, and then leaving. Since i’m not a graphic design person, the people will probably consist of dots, and the tables squares.

Action: this will be most of the game, as many different actions must take place. A couple to think about would be a food inspector/critic coming in. They would affect people’s opinion of the restaurant. Another event could be a food poisoning, again resulting in negative opinions. Something positive might be a celebrity attending.

Animate objects: the customers, the staff. The customers would have a grading scale that they would come pre-programed with. The scale would determine how much they liked various parts of the restaurant. For instance, they might have a very high priority for salty foods, or low light, or high prices. The closer the restaurants settings were to the customers scale, the more overall points the restaurant would score. The more overall points the restaurant had, the more customers they would be eligible for (i.e. more people would come).

inanimate objects: dishes and ingredients. I go into a good bit of detail earlier of what this entails…