Rock, Paper, Scissors, Images!

After creating my first decision making game, “Rock, Paper, Scissors”, I wanted to move beyond the text based method that I had used before. As an improvement on the original I decided to add images to the gameplay. This would allow a much richer game play experience and one that would not be dependent on the keyboard, making my game suitable for touchscreen and mobile platforms. Now all you have to do is click on your choice which is passed to the game as a number that determines which of the three objects is picked out of an array.

Click on your choice below to start playing the game:

paper scissors rock

The Prisoner’s Dilemma

Decided to implement a game that I had wanted to do for a long time. I initially wanted to do Mad Libs but decided to start with a switch based game. I decided to combine switch statements with operators to create a prisoner’s dilemma game. There are two versions: one requiring two humans and the other using a computer opponent for a wild card factor.

A more complex game could involve more and more players resulting in factions forming and certain people implicating others while denying their own involvement. The police could also offer incentives that could reduce the severity of punishment, i.e. some gets a good recommendation or immunity for implicating their partner AND confessing. Right now the game only allows someone to do one action at a time. Plenty of people admit their role in a crime and say their partner had something to do with it as well. There is also the possibility of going through more than one cycle. Based on player B’s response, Player A could receive a hint that Player B’s decision will negatively impact them. They could then decide if they want to change their response and perhaps obtain a more favorable outcome.


Taking an interest

Working with ‘while’ loops made me think about an old problem that still requires a brute force solution even with all the advances in math and computer science. There are simple formulas for determining the interest generated by a certain amount of money over x years, but compounding is a much more complex problem. If interest is compounded every year, then the principal is changing in an exponential way and simple formulas no longer suffice because they do not take into account the necessary information. In order to find out the total balance 15 years in the future, for example, you need not only the initial balance and rate but what the balance was in each of the previous 14 years (since each year’s balance depends on the previous year’s balance plus the interest earned). While working with ‘while’ loops, I decided to apply them to a brute force problem like compound interest. The result is below:

Future Balance Calculator

What was your balance at the end of 2012? $

For what year do you want to know your end of year balance?

What is your interest rate? %

You will have a balance of $ at the end of

Objects are the objective

Started exploring the use of objects in Javascript, something I had heard of before when referring to computer programming languages but hadn’t really been exposed to while learning them. At first I wasn’t sure how to employ objects, and then I learned about the ability of objects to contain variables and functions in a single container.

I was surprised to hear that objects could contain variables and functions in the same data structure. Then I remembered that I had written functions in AutoLISP that executed other functions. Some of my programs for AutoCAD were built on smaller programs that I wanted to be self-contained instead of piled into one large block of code. For example, a program that organizes a raw text file into a usable list in AutoLISP…

(defun prog04a ()
(c:vt)
; file to read
(setq fh1 (open “I:/LISPDATABASE/StatesID.txt” “r”))
; Ignore first line
(setq stnmlist (list ))
; Begin transcribing
(while fh1
(setq nline (read-line fh1))
(if nline
(progn
(setq d1 (atoi nline))
(setq d2 (read (read-line fh1)))
(setq d2 (atoi d2))
(setq d3 (read (read-line fh1)))
(setq d4 (read (read-line fh1)))
(setq d4 (atoi d4))
(setq d5 (read (read-line fh1)))
(setq d6 (read (read-line fh1)))
(setq stnmlist (append stnmlist (list (list d1 d2 d3))))
)
(setq fh1 (close fh1))
)
)
(princ)
)

…is executed in another program with a call after the list it feeds data into is created.

(defun prog04 ()
; file to read
(setq stnmlist (list ))

(prog04a)

(setq fh1 (open “I:/LISPDATABASE/States.txt” “r”))
; Ignore first line
; Begin transcribing
(setq ncolor 0)
…….

Going through some other AutoLISP programs I created I found that I had often created small programs to do some kind of prep work, usually preparing data, that I then used in another program. Most of the time the end program still executed a large amount of code, but the combination of variables and program references stored in a single block reminds me of an object.

I have noticed that objects are different in the sense that they are not executable themselves. My master programs that relied on executing smaller programs first were still programs. They had to be run in order to be useful, whereas I am discovering that an object can be a very complex container of data that is both executable (functions) and static (variables).