Programming (Week 5)

DEC. 30 – Jan. 6

Monkey see …

I started this week by looking at the game files for the game that is our main inspiration – Hearthstone. The only relevant files that were not encrypted were the XML files. I had hoped to find the main files for cards, but it seemed as if those were either not saved as XML, or split between so many files that I could not puzzle them together. I did however find out that they don’t have different elements for the different properties of the cards, but instead differ between them with different values for the “field” attribute.

… Monkey do.

I thought about changing my XML to the way Hearthstone did it, but decided against it, because i saw no reason to do it. I did however spend some more time on changing the names of the attributes of each card, to better reflect, and more clearly explain their function.

I got the core XML functionalities running to the point where I could load cards from the XML document and display the values on a card-mockup.

xml loading

The importance of examples

During our meeting on Monday we found out that we had different concepts of one of our Resources, “Profit”. Some of us understood it as an accumulation of the player’s income, and the others as cash-flow. This explained why we had such different ideas of how it would be used. After I explained to the others how I imagined Profit as cashflow to work, we decided on using that.

I learned that whenever you talk about a game mechanic like this, you should make some kind of example, perhaps do a few turns of mock-play to see if everyone is on the same page.

Programming continues

For this project I decided to write every class in their own Script, like Card and CardSlot for clarity and neatness.

During programming I often noticed things that we hadn’t talked about before. I was wondering whether this was fine, or whether we should have planned ahead more. One of these things was showing buffs or debuffs on certain cards, for example if you were to use an event card that increases profit of a structure, that change has to be somehow shown on the card.

I also get to make small gameplay decisions all the time.
For example, I decided that the chance for a card that is randomly inserted into a deck would be a tiny bit (like 0.000001%) higher to be inserted at the top than anywhere else. This is due to the way probabilities are calculated in programming. I could have chosen any location to be this tiny bit higher, but the top position was the most fun imo.

One of my favourite things in programming are named and optional attributes. They allow you to keep method calls short if you do not need all parameters.

1 thought on “Programming (Week 5)”

Leave a Reply

Your email address will not be published.