#vector valued functions are my enemy
Explore tagged Tumblr posts
Text
So close to dropping Calc 3 🤩
2 notes
·
View notes
Text
GDevelop Platformer Development
For Moon Jumper, the technical basis is the simple platformer game that was outlined in IGB120’s week 2 workshop. This game gave me a really good starting point to building my game, giving it a controllable player character, simple platforming moving mechanics, collisionable platforms, functioning enemies, and art assets. A lot of this is useful for the game I want to create, outlined in my Elevator Pitch post.
The first thing I did was update some of the assets to create a visual style more in-line with my vision. Some of the assets, especially the astronaut player character from the tutorial assets, were fitting enough. I created a black background image with white dots scattered about it as the backdrop of space and found a cartoonish moon texture that I could use as the tiling platform texture.
Once I had a quick, clean visual upgrade, I began working on creating the movement mechanics. Since I knew I wouldn’t have much time for this particular game, rather than adding a bunch of different features and completely fleshing the game out, I opted to treat it as a gameplay prototype for the movement mechanics. I used some of the information from chapter 8 of the textbook, which details digital prototyping, as a basis for this. I knew my control scheme wouldn’t change, and the game wouldn’t need major technical prototyping, so I focused mainly on gameplay mechanics and kinesthetics.
The first thing I did was add a simple “bouncing” mechanic, making it so whenever the player came into collision with a platform, it would simulate the jump button being pressed. By also lowering the gravity of the player character in the behaviors tab, I accomplished the bouncing and floatiness feeling I was looking for. I could even control the player slightly by moving left and right.
Finally, I made it so that when the player hits “space”, a strong force is applied downward, shooting the player towards the ground, giving them more control over the movement. This was the basis for my movement, but I knew it would require a lot of iteration. To playtest this simple movement, I built a small level, placing platforms and monsters down. This allowed me to change my mechanics, mostly by changing values like the amount of gravity, jump speed and time, and the force applied when pressing “space.” By playing the game and making changes accordingly, I was able to get the movement to a place that I think is pretty fun. However, I believe the game requires more playtesting to figure out what features to change and add and how to fully fine-tune my movement.
Final movement result. As you can see, the current mechanics allow the player to bounce off the side of platforms, which, in my playtesting, was quite fun.
Application of Fullerton Textbook Theory
While developing this platformer, I had chapter 1 of the textbook firmly in mind, especially the ideas of chasing the fun and advocating for the player. I continuously changed designs and tweaked my prototype to make the player character's movement as fun and responsive as possible. A critical part of the chapter I kept in mind was “Setting player experience goals” In particular, I wanted the player to feel like their control over the character was unique and floaty. By decreasing gravity, making the player near weightless, I achieved the “floaty” feeling I sought. And by playtesting my game and tweaking movement variables, I was able to make that feeling fun.
Fullerton, T. (2018). Game Design Workshop: A Playcentric Approach to Creating Innovative Games. ProQuest Ebook. Retrieved from: https://ebookcentral.proquest.com/lib/qut/reader.action?docID=5477698
Moon texture retrieved from https://www.shutterstock.com/image-vector/moon-surface-texture-beautiful-banner-wallpaper-636994813
Other assets retrieved from IGB120 Workshop 2 https://canvas.qut.edu.au/courses/21200/pages/igb120-w2-workshop-introduction-to-gdevelop-platformers?module_item_id=1928114
0 notes
Text
Dungeon Crawler - 17/10 - the finale
Today is the last day of development and so I am going to be cleaning up the stuff with the build system and the upgrade screen, preventing the player from shooting themselves to death, try to fix the long lasting bug where the enemies decide not to shoot and more.
So starting off with the enemies, I changed the recovery time from 1 to 1.8 so that it isn't a frequent thing, but if an enemy has been hit and is moving really slowly - they can recover. After they have recovered once, the time taken to recover is doubled.
Now for the issue I have had since the start; sometimes the enemies will just stop shooting. After looking through my code a bit, I noticed that to shoot; the enemy needed to be completely still:
So I thought it could help to have the velocity set to zero whenever the enemies isn't being hit.
From looking at these two screenshots, you might see that I am using two different vectors: this is because it vector2 will only monitor the x and y values while vector3 does x, y and z. As it didn't really matter if the enemies are moving along the z axis (which they can't) but just incase I reset all of the values.
Anyway this seems to have fixed the issue!
Now for the player stuff. I reckon a solid 33% of my deaths while playing my game has been from killing myself by shooting (to put it a little clearer; health = ammo, when ammo = 0, health = 0). So I made it so when the player has only 1 ammo, they can't shoot and it'll play a sound to let them know. Pretty simple stuff.
I also increased the player's move speed from 3 to 3.5 because it was a bit of a bore getting from room to room. I also want to change how the rooms are generated a bit. So in the player movement script, I increased the amount of things that can spawn in each room from 1-2 to 2-3 as there were not many rooms where it would have a different layout and enemies in. However I also have to decrease how many enemies, materials, etc can spawn at once since its going to be doing this up to 3 times. So the enemies have gone from 2-5 to 2-4, the materials have gone from 1-6 to 1-3 and the gems have gone from being a 1/30 chance to 1/40 chance and cannot spawn on the first 3 rooms.
Something I don't have yet is a game over screen, so i'll get on that...
So I got the game over screen, and its simple but it does the job (plus it fits in with my theme).
And here we control what happens when the player dies:
The variable "playerIsDead" is used to turn off the stuff I dont want to use when dead, like shooting and moving. Also the reason I delete the enemies is that they themselves make a lot of sound, and I don't want the player knowing this is just a screen I put over the game.
I also made reloading the scene into a function so I can access it from my button in the game over screen.
After some more play testing of my own, I decided that I made the gems too rare so I changed it from a 1/40 chance after 3 rooms to 1/20 chance after 5 rooms.
In an attempt to steer away from the building aspects, when you collect a gem, the upgrade screen will pop up and the player can buy upgrades using their ammo.
I also made it so that the enemies will spin whenever you hit them, just for visual effect.
I added the 3rd and final upgrade, which is a chance to dodge an enemy bullet.
And finally, I published my game to Itch (where you can play it WITHOUT downloading anything). Click the link above to go to my itch page.
0 notes
Text
Tutorials & Planning: Hologram Design
Holographic effect: This video explains how to create a holographic material and then add this to different actors/blueprints in UE5. I will explain a step by step but you can also watch the video for clarification. I will do another step by step later on in the project of how I put it together. For now this is just a step by step. I intend for the holographic enemies to look like this in the final section of my game. This is probably the best solution I could find because otherwise I struggled to find anything.
Create a brand new material and name it Hologram
Once in the material, set it's blend mode to translucent
Then create a generated band node and hold down S on the keyboard to make a parameter node and name the value of this node (Width).
Once this is done, connect these two nodes together.
Then, add an Add World Position node and hold down D and click to create a divide node. You also will need a Parameter to connect to this too.
The next step is connecting all of this together. To do this, you first connect a mask node to the code in the previous step and make sure the blue and green of this node are ticked.
Add a Panner node and set the Y value. Connect this code to the input coordinates on the Generated Band node. When previewed this should create a hologram like animation on the material.
Copy this code and change the name and values of these so there isn't a mix up in the code.
Hold down A on the keyboard and create an Add node and join each Generated Band node.
Make a constant3vectornode and a Texture Sample node and set the default texture.
make another Panner node and connect this to the UV on the texture sample.
Convert this texture sample to a parameter and change the colour of the vector to a colour of your choice
Join both these nodes to a multiply node
Add a blend overlay and set this to preview after connecting it and this will change the hologram a blue colour making it more realistic.
Add a Frensel Function node and join this to a power parameter. This will give the hologram a glowing border around it.
Add a texture sample and add a static material provided with the starter content.
Create a text coordination and a multiply node. Add a screen position node and another multiply node and join these all together.
Add a Panner node and Join all of these together and add another multiply node. When previewing this creates a static glowing outline around the hologram making it look more translucent.
To join everything together, Add multiple Add and multiply nodes and plug one of the add nodes into the Material node itself under the Immersive colour section.
Bonus Step: To make the hologram more see through, add an opacity node and set the value quite low and connect this to the opacity section on the Material node.
youtube
1 note
·
View note
Text
Programming weapons [oh god]
For all of the tapes, I need to summon 1 or more projectiles. To do this, I'd need to create and spawn the projectile, make it do a line trace from where the camera is and is pointing to a distance specified by a bullet distance variable. It will then need to travel that distance. There also needs to a delay between firing, and on shotgun blasts, there needs to be a 'spread' mechanic.
This is how I programmed the bullet being spawned and working out where it goes. 1.1 is Tape 1 Primary, so the Scout Tape shotgun blast. Once this event is called, it spawns a pellet in the direction and location of the camera and then works out, also from the camera location and direction, how far and in what direction to go.
This is how I programmed the fire rate. The player character has two variables called fire_rate and canshoot. fire_rate controls the time until the gun can be fired again as it's used as the delay between canshoot turning on again, and canshoot is turned off after firing for however long fire_rate is and the gun can only be fired if it's on
I, eventually, managed to make the bullet move via a Projectile Movement component. In here, I could set both the starting and max speeds rather than attempting to use timelines.
Unfortunately, for some godforsaken reason, bullets cannot be fired at an up or down rotation, so all bullets can only fire directly forward
[this was fixed by changing the Get Forward Vector node to reference the camera rather than an arrow]
This here abomination is how I program the spread. Effectively, the computer gets a random number between two variables, adds it to the camera's Y and Z values and sets that to the rotation when a shotgun pellet is spawned. This occurs 7 times, so 7 pellets are spawned
This was how I fixed the bug that caused enemies to be invulnerable at extremely close range. From what I can tell, this was due to the pellets spawning inside the enemy's hitbox so never actually starting to overlap it. Effectively, it just spawns the pellets slightly behind the camera.
This is what happens when my enemy takes damage. If this damage kills the enemy, it explodes and the enemy is destroyed. If the damage is non-fatal, sparks are produced. Unfortunately, despite my best attempts, the sparks linger after actor destruction. I do not know why.
This code controls how much damage is taken by checking what the enemy was hit by and applying the relevant damage.
This is the code for the knives thrown during the sniper's secondary attack. The Z angle at which they're thrown is based on a variable that increases by 5 degrees every time one is thrown before resetting after all knives are thrown, creating a symmetrical arc. I added this to give the dash ability more use.
This is how I initially programmed the Scout's stun mechanic. My thinking was that it would function as a stun baton, forcing the player to get close to stun the enemy. However, due to technical restrictions [AKA: I don't know how to control the line trace range or apply stun], I elected to make the stun mechanic a projectile. After all, the player is already getting up-and-close to use the shotgun blast, so the stun's range limit is redundant.
uh oh
0 notes
Text
passim, a blurb from a network
“A coup d’état is sanctioned as it were in the opinion of the people if it is repeated” – says Hegel in the “Introduction to The Philosophy of History”. This opinion is a serious stake, for with the sanction in question the history leaps forward. “Thus, Napoleon was defeated twice and twice the Bourbons were driven out. Through repetition, what at the beginning seemed to be merely accidental and possible, becomes real and established”. Then we see Marx opening his “Eighteenth Brumaire” with famous “Hegel remarks somewhere that all great world-historic facts and personages appear, so to speak, twice. He forgot to add: the first time as tragedy, the second time as farce”. There’s a strong drive, in other words, in the world of the mortals to “get real” by means of caricature. The event is not enough, nor is the myth. A debasement is needed, be it only through a remark – found passim, with dignity of at most a gossip – which nonetheless points at something that's, seemingly, grounded and, apparently, operative. Con-firmed. Now – could we perhaps, in a provisionary way, take the psychoanalytical endeavour as means to flesh out our exaggerations? swarming, yet not palpable? Like a cartoonist who picks on the recognizable and leads it to the constatation “that’s true!”, and one that is palatable at that? Here’s a pick from the very discourse. Bracha Ettinger remarks somewhere that the deep model revealed in Lacan’s exposition of the lamella myth is the libidinal model of subject versus object – since the maternal in it, for a subject, is an object, and her body a partial object – a setup Ettinger aims to “shake a bit” with the matrixial approach. Neologisms are among the means put to the task. But also questions: is the basic human erotic tendency towards the object? or is it towards linking with objects? or is it perhaps towards the linkage itself? „What we miss is not an object but a type of linking”. This resounds with Aaron Schuster’s remark, made elsewhere, that what we’re lacking is not an object of desire but the very ground from which we could, finally, desire. The surplus value of these remarks lies, paradoxically, in grounding the elusive nature of that weird concept which is lamella, rendering an organ whose function is to go further than the body’s limit (through collapsing the boundaries of the individual autonomy). A closer inspection reveals a question that’s still, in its core, Lacanian – that is Freudian – only that now it is pushed – and pushed again, mind – into the farcical dimension. For the sake of the argument we use the term “caricature" in a non-partisan, if benevolent, colouring. Exaggeration of a model’s features buttons up our understanding, prepares us to embody the concept; to face it really. Ettinger is careful enough to prepare the ground before making us face her own exaggerations, like, say, „borderlinking”, or „borderspacing”. She takes heed of Freud’s lines in „Beyond the Pleasure Principle”, based on Plato/Aristophanes caricature, which Lacan will then himself caricaturize in his delicious man-omelette myth. It’s where Freud arises the case of death instinct and, being troubled by its discovery, he asks how could we possibly postulate this. He points at the „life instincts already operating in the simpliest organism” – this amoeboid which we will later find turned into lamella – speaking of a “conjugation, which works counter to the course of life and makes the task of ceasing to live more difficult” and about death instincts “associated from the very first with life instincts”, admission of which forces us to work upon an equation “with two unknown quantities”, addressing, as Freud himself does, science, philosophy and poetry simultaneously. Here we’re groping in “darkness into which not so much as a ray of a hypothesis has penetrated”. The darkness is called sexuality. Nothing more than a split in the unified being. Like, we may finally pronounce it, literature. “In quite a different region, it is true, we do meet with such a hypothesis; but it is of so fantastic a kind, a myth rather than a scientific explanation, that I should not venture to produce it here, were it not that it fulfils precisely the one condition whose fulfilment we desire. For it traces the origin of an instinct to a need to restore an earlier state of things". That’s it. The stage is all set now. Enters Plato. In the “Symposium” we find the split between the male and female, and the union of the two. That theory “which Plato put into the mouth of Aristophanes (...) deals not only with the origin of the sexual instinct but also with the most important of its variations in relation to its object”. So much for Freud. From here onwards Ettinger will lead us towards her border, introducing, by the way, new characters, inviting us to follow the hint given us by the poet-philosopher, and [still Freud] “venture upon the hypothesis that living substance at the time of its coming to life was torn apart”, but [and now Ettinger] “not torn apart between male and female (and you see how lovely and Deleuzian this is)”, but [Freud again] “into small particles, which have ever since endeavoured to reunite through the sexual instincts”. What we have here are not two human beings trying to reunite, but the particles – and that’s very subrealistic, in Ettinger’s terms – those different underground particles – whose desire, moreover, to reunite, does not correspond to our desire to live our life in the world. “They’re doing their own thing and this is frightening – this lamella – you can find it everywhere doing its work, but it’s not my work”. And we’re finally in the psychoanalytical imperative, aren’t we. As Ettinger underscores, Freud doesn’t take it to the place where these particles would like to communicate between different figures. In his take the basic arrow would be the desire between different cells, of different amoeba, to become more amoeba, and then “create a border around them and, little by little, we have creatures that defend themselves through their boundaries; and we are the collection of these particles and so on”. The arrow that Ettinger offers is pointing to another level: “when I talk about the matrixial (...) these particles are sustaining their life instinct and so on, but [can the separate collections of these particles] be imagined [as not having to] fight one another in order to exist but already filtering the transconnectedness, the crossinscription”. But here, as Freud would put it, the moment has come for breaking off. Asking: was our primordial state a caricature of sex? We are repetition of amoeba and amoeba is tragedy of ours, forced to copulate. Let’s take a bypass here. „Real humanism”, says Marx, “has no more dangerous enemy in Germany than spiritualism or speculative idealism, which substitutes “self-consciousness” or the '”spirit” for the real individual man and with the evangelist teaches: “It is the spirit that quickeneth; the flesh profiteth nothing.” Needless to say, this incorporeal spirit is spiritual only in its imagination. What we are combating in Bauer's criticism is precisely speculation reproducing itself as a caricature. We see in it the most complete expression of the Christian-Germanic principle, which makes its last effort by transforming "criticism" itself into a transcendent power”. This excerpt from “The Holy Family” seem to admit another property of the blunt reproduction/repetition – the need to fight it. But maybe in a way a sculptor struggles with the material at hand. Thus “the more completely Critical Criticism (the criticism of the “Literatur-Zeitung”) distorts reality into an obvious comedy through philosophy, the more instructive it is”. The problem however arises with a strange inversion that may be observed in the course of analysis, that we could term “who caricaturizes whom?”. There’s change of vectors occurring when the caricature, the set of pronouncements on the face of the object, reveals the vital obsessions of the caricaturist. Rebecca Comay in her lecture “Hegel remarks somewhere...” speaks of Marx “outhegelianizing” Hegel, i.e. doing an even fancier dialectical maneuver than one normally attributed to Hegel. Marx reminds Hegel that repetition is not simply repetition, it is a farcical one (in Hegel it is repetition of Caesar by cesarism), but then it is through Hegel we get an explication of what would a parody in Marx be: a crisis caused by hypertrophy of signification – via representation – like when the second revolution, masquerading as first, is stalling the motor of history, which then stutters in the empty repetition of simulacra. Marx: “If any section of history has been painted grey on grey, it is this. Men and events appear as Schlemihls in reverse, as shadows that have lost their bodies”. But then – the regime of parody as pure excessive signification without any ground, the condition of stasis, seems nonetheless the occasion for overcoming this stasis. Repetition deepened, exaggerated and prolonged, becomes prolegomena for a radical novelty. There’s difference looming. The wager of psychoanalysis, its concern with the speaking being, its definition of the subject and of experience as bound to the realm of signs, comes to haunt us as the lamella-like blobs, that cannot be properly signified. And this in turn appears to be shaping the language in a way that is not without a caricatural charm – psychoanalysis the lacanian psychoanalysis just like the swiss font also carries an excess of beauty that cannot be attributed only to and analysed in terms of rationalisation, the right/wrong dong but one is not mistaken who say that it rests wholly in its content Aren’t, in their analytical aspect, Ettinger’s elaborate neologisms but a pronouncement of Lacan’s own structuralist elaborations of Freud? Which doesn’t mean, of course, that the Lacanian orthodoxy shouldn’t fight back. Marx did, being a good Hegelian, against the Holy Family of the Bauer brothers and their supporters. The Freudian orthodoxy didn’t make it easy for Lacan either, though it was only “back to Freud” at stake at the beginning and “be Lacanians if you wish: I’m a Freudian” in the end. Our point lies, however, elsewhere. And it is a literary one, coming from a Lacanian affinity rather than from the Lacanian field. Namely, a certain degree of liking. (We could observe such in the recent Žižek-Peterson debate, where Peterson started with “The Communist Manifesto” and was disappointed that Žižek didn’t talk about Marxism that much). There’s a big risk that comes with any liking; but this is nonetheless supportive of the libido model and the Lacanian take on the lamella. “Libido is this lamella that the organism's being takes to its true limit, which goes further than the body's limit. Its radical function in animals is materialized in a certain ethology by the sudden decline [chute] in an animal's ability to intimidate other animals at the boundaries of its “territory”. This lamella is an organ”, lest we forget, “since it is the instrument of an organism”. And yet there is something not unlike liking that seems to permeate the matter. Take the affinity itself. Firstly, it names a natural liking for and understanding of someone or something. But then, in biochemistry, affinity stands for the degree to which a substance tends to combine with another. Dictionary seems an unruly beast sometimes. “It is sometimes almost palpable [comme sensible], as when an hysteric plays at testing its elasticity to the hilt”. This caricatural liking we bring to the table.
Yet, we remain careful. A self-debasement might be a power-move. Convictions? “(...) I am not convinced myself and (...) I do not seek to persuade other people to believe in them. Or, more precisely, (...) I do not know how far I believe in them. There is no reason, as it seems to me, why the emotional factor of conviction should enter into this question at all. It is surely possible to throw oneself into a line of thought and to follow it wherever it leads out of simple scientific curiosity, or, if the reader prefers, as an advocatus diaboli, who is not on that account himself sold to the devil”. One can’t resist it. Liking drives in. It’s perhaps far-fetched to offer caricature as means of analysis. Neither tragedy nor farce, as one might put it, but history (i.e. desiring subject) remains here the main focus. But as a method of sharpening the tools these exaggerations may prove good enough. [Friedrichshain/Neukölln, April 2019]
1 note
·
View note
Text
Week 5 Lectures
Morning Lecture
Wired Equivalent Privacy
With WiFi, unlike a wired connection, it is easy for other people to access packets that are being sent through the air. This means that you would want to encrypt your data before sending it.
WEP is very basic encryption with many vulnerabilities. What was interesting is that even though vulnerabilities were found, people kept using it for a while because they didn’t have many alternatives.
Data sent in a WEP frame is broadcast, and only those with the correct MAC address will read it. But this doesn’t stop other people from taking these packets, modifying them and resending them.
Encryption is done using RC4 (which uses a random number generator), and XOR. The data is encrypted, but the order and structure is still the same. So given a packet, it is known which bits correspond to the IP packet’s destination IP address.
An attacker can take a packet sent by someone else, modify the packet’s destination IP address, and send it back to the access point. Instead of the attacker doing work, the access point will decrypt it and send it back to the attacker! Note that the attacker’s IP and the victim’s IP addresses are the same for the first 3/4 of bits, so there aren’t many different combinations to try.
This is an example of mixing data and control - changing the addresses within the IP packet (which is inside the WEP frame) also changes the control.
Phreaking (phone hacking)
Phones back in the day sent tones of different frequencies for control e.g. the frequency 2600Hz was used to give a free phone call.
There was a Captain Crunch promotion where they gave out whistles with frequency 2600Hz - the same frequency as the tone for free phone calls. So people bought the cereal and abused this to get free calls.
The main problem was that tones used for control were sent along the data line.
Guest Lecture - Doctor
There is a lot of bias going on even in the medical world, with patients, pharmaceutical companies, and with doctors.
Observation bias is when seeing what other people are doing influences our decisions. For example, there is a hormone tablet for breast cancer offered after a surgery which has a chance of preventing the cancer coming back, however it has some side effects. A doctor who just saw a patient who decided to take the tablet may become biased towards supporting the decision to use the tablet for the next patient.
There is also the idea of “quid pro quo”, something mentioned in the Social Engineering lecture. Sometimes pharmaceutical representatives take doctors/nurses out for a free lunch and tell them about a new drug. Because of this favour they have done, these doctors/nurses are more likely to recommend the company’s drugs.
What’s scary is that sometimes you think you are not being biased, but in reality you are subconsciously leaning towards one side or another. Next time I make a judgement on something, I’ll try to check if I am truly being fair, or if I’m just following my instincts.
A majority of problems occuring is from human error, be it negligence or poor judgement. Take for example hygiene. It is difficult to get doctors to wash their hands regularly or follow proper hygienic procedures, because they either forget or think its too much of a hassle.
A study showed that adding checklists in surgery halved the infection rate. Checklists have really simple things on them, and are cheap to create, but its usually the simple steps that aren’t followed which lead to poor hygiene. So instead of investing in high end equipment to reduce bacteria levels slightly, in this instance, it was more effective to bring about a culture change on the simple things.
Evening Lecture
Extended seminar - OPSEC (Operations security)
Protect information that could be used by the enemy against you
Identification of critical info
Analysis of threats
Analysis of vulnerabilities
Assessment of risk
Application of appropriate OPSEC measures
Random pieces of info aren’t useful, but together they can do damage.
Origin - Vietnam war
Snowden - “What would be the impact if my adversary were aware of my activities?”
If your threat model is too high - don’t do it.
How to OPSEC?
If you don’t need to share information, don’t.
If you do something you don’t want people to know about, ensure it can’t be traced back to you
Avoid bringing attention to youself
This is hard to pull off, so tradeoffs must be made e.g. where do you want to be secure, or and where do you want to be visible. It’s hard figure out how much you want to hide.
Avoid sharing information - only share if it’s needed, beware of social media, metadata, indicators - expensive clothes
Keep identity secret - Tor browser to remain anonymous,
You can use a false identity - hard to maintain
Be forgettable - blend in with everyone else so that you don’t draw attention to yourself
“There are no case studies of good OPSEC - you never hear about them.”
Case studies
WW2 - American congressman bragged that American subs survived because Jap depth charges weren’t deep enough. This cost the US lives, as Japanese set them deeper.
MI6 agent exposed because of wife who left Facebook on public.
Harvard bomb threat
Bomb threat listed his exam hall
Guerilla mail adds originating header - found out it was Tor
Tor was used on campus wifi - don’t be logged in if you want to be anonymous
Silk road - Ross Ulbricht
Asked for help with set up on his real email
Used same alias on multiple sites
Tor and VPN used in wrong order - negligence
Richard’s comments
Someone with good OPSEC used different computers and toolkits for different personas.
Even first contact is dangerous - you can roll back in time to when people were young and connected their accounts etc.
Extended seminar - Passwords
Most passwords used are weak. It’s hard to remember and to type a complex password, so people tend not to use them.
Passwords often use personal information such as name and birthday. So hackers can try cracking passwords using this information.
Good passwords are long without english grammar patterns.
Passwords are broken
Passwords are weak - full of meaning (47% based on name), often reused over multiple sites.
Personal Information Attack
Fake Facebook profile (Sally) - can see partner’s name, birthday, education, hobbies, pet’s name
cup.py - many combinations of passwords based on personal information, common replacements (a -> 4)
Password Crackers
John the Ripper on Kali Linux
Hashcat - for hashes
Why are passwords bad?
hard to remember and type good passwords
complicated rules for generation (letters, numbers, symbols)
regular renewal
little incentive to create unique passwords
low probability, high impact risk
Password Storage: bad practice
Some are still stored in plain text - mostly small to medium sized companies
Facebook had stored plaintext passwords in an internal database
Bad hashing (md5, sha1) - Rainbow tables are designed to match with passwords
Demo - using Linkedin passwords file
In 2012 - Linkedin was hacked, and passwords leaked.
Saeed had a file with the list of userid:hashedpassword.
Used Google - sha1 to reverse the hashed password
Looking through the first 1000 lines, 4 people had the same password
10000 lines - 26 people
Passwords frequency in descending order: password, 123456, LinkedIn
If you have a bad hash, anyone with google can hack passwords
John the Ripper - automatically cracks the passwords based on the hashes
Salt - add random string to end of the password, you get 2 different hashes. This way, there isn’t a problem if many people had a password. LinkedIn did not have a salt.
Best practices for storing passwords
Use a strong encryption method like a hashing function such as sCrypt or BCrypt
Store the salted hash, not the password
Salts should be long (at least 256 bits)
Don’t store password hints
Another solution - let a bigger company handle it. Log in with Google or Facebook, however this is
Maybe we can get rid of passwords altogether - but not yet.
Password Generation
Better ways to come up with memorable passwords
correcthorsebatterystaple
length of word creates enough entropy
avoids english grammar patterns
don’t use common words
passphrases
long and with wacky lexicon but good syntax to make it hard for AI to generate
memorable
initialisation of a phrase
take first letter of each word, removes English letter frequency
New policy - NIST 2016
don’t force regular password changes
don’t enforce composition rules
don’t provide password hints
allow user to opt for passwords to be viewed while typing
limit number of failed login attempts
Richard: just keep a list of bad passwords, don’t use any.
Long passwords are better than just adding symbols and numbers.
Richard: we think our passwords are good, but we overestimate it. Humans are bad at generating passwords - we follow patterns.
Buckland’s Lecture
Merkle Damgard construction
https://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_construction
SHA2 - different types depending on size (SHA-256 means SHA2 with 256 bits)
We have a long message, but we need a small hash, so we break the message into blocks.
This is a method of building collision resistant cryptographic hash functions from collision resistant one way compression functions.
It is used in hash algorithms such as MD5, SHA1 and SHA2.
The message is split up into blocks.
The algorithm starts with an initial value, the initialisation vector (IV).
The result so far (initially just the IV) is combined with the next message blockis, then the compression function f is applied.
Step 3 is repeated until all blocks have been added.
The last result may be passed through a finalisation function.
Bank messaging problem
We want integrity and authentication. MACs give us both.
We can add the secret key before the message, and then hash it.
MAC: h(key|data)
The problem with this is that an intercepted message with known hash and message length can be extended. This is a length extension attack.
Take the hash, append a new message to it and pass it into f, the compression function. In this way, you can modify the message, even without knowing the secret key.
HMAC (hash-based message authentication code) puts the password after the message, instead of the beginning. h( key | h(key|m) )
Digital Signature
DSA - Digital Signature Algorithm
A digital signature is used to verify authenticity of digital messages or documents. A valid digital signature gives the recipient strong reason to believe the message was truly from the sender (authentication) and that the message was not altered in transit (integrity).
Signing larger files directly takes a long time. To sign large files, hash the file and then sign the encrypted hash.
Collisions with digital signatures
A collision attack requires half the number of bits in the hash size.
Example: Alice has a pdf saying “I will give Bob $100″, then Alice signs it, and sends it along with the signature to Bob. If an attacker can create another document with the same hash as Alice’s document, then the attacker can use the same signature with this new document, so it looks like Alice has signed the new document.
The attacker can change 1 bit in each document that doesn’t change anything visible (e.g. whitespace) and then keep hashing them until you find 2 identical hashes. Ask Alice to sign the first document, and you can reuse the signature for the second one.
Passwords
Password attack types:
online - typing the password on a website manually
website can detect
offline - obtaining the file containing hashes of passwords and decrypting locally
/etc/shadow
password file used to be protected by md5
Salt is random data added to the password before hashing. Salts help to prevent collisions in the case that users have the same password. Salts also protect against the use of rainbow tables, because the password will need to be hashed with the random salt to be in the table.
0 notes
Text
Mid-Semester Revision Thread
Blob of text for my own midterm study that I thought I may as well put on my blog.
Questions taken from Jasper’s midterm stuff.
What are the six most common letters in English text?
ATEION
What are the important properties of a cryptographic hash function?
- hashes are fixed length
- changing one character in plain text, changes the hash significantly
- the plain text is difficult to be reversed from the hash
- two different strings are unlikely to evaluate to the same hash
- the same string will always evaluate to the same hash
What are the CIA properties?
Confidentiality
Integrity
Authentication
(Deniability)
Substitution Cipher 1
Cipher solved! You are awesome! You solved the cipher: NEVER LET THE FUTURE DISTURB YOU. YOU WILL MEET IT, IF YOU HAVE TO, WITH THE SAME WEAPONS OF REASON WHICH TODAY ARM YOU AGAINST THE PRESENT.
Substitution Cipher 2
Cipher solved! You are awesome! You solved the cipher: PASS THEN THROUGH THIS LITTLE SPACE OF TIME CONFORMABLY TO NATURE, AND END THY JOURNEY IN CONTENT, JUST AS AN OLIVE FALLS OFF WHEN IT IS RIPE, BLESSING NATURE WHO PRODUCED IT, AND THANKING THE TREE ON WHICH IT GREW.
Substitution Cipher 3
Cipher solved! You are awesome! You solved the cipher: ALEXANDER THE GREAT FOUND THE PHILOSOPHER LOOKING ATTENTIVELY AT A PILE OF HUMAN BONES. DIOGENES EXPLAINED, "I AM SEARCHING FOR THE BONES OF YOUR FATHER BUT CANNOT DISTINGUISH THEM FROM THOSE OF A SLAVE.
Substitution Cipher 4
Cipher solved! You are awesome! You solved the cipher: PEOPLE ARE FRUGAL IN GUARDING THEIR PERSONAL PROPERTY; BUT AS SOON AS IT COMES TO SQUANDERING TIME THEY ARE MOST WASTEFUL OF THE ONE THING IN WHICH IT IS RIGHT TO BE STINGY.
Lecture Points That I Deem Important
Lecture 1
Vulnerabilities: weakness in a system
Exploit: something that uses a vulnerability to compromise a system
Threat: what you are up against
Kerckhoff’s Principles:
1. The system must be practically, if not mathematically, indecipherable; 2. It should not require secrecy, and it should not be a problem if it falls into enemy hands; 3. It must be possible to communicate and remember the key without using written notes, and correspondents must be able to change or modify it at will; 4. It must be applicable to telegraph communications; 5. It must be portable, and should not require several persons to handle or operate; 6. Lastly, given the circumstances in which it is to be used, the system must be easy to use and should not be stressful to use or require its users to know and comply with a long list of rules.
Security Through Obscurity - relying on secrecy or complexity for security
Confidentiality - Ensuring that only authorised people can access certain information.
Integrity - Maintaining the “trustworthiness” of a message. I.e. ensuring the message is not altered or destroyed by an unauthorised party.
Authentication - an act, process, or method of showing something to be real, true, or genuine.
Bell LaPadua – levels of confidentiality (single point of failure at top)
Ciphers: - Substitution: letters (or a group of letters) are substituted with other letters. - Transposition: letters remain the same, but the order is changed.
Lecture 2
Vignere Cipher - Take a password and shift the encrypted message by the alphabetical order of the password (e.g. ABBA).
Steganography - hide existence of the message (e.g. hiding data in a cd)
One Time Pad - like Vignere but the password is the length of the message and completely random, once used the cypher should be discarded
Type 1 Error - false positive
Type 2 Error - false negative
Security By Design - reduce single point of failures, trust no one, build security from beginning rather than after system built.
Lecture 3
Risk:
- Risk is still there and bad even if nothing goes wrong - Humans are especially bad at preparing for Low Probability-High Impact events as we normally base our risk assessment on things we have experienced or can easily visualise happening.
Dealing with risk:
1. Prevention - remove vulnerabilities that allow the risk to occur.
2. Limitation - put in place things that will reduce the impact of a risk occurring.
3. Passing the risk to a 3rd party - reduces impact by having a “backup” (e.g. insurance)
4. Wearing the risk - If a risk cannot be fully prevented, it is necessary to just “wear the risk “.
Public Key Cryptography - release a public key that everyone can use to send you encrypted messages that only you can decrypt using your private key.
Lecture 4
Substitution Cipher Example:
26! combinations of English letters for substitution cipher.
Would take a very long time to brute force.
But, English language has patterns
Entropy - degree of randomness
Hashing:
Hash functions must return the same results each time
Hash collisions - different items map to the same thing
Hash functions summarise variable information into fixed, deterministic information
Sometimes it’s easier to look at the hash data rather than the original data
Clustering in data causes clustering in the hash
Birthday attack exploits hash collision
Hash is like a signature. Original message and hash can be tampered with
Birthday Attack - exploits the mathematics behind the “birthday problem” to find hash collisions. Work required to find collision is 2^(n/2) where n is size of the hash (e.g. 16 bit hash = 2^8 to solve).
Types of Hash Attacks:
preimage attack: given hash(M) find M
2nd preimage attack: given M find M' where hash(M)=hash(M')
collision attack: find any two messages M, M' where hash(M) = hash(M')
Lecture 5
Separate data and control - Users have access to data, but they shouldn’t have access to control
Wired Equivalent Privacy (WEP):
A stream of bits (A) is sent from one point to another
A random stream of bits (B) is generated using an algorithm, such as RC4 (very insecure)
The XOR function turns A into a stream of bits with the statistical properties of randomness.
A (xor) B -> C (Encrypted Stream of bits)
C (xor) B -> Gives back A again
Hashes
MD5, SHA0, SHA1 - broken
SHA2, SHA3 - not broken
SHA3 only one not vulnerable to length extension attacks
Broken - property can be violated faster than brute force (e.g. birthday attack)
Length Extension Attack
a length extension attack is a type of attack where an attacker can use Hash(message1) and the length of message1 to calculate Hash(message1 ‖ message2) for an attacker-controlled message2, without needing to know the content of message1. Algorithms like MD5, SHA-1, and SHA-2 that are based on the Merkle–Damgård construction are susceptible to this kind of attack.
When a Merkle–Damgård based hash is misused as a message authentication code with construction H(secret ‖ message), and message and the length of secret is known, a length extension attack allows anyone to include extra information at the end of the message and produce a valid hash without knowing the secret. Note that since HMAC doesn't use this construction, HMAC hashes are not prone to length extension attacks.
Merkle Damgard Construction
1. break message into a series of blocks
2. start with IV (initialisation vector)
3. Given hash function f, it takes in IV and block 1, output goes into f again with block 2 etc.
4. After doing this with all blocks, final hash is produced
MAC
Insert shared secret at the front of the hash, as the first block
MAC = h(key | data) - h is a hash function, key|data is the password concatenated with the message
Flaw:
If someone has sent a message, and you have the hash and the message length, you can extend the message.
You can take the hash you have, pass it into f again with a new message, thereby extending the original message. This is a Length Extension Attack.
Best MAC to use is HMAC (hash-based message authentication code)
HMAC = h(key | h(key | m))
Salting a hash
Salting a hash is something that gets added to the password before it gets hashed. Salt can be a single string, or a unique string for each user. If your salt is unique for each user, each user's password is almost guaranteed to be unique before hashing. The goal is to make the amount of work to decode a hash as great as possible, to deter hackers.
Key Stretching
Key stretching is designing a hash to be slow, such that it adds even more work for a hacker to decrypt a table of passwords. The added time for an individual user would be negligible by comparison.
Module Stuff That I Deem Important
Coincidence Index
Shift a cipher text any amount and line it up with itself
Count the coincidences (when the same letter lines up)
Divide coincidences by the length of the lined up text
Multiply by 26
Merkle Puzzles
Let's say Bob wants to securely communicate with Alice.
Alice creates 1000 unique pairs of a unique Identifier, and a key : 1000 x (identifier, key)
Alice encrypts each pair separately with relatively weak encryption - encryption((identifier, key), randomWeakKey)
Alice then sends all 1000 encrypted blobs to Bob
Bob chooses one encrypted blob at random and brute forces every password until it is cracked
Bob is left with a unique identifier and a key. Maybe : (sausage, A3D19F)
Bob encrypts the message with the key, and then tells Alice is he using the key corresponding to the ID 'sausage'
Alice looks up 'sausage' on her list, and finds the corresponding key
Alice decodes the message using the key A3D19F
Attacker will need to decrypt (on average) n/2 times (500 in this case), whereas the recipient need only decrypt 1.
RSA
Step 1 : Choose values for p & q (prime numbers)
Step 2 : Calculate n for the keys (n = p * q)
Step 3 : Calculate Euler's totient (ϕ) ((p-1) * (q-1))
Step 4 : Choose a value e for the public key (e must not share any factors with phi)
Step 5 : Choose a value d for the private key (e * d mod ϕ = 1)
Encrypting with Public Key: c = me mod n
Decrypting with Private Key: m = cd mod n
Hashing
A cryptographic hash has the following properties:
Reduces any amount of text or data into a fixed output
The same text will always result in the same hash (deterministic)
Its quick to compute
It should be hard to reverse
It's hard to find two different texts that has the same hash
If you make a small change to the text, it will change lots of things in the hash
0 notes
Text
Week 5 Notes and Reflection
REFLECTION
Interesting lecture. Richard really likes to talk about WEP!! Perhaps its in the exam?
I find the idea of hashing really interesting. I was always wondering what a digital signature was and how it works when you sign something in Adobe Acrobat - and why you can’t change the document after you sign it! Now I understand why, so that’s pretty cool!
Don’t fully understand why MD5 is bad for password storage - does it matter if someone figures out a collision for a password attack?
NOTES
Motto: “Don’t roll your own”
Last weeks motto: “Every contact leaves a trace”
Binary Search - Apparently someone published an implementation of binary search and they guy was certain it was right, but years later discovered an integer overflow bug. If binary search is so hard to implement, gg security. Don’t try to reinvent the wheel. A lot of time has gone into developing things,you probably can’t do it better than history.
Phone Phreaking - Playing around the tones in the telephone line, reversing engineering. Get free phone call.
CRYPTOGRAPHIC PROTOCOLS
WEP Wireless Security
With WiFi, someone who is a KM away could tap into your network. This is unlike Ethernet network, where the attacker needs physical access. WEP had so many vulnerabilities it was really funny. Once people discovered it was flawed, people still kept using it!!!
How it works - We are streaming the bits serially between the devices. The bits are broadcast everywhere. Laptops need to know which bits are there bits. Communication is done through frames, with the MAC address appended to the beginning. We need to encrypt this.
Both sender and receive have a random number generator. The number is XOR with the data. The property of XOR is associative - can be done in any order. XOR also gives nice psuedo-randomness. The encrypted data is sent to the receiver, he XOR it, then he gets the plain bit string back.
The hack was done using TCP/IP packets. TCP/IP has header etc. The IP packet wrapped around the TCP packet has the source/destination IP address. Hence we know which part of the encrypted string is the header etc. What is interesting is that there is nothing stopping you intercepting the packet and sending your own packet - the machines are responsible for checking this.
How to hack - I take the packet, retransmit by sending the packet to the router but with the destination address to my computer. Then the router will decrypt it, and send it to you!!
The problem is that the data and control are mixed together. Mixing data and control might enable hackers to control the system.
Hack a phone - phones send tones around the PSTN to control things. You can just do a replay attack. E.g. get free phone call.
Hashing
Hashing is good for integrity.
History of hashing - MD5 is “broken” - someone has worked out a way to get an undesirable property from the protocol faster than brute force. E.g. for MD5 if it is 56 bits, to find a preimage it should take 55 bits of security on average. For MD5, and many other protocols, find a small break in the protocol, and over the time like a volcano it goes bang bang bang and breaks. As each year went by, it turns out the time to break it become smaller and smaller.
SHA-0 - NSA came up with a better hashing algorithm. However it was bad so they came up with SHA-1. Just recently SHA-3 has been recently approved.
Data breaches - Few data breaches last year where hackers got the password file with the hashes. A ridiculous number were in MD5!
In early 2000s there was a bit of theory about hacking SHA-1. Recently found a collision.
Broken hash - A way of getting info out of the hash without pure brute-forcing. If a hash can be broken in time less than the brute-forcing time, then it is considered broken.
Merkle-Damgard Construction
MAC - Gives us Authentication and Integrity. MAC is basically a hash of the key and the data. h(key|data). E.g. append shared secret “sausageP” to your strings then hash.
Length extension attack - Take the existing message, with the hash. Add stuff the end of the message, continue the hashing process for the next block, since hashing is done on a block by block basis like a state machine. The solution is to add the password to the end, but still breakable.
Digital Signatures - Need a signature on a document to ensure the document is not tampered with.
Take the original document, encrypt with your private key.
If people can decrypt the doc with your public key, must have been from you!
However instead of encrypting the document itself, we encrypt the hash of the original document, it is shorter.
Collision Attacks with Signed Documents - If we can figure out two documents with the same hash, then on the fake document we can use your original signature and forge the fake document.
Make fake document and original document.
Keep trying to modify the original document until its hash matches the fake document. E.g. add whitespaces
Give the original document to the person and they sign it.
By doing this, they are also accidentally signing the fake document at the same time!!
Data Breaches - Ashley Madison data breach, LinkedIN MD5 Breach
Salted Hashed Passwords
A table makes it easy to crack passwords, as commonly used passwords would hash to the same password. So if a common password is sausage and 1000 people used it, by cracking sausage once you crack all the 1000 passwords.
If we add a salt (a phrase) to each password, and each person has a different salt, then even if two people use the same password, the combination of “sausage” + salt1 and “sausage” + salt2 would result in different hash value for each. We can store the salt in plaintext in the password file.
So in this case if they want to crack some passwords they have to go through each person, and append the salt and then attempt their brute force or dictionary attack.
Doesn’t stop the use of rainbow table, but increases the complexity. Rainbow tables make unsalted MD5 or SHA0 passwords easy to break.
Key Stretching Hashes
Services like Bcrypt are slow algorithms. Although you might have a 1 second slowdown for the user, the amount of time for a hacker to try to crack lots of passwords increases.
Online & Offline attack - Online attack is trying to login to the website, offline attack is when you have the hashed passwords and can easily try crack them offline.
NIST Password Guidelines - read them!
Moore's Law. (n.) Moore's Law is the observation made in 1965 by Gordon Moore, co-founder of Intel, that the number of transistors per square inch on integrated circuits had doubled every year since the integrated circuit was invented. Moore predicted that this trend would continue for the foreseeable future.
An initialization vector (IV) is an arbitrary number that can be used along with a secret key for data encryption. This number, also called a nonce, is employed only one time in any session.
Attacks on MD5
A. Sotirov M. Stevens J. Appelbaum Arjen K. Lenstra
Flame malware in 2012
AbstractPresented at the 25th Chaos Communication Congress in Berlin on December 30, 2008. We have identified a vulnerability in the Internet Public Key Infrastructure (PKI) used to issue digital certificates for secure websites. As a proof of concept we executed a practical attack scenario and successfully created a rogue Certification Authority (CA) certificate trusted by all common web browsers. This certificate allows us to impersonate any website on the Internet, including banking and e-commerce sites secured using the HTTPS protocol. Our attack takes advantage of a weakness in the MD5 cryptographic hash function that allows the construction of different messages with the same MD5 hash. This is known as an MD5 "collision". Previous work on MD5 collisions between 2004 and 2007 showed that the use of this hash function in digital signatures can lead to theoretical attack scenarios. Our current work proves that at least one attack scenario can be exploited in practice, thus exposing the security infrastructure of the web to realistic threats. This successful proof of concept shows that the certificate validation performed by browsers can be subverted and malicious attackers might be able to monitor or tamper with data sent to secure websites. Banking and e-commerce sites are particularly at risk because of the high value of the information secured with HTTPS on those sites. With a rogue CA certificate, attackers would be able to execute practically undetectable phishing attacks against such sites. The infrastructure of Certification Authorities is meant to prevent exactly this type of attack. Our work shows that known weaknesses in the MD5 hash function can be exploited in realistic attack, due to the fact that even after years of warnings about the lack of security of MD5, some root CAs are still using this broken hash function.
The program is being used for targeted cyber espionage in Middle Eastern countries.
Flame was signed with a fraudulent certificate purportedly from the Microsoft Enforced Licensing Intermediate PCA certificate authority.[15] The malware authors identified a Microsoft Terminal Server Licensing Service certificate that inadvertently was enabled for code signing and that still used the weak MD5 hashing algorithm, then produced a counterfeit copy of the certificate that they used to sign some components of the malware to make them appear to have originated from Microsoft. - wikipedia
OPERATIONAL SECURITY EXTENDED LECTURE
Military definition: How they protect info that could be used by the enemy against them, in order to create a safe environment.
Origins - US military tradition of communicating in plain language, field commanders ignored encryption instructions or used bad encryptions.
When to OPSEC - 24/7.
Snowden on Opsec - If the impact of your threat model is too high, consider alternatives. Because sometimes you can’t always keep something secret, but you can plan your response.
The extends to which you you go protect your information and the tools you use will be different depending on the situation.
There’s a counter to every attack, so instead of taking every possible measure to mitigate risk, just think about simple.
How to OPSEC? - If you don’t need to share info, don’t. If you do something you don’t want people to know about, ensure it can’t be traced back to you. Avoid bringing attention to yourself. Very hard to pull off, and tradeoffs must be made.
Avoid sharing info - Only share info on a need-to-know basis. Beware social media, metadata. Minimise indicators - expensive clothes, carrying tools. No info is still information! Hard to strike the right balance.
Keep your identity secret - Remain anonymous or set up a false identity to hide your tracks e.g. VPN. False identities are difficult to create and maintain, but are often useful. Never contaminate, leaking info from one identity to another.
Be forgettable - Blend in with everyone else. If you stand out, you will be remembered and monitored.
Case Studies
Promotion - Wife left facebook post of MI6 chief-to-be public.
Harvard Bomb threat - Bomb hoax, but person failed as he was traceable - IP header, campus wifi.
Good OPSEC - Good OPSEC by NSA. Assange and Snowden.
PASSWORDS EXTENDED LECTURE
Passwords are WEAK
Some statistics:
Full of meaning - 47% of passwords based on a name, 42% based on significant dates or numbers, such as birthdays, 26% based on pets.
Personal Info Attack - Sally Smith Facebook. Kali Linux, make a password dictionary, Hashcat, rainbow tables.
Why are passwords bad? - Hard to remember good passwords, hard to type good passwords, complicated rules for generation, regular password renewal creates user generated patterns, little incentive to create unique passwords (low probability, high impact)
How to not store passwords - Hash them, not plain text!
Bad hashing - Rainbow tables are designed to match with passwords. project-rainbowcrack.com/table.htm Encoding the same string using the MD5 algorithm will always result in the same 128-bbit hash output.
This also applies to SHA128, etc.
Add Salt to Passwords - so hash for same password not always the same
Best Practices - use sCrypt/bCrypt, use salted hash, salts should be long, keep on updating and improving, don’t store password hints.
Password Generation - 4 unrelated words concatenate together creates enough entropy so it is difficult to hack. Long and wacky lexicon but good syntax to make it hard for an Ai to generate.
New policy - Allow long passwords, use multi-factor, don’t force regular password changes, limit failed the number of login attempts.
0 notes
Text
Game Review : Space Harrier
Elite Systems / 1987 / Originally £9.99 / Commodore 64
In Space Harrier, save the ‘Fantasy Zone’ from certain destruction by flying into the screen and blasting stuff until you meet a bigger thing to blast at the end of the level. Then blast more stuff while looking at a differently coloured background!
The rate at which graphics and sound advanced in the arcades in the early 1980’s was genuinely astounding. As a kid I only made contact with this exciting world a few times a year, and I would be greeted with something new and potentially jaw dropping on nearly every occasion. A case in point: try comparing SEGA’s 1981 driving game Turbo with their 1985 fantastical 3D shooter Space Harrier. Turbo was a really impressive game for ‘81, but it was made to look colourless, jerky and ridiculously limited within just a few short years.
Space Harrier was a notable early entry in SEGA’s ‘super scaler’ series of arcade games, which used hardware sprite scaling effects to provide a convincing into-the-screen 3D effect without the need to render a real 3D space.
In the arcade. Fast, smooth and colourful!
The effect of movement is amplified here by a smoothly animated checkerboard ground pattern. It’s a very simple game at heart; you view your flying character from behind as they weave in and out of columns and trees, trading shots with enemies that dance in front of them. At the end of each level you come to a dead stop and face off against a larger boss; basically a mobile bullet sponge who guards the way to the next level.
Every few stages you get to ride a dragon and smash into trees to earn points. The battle is played out to a memorable theme tune, and has a few scattered speech samples thrown in for good measure (‘welcome to the fantasy zone!’).
From the very beginning, reproducing a game like Space Harrier on the C64 was a bit of a non-starter. Where 8-bit home computers could often produce a reasonable facsimile of arcade games at the beginning of their life-span, they were soon completely out-paced by the sounds and visuals offered in the arcade.
Despite this fact, arcade licenses remained sure sellers on home systems which could never do them justice.
You'll forget the sun in his jealous sky as we walk in fields of brown.
The impossible job of converting such a technically advanced game to the C64 was handled by Chris Butler, whose efforts on the beige box I generally have a lot of time for. He produced very playable (if truncated) versions of Commando and ‘Ghosts and Goblins’. He also went on to make several other madly ambitious C64 conversions of SEGA’s super scaler arcade games, with some degree of success. His games though, had a definite tendency to look plain and functional. If you take a candy coloured fantasy like Space Harrier and replace 90% of the colour with turd-brown and battleship grey it’s hard to hand out plaudits for what’s left.
And yet, if you squint… and approach it with a lot of charity… this *is* a half decent effort for the time. It’s nice and fast and contains all the essential gameplay elements of dodging and shooting in a 3D space. It’s a shorter game, with much less variety in enemies, no dragon riding bonus sections and no character speech, but the graphical effect that renders the enemies and obstacles as they get closer until nearly filling the screen has been done fairly effectively.
It’s certainly much better than the laughably feeble Amstrad CPC effort, which rendered all the enemies and obstacles with vector graphics to keep the speed up. It’s also much less likely to give you a seizure than the Spectrum port, throwing its shaded monochrome sprites and horrible colour clash right into your retinas.
The conversion is obviously a rush job; apparently Chris was given a stupidly short deadline and it would have been much better if he’d been allowed the time to finish. This is evidenced by the later US release which added a raster bar effect on the ground and tidied up the sprite work.
U.S. Space Harrier. A slap in the face to British gamers!
Ultimately, what sinks this game on the C64 is that fact that in the arcade it was more of an attempt at sensory overload than a deep and engaging game. The deluxe cabinet even threw the player about courtesy of a hydraulic chair! It was about as imaginatively made a sensory overload as you were going to get back then, and I still retain a lot of fondness for it, but strip it of its theme park ride trappings and there isn’t really a whole lot left to keep you entertained.
Buying it today
This was a successful mainstream release, and there are plentiful cassette copies available for a few pounds.
Commentariat
Tim: The odd thing is, for years I never saw an actual Space Harrier arcade machine. Our local leisure centre was the point of reference for such things and while it was fine for Double Dragon, Thunderblade, Xenophobe, Outrun and Operation Wolf, they never seemed to ever get Space Harrier. So in my mind, this game has always really been a mish-mash of low res graphics and turgid colours. Oddly, it’s the arcade that feels wrong. Messed up, I know.
The C64’s version is alright; it whips along at a decent pace and the music, what there is of it, is nicely done. True it’s nowhere near arcade accurate and at times makes little sense, but it’s a solid attempt even if it quickly bounces against the limitations of the hardware it’s running on. Compare it to some other versions and the arcade and sadly, it’s nothing to write home about.
Pop: When I think of Space Harrier, I’m always transported back to a specific moment in my childhood. Some of my friends were keen mountain bikers, and since I’d just been given a cheap imitation of a mountain bike I decided to join them on one of their weekend trips. This quickly resulted in me travelling at speed down a gravelly hill on my arse. Luckily Tim lived nearby; his mum was a nurse and with her expert help I survived. I remember coming home that evening battered and bruised and playing my new copy of Space Harrier for the first time. I can’t remember enjoying it that much, but it was certainly a surreal experience, still vivid in my mind.
In retrospect, this wasn’t much cop. The C64 was plagued by over-ambitious arcade conversions. There’s just not enough gameplay here, and it’s all quite unattractive to look at.
Meat: The graphics are ugly, the main character runs like he’s shat himself, there’s minimal gameplay, half the levels are missing, the bonus stages are missing, the synthesized speech is missing. Other than that it’s fine.
Score card
Presentation 5/10
A standard cassette jewel case with inlay instructions. The cover artwork is attractive courtesy of the original arcade game. There’s very little that’s special about the in-game presentation, with a very bare title screen. This has all the hall-marks of a rush job.
Originality 6/10
From a graphical design standpoint the arcade game was very original. The gameplay itself was only an iteration on what had come before. There weren’t too many games attempting this into-the-screen viewpoint on the C64 at the time, given how difficult it was to pull off successfully.
Graphics 5/10
They’re fast, but much more jerky than in the arcade thanks to the lack of any custom sprite scaling hardware in the humble ‘64. The effect just about works, but the lack of any ground animation is a let down. Everything is splotchy and ugly, and there’s far too much brown!
Hookability 6/10
Very easy to get into, and nothing much to explain. There’s a certain appeal to seeing what comes next, for a while at least.
Sound 7/10
A well made rendition of the arcade Space Harrier theme plays on every level, with a separate end-of-level boss tune. The spot effects are pitiful, however. The C64 surely could have handled the synthesized speech, though this may have been cut due to memory constraints and to avoid having to make the game a tape multi-load.
Lastability 3/10
Space Harrier is not a deep game. There isn’t even as much incentive to see later levels as in the arcade, because the background and enemy variety has been cut right back.
Value for Money 3/10
1987 was something of a vintage year for the C64, with the release of original titles such as Wizball, IK+ and The Last Ninja. There really isn’t enough here to make this a worthy purchase at full price.
Overall 4/10
While this was a brave attempt at home conversion of Space Harrier, it was a minor disappointment at the time. It may have been the best on an 8-bit computer, but that’s clearing a pretty low bar. It also rankles that we got something half finished where the U.S. saw a significantly more polished release.
If you really feel the need to play an 8-bit conversion today, we would recommend the efforts on the Master System or PC Engine. There’s also a highly impressive modern homebrew for Atari computers.
0 notes
Text
The St. Petersburg Paradox
Thinking about Risk and Uncertainty¶
This series of posts will be an introduction to the economics of risk and uncertainty as well as some finance. To make it easy to follow along, everything will be recorded in Python and uploaded to my Github as an iPython notebook.
If you were offered a bet that you were nearly certain to win, would you take it? Consider the following scenario:
You have \$100. In a lottery, you have an 80% chance of earning \$120 (\$100+20) and a 20% chance of losing your \$100. Would you choose to take such a bet? Would you play it the other way around and bet on the 20% chance to win \$180? Would you even play this bet at all? During the 2016 presidential election, several thousands of people made this very bet using political gambling websites (and not everyone was happy with the results).
From assessing stocks to picking insurance plans, risk assessment is incredibly valuable skill with a lot of hidden complexity. Furthermore, learning to understand risk better helps us engage with problems of judicial importance such as legal negligence standards and political importance such as climate change regulations.
Even Batman V Superman makes a nod to the idea of existential risk calculus:

“He has the power to wipe out the entire human race and if we believe there’s even if it’s a 1% chance that he is our enemy we have to take it as an absolute certainty!”
The 2 characteristics of uncertain environments¶
Given a choice made by a decision maker, an outcome is any possible occurrence that affects someone in some way. Mathematically speaking, an outcome (the first characteristic) is a parameter that affects the well-being (utility) of the decision maker.
For simplicity’s sake, we assume that the number of possible outcomes is always finite:
In [16]:
#First, get the import statements out of the way from __future__ import division import math import numpy as np from IPython.display import display, Image, HTML, Latex, Math import pandas as pd import matplotlib.pyplot as plt %matplotlib inline
Outcomes are always finite in terms of some arbitrary N. This lottery is of size N = 5 and has no outcomes.
In [2]:
#Outcomes are always finite in terms of some arbitrary N N=5 #This lottery is of size N and has no outcomes outcomes = [None]*N print(outcomes)
[None, None, None, None, None]
For example, a coin flip would have 2 possible outcomes: Heads or Tails. But knowing the outcomes alone isn’t particularly interesting. What we’re interested in is the outcomes and their corresponding probabilities. So, the vector of probabilities (the second characteristic) is the list of probabilities corresponding to a list of outcomes. Each probability must be $\ge$ 0 and the sum of the probabilities must equal 1.
If we assume that a coin is fair, then the probability of Heads is equal to 0.50, and the probability of Tails is also equal to 0.50.
In [3]:
#The probabilities in an event where each outcome is equally likely probabilities = [1/N for i in range(0,N)] print(probabilities)
[0.2, 0.2, 0.2, 0.2, 0.2]
Together, the corresponding lists of outcomes and probabilities forms a lottery.
In [4]:
#A lottery is the list of outcomes and their corresponding probabilities def lottery(outcomes, probs): assert len(outcomes)==len(probs) assert sum(probs)==1.0 lotto= zip(outcomes, probs) return lotto example_lottery = lottery(outcomes,probabilities) display("Example:", example_lottery)
'Example:'
[(None, 0.2), (None, 0.2), (None, 0.2), (None, 0.2), (None, 0.2)]
In [5]:
#fair coin sides = ['H','T'] coin_probs = [0.5,0.5] coin_lotto = lottery(sides, coin_probs) display("Fair coin flip:",coin_lotto) #ex2 ex2_outcomes = ["$1000", "$4", "$-300"] ex2_probs = [0.1, .85, .05] ex2_lotto = lottery(ex2_outcomes,ex2_probs) display("Another example:",ex2_lotto)
'Fair coin flip:'
[('H', 0.5), ('T', 0.5)]
'Another example:'
[('$1000', 0.1), ('$4', 0.85), ('$-300', 0.05)]
Furthermore, a lottery may also contain lotteries. This is called a compound lottery.
In [6]:
#A compound lottery is a lottery that may contain other lotteries ex3_outcomes = [10, coin_lotto] ex3_probs = [0.5,0.5] ex3_lotto = lottery(ex3_outcomes,ex3_probs) display("Compound Lottery:", ex3_lotto)
'Compound Lottery:'
[(10, 0.5), ([('H', 0.5), ('T', 0.5)], 0.5)]
Just like with a probability mass function (PMF), we can calculate the expected value of a lottery by finding the sum of the products of each outcome and its probability.
In [7]:
def expected_value(lottery): mean = 0 for outcome, probability in lottery: mean+= outcome*probability return mean
Here, the expected value is 0
In [8]:
ex3_lotto = lottery([1,-1],[.5,.5]) display(expected_value(ex3_lotto))
0.0
Now, given this framework, we can calculate the value of a real lottery such as a powerball lottery.
In [9]:
#Odds of winning a jackpot (a rough guess) powerball_prob = 1.0/300000000 #Odds of losing loss_prob = 1-powerball_prob #Jackpot jackpot = 10000000 ticket_price = -1 powerball = lottery([jackpot,ticket_price],[powerball_prob,loss_prob]) display("The expected value of your ticket:",expected_value(powerball))
'The expected value of your ticket:'
-0.9666666633333333
The expected value is a powerful idea because it helps us order our preferences between lotteries. When using expectations, we make three assumptions:
• When the expected value of a lottery is greater than a guaranteed option, a decision maker will choose the lottery.
• Conversely, if the expected value of a lottery is lower than a guaranteed option, a decision maker will always choose the guaranteed option.
• Finally, if the expected value of a lottery is equal to the value of a guaranteed option, the decision maker will be indifferent between the two.
Simply put, For all lotteries $L1,L2$ either $L1 \succsim L2$ or $L2 \succsim L1$ where $\succsim$ indicates a preference relationship. For more information, check out the Debreu theorems
The St. Petersburg Paradox¶
Finding the expectation of a lottery may seem like a useful tool in most decision-making situations, but consider the following gamble:
Suppose you were made an offer. A fair coin would be tossed continuously until it turned up tails. If the coin came up tails on the $n^{th}$ toss, you would receive $\$2^n$ i.e. if it came up tails on the 5th toss, you would receive $\$2^5 = \$32$. How much would you be willing to pay to participate in this lottery?
Intuitively, we already know that not many people would spend much to play this game. But why? To visualize the paradox, we can re-write the game in Python.
Game: Get payoff that depends on when heads comes up first on toss of fair win.
Payoff: $2^{i}$ where $i$ = toss number of first H
In [10]:
def game(): i = 0 #number of heads while(True): flip = (np.random.randint(low=0,high=2)) #If the flip is a tails, return the payoff if flip == 0: return 2**(i-1) #If the flip is a heads, flip again else: i += 1
In [11]:
trials = [game() for x in xrange(0,10000)] plt.figure(figsize=(15,5)) plt.plot(trials) plt.xlabel("Trial number") plt.ylabel("Payoff") plt.title("St. Petersburg Lottery") print("Expected value of sample:", np.mean(trials))
('Expected value of sample:', 6.10215)
This question is asking for the amount someone would be willing to pay for such a lottery, so we can consider this question as asking for the certainty equivalent of the lottery. The certainty equivalent is the guaranteed amount of money that an individual would consider just as desirable as a risky asset (lottery). We calculate the certainty equivalent by taking the expected value of the lottery. But given exponential payoff of this function, we encounter a problem: This gamble has an infinite expected value!
Expected payoff = $(\frac{1}{2}^0 *2^0) + (\frac{1}{2}*2^1) + (\frac{1}{2}^2 *2^2) + (\frac{1}{2}^3 *2^3) + … + (\frac{1}{2}^i *2^i) =\infty $
Despite the fact that the expected payoff is $∞$, only a few people are willing to pay much for this lottery.
This problem is known as the St. Petersburg Paradox. To understand why decision makers are not willing to purchase this lottery, it is important to understand that decision makers are utility maximizers not outcome maximizers. Instead of calculating the expected value of the lottery, we instead calculate the expected utility of the lottery.
Mathematician Daniel Bernoulli, suggested that when we take utility into account, we can develop a solution. He states, “The determination of the value of an item must not be based on the price, but rather on the utility it yields…. There is no doubt that a gain of one thousand ducats is more significant to the pauper than to a rich man though both gain the same amount”
This theory of utility maximization is explained by the law of diminishing marginal utility which states that when a decision maker consumes a specific good, the next good consumed will be less enjoyable than the previous. So, the marginal utility, the difference of utility between the consumption of a good and the consumption of a consecutive good, will decrease.
In [12]:
def utility_table(size): n = np.arange(0, size, 1) p = pd.DataFrame() p['n'] = n payoff = 2**n p['Payoff'] = payoff p['Probability'] = 0.5**n p['Expected Payoff'] = p['Payoff']*p['Probability'] p['Bernoulli Utility Function'] = np.log(payoff) p['Expected Utility'] = p['Bernoulli Utility Function']*p['Probability'] return p table = utility_table(size=10) display(HTML(table.to_html(index=False)))
n Payoff Probability Expected Payoff Bernoulli Utility Function Expected Utility 0 1 1.000000 1 0.000000 0.000000 1 2 0.500000 1 0.693147 0.346574 2 4 0.250000 1 1.386294 0.346574 3 8 0.125000 1 2.079442 0.259930 4 16 0.062500 1 2.772589 0.173287 5 32 0.031250 1 3.465736 0.108304 6 64 0.015625 1 4.158883 0.064983 7 128 0.007812 1 4.852030 0.037906 8 256 0.003906 1 5.545177 0.021661 9 512 0.001953 1 6.238325 0.012184
Given Bernoulli’s hypothesis of diminishing marginal utility, we can show that although the outcomes increase with each bet, the utility gained from each consecutive outcome will be lower than the last. Bernoulli suggests that we can model the decision maker’s utility using a natural log function. The natural log function is useful since it is monotonic (each additional unit provides additional gains in utility) yet diminishing such that the gains converge to 0 as x approaches $\infty$. $$u (x) = ln(x) $$ $$ u'(x) = 1 / x$$
In [13]:
t = np.arange(1, 10, 0.2) constant = plt.plot(t, t, 'r', label="Constant returns", linewidth=3) diminishing = plt.plot(t, np.log(t), 'b', label="Diminishing Returns",linewidth=3) plt.legend(loc="center right",) plt.xlabel("Quanity consumed") plt.ylabel("Total Utility") plt.title("Constant marginal returns vs diminishing marginal returns") plt.plot()
Out[13]:
[]
Graphically, we can see utility uniformly increases as the payoff exponentially increases. However, the expected utility decreases since the probability exponentially decreases.
In [14]:
table = utility_table(size=5) plt.figure("Bernoulli Utility Function") expected_payoff= plt.plot(table['n'], table['Expected Payoff'], 'r', label="Expected Payoff",linewidth=3) diminishing = plt.plot(table['n'], table['Bernoulli Utility Function'], 'g', label="Utility",linewidth=3) expected_utility = plt.plot(table['n'], table['Expected Utility'], 'b', label="Expected Utility",linewidth=3) plt.legend(loc="center right",) plt.xlabel("Number of heads") plt.ylabel("Returns") plt.title("Utility vs Payoff") plt.plot() plt.figure("Comparison") constant = plt.plot(table['n'], table['Payoff'], 'r', label="Payoff", linewidth=3) diminishing = plt.plot(table['n'], table['Bernoulli Utility Function'], 'g', label="Utility",linewidth=3) expected = plt.plot(table['n'], table['Expected Utility'], 'b', label="Expected Utility",linewidth=3) plt.legend(loc="center right",) plt.xlabel("Number of heads") plt.ylabel("Returns") plt.title("Utility vs Payoff") plt.plot()
Out[14]:
[]
For calculating the certainty equivalent, we need to take the sum of the expected utilities for an infinite number of trials. Since the function converges, we can reach an estimate as n approaches $\infty$ $$E(L) = \sum_{n=1}^{\infty} \frac{1}{2}^x * ln(x) \\ = \sum_{n=1}^{\infty} 2^{-x} * ln(x)$$
So, we can estimate the certainty equivalent as:
In [15]:
table = utility_table(size=1000) util_lottery = np.sum(table['Expected Utility']) print("The expected utility of the lottery is ",util_lottery) print("The certainty equivalent of the lottery is ",math.exp(util_lottery))
('The expected utility of the lottery is ', 1.3862943404624948) ('The certainty equivalent of the lottery is ', 3.9999999173704177)
Since we are still dealing with a utility function, the certainty equivalent will not be 1.386. Instead, it will be the antilog of 1.386. In other words, we are trying to find the parameter that makes our utility function = 1.386. So, we can estimate the certainty equivalent as:
$$CE = e^{E(L)} = e^{1.386} = 4$$
A final note¶
The logarithmic utility function that Bernoulli proposes is case specific to the $2^n$ lottery. By adjusting the values in the lottery, we can again make it a paradox with an infinite expected value. The St. Petersburg paradox is used to demonstrate that there are diminishing marginal returns to utility and we can take further steps to model choices under uncertainty.
0 notes
Link
The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community. The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.
This article was originally posted here.
In my personal definition of what constitutes a real-time strategy game, one of the genre’s key requirements is that there be some sort of economic component. Specifically, a real-time strategy game asks players to acquire and expend some sort of store of value in order to expand their ability to modify the game’s state (that is, to build units, perform research, activate abilities, et cetera in pursuit of the game’s objective).
In most RTS (what I will call “traditional RTS” in this article), the resulting system is a variant or extension of the model introduced or popularized by Dune 2: players acquire resources to build structures, which provide access to units or additional structures, produce units, add functionality (e.g. turn on the minimap) or make research options available. Some of these structures may play a role in the game’s economy: serving as a drop-off point for one or more of the game’s resources, generating resources themselves, and/or producing units that harvest resources.
In previous articles, I have advocated for the efficacy of such systems. They have a lot to offer, and it is my firm belief that competitive strategy games suffer when a player’s ability to have nuanced control over a game’s economic interactions is restricted. In short, competitive strategy games best serve their player base when they provide multiple paths down which a player can exercise mastery and drive success: economics, infrastructure, combat tactics, research, scouting, et cetera. I tend to think of this, personally, as vectors or hooks on which a player can hang a victory.
It is my contention that the “traditional” model of RTS design contains some inherent or baked-in features which provide players with incredible autonomy, but ultimately drives a very steep slippery slope or “snowball” curve that can erode the quality of gameplay. In this article I will attempt to address what I see as the strengths and weaknesses of common themes in real-time strategy base and economy management, and attempt to identify aspects of a variety of games I see as ultimately the most empowering and engaging for players. And hopefully, I will be able to explain why I feel this is important.
Thanks for reading. Let’s get started.
Economic operations are a separate though related system from army management: building, protecting, and managing one’s economy in the classic RTS franchises (Command and Conquer, Age of Empires, and the -Craft games, among others) provides a unique stream of objectives, unique types of operations, and unique types of challenge, decision points, and methods of skillful play that differ from army management in terms of execution and mindset.
What do I mean by that? When building up one’s economy to fund the expansion of their army, the player is making a series of decisions down a variety of paths, each influencing the availability and feasibility of other decisions they will face. Production, research, economic expansion, army expansion, and information gathering are all products of a player’s time, attention, and physical game resources (e.g. Gold or Vespene Gas).
Each of those facets of gameplay requires both short-term and long-term decision making that impacts the overall progression of the game. Short-term decisions are mostly trade-offs: do I build an additional worker to increase my income, or do I build an additional soldier to better defend my holdings? When (and where) should I build this production building to take advantage of my income? Tactical decisions in the early game are likewise trade-offs; moving one of your few early-game units is a risky bit of force projection that could leave the player vulnerable to counterattack.
It’s these sort of decisions that many hardcore players of RTS deeply enjoy, and for good reason. Few other types of game provide players with such a rich patchwork of opportunities to be successful in a large variety of ways. The best RTS give players tactical and economic autonomy to drive efficiency and excellence – to outplay their opponents along multiple vectors.
Most strategy games in which economy is linearly increased via sustained production (meaning, most strategy games) tend to embrace the idea of snowballing. That is, due in part to the growth curve of the economy – I’ll go into some other reasons as well – advantages tend to pile up, and setbacks tend to have a similar pile-on effect. Winning an individual engagement or interaction has a tendency towards making winning future engagements more likely, which increases the overall chance of victory. Sometimes, I’d even go so far as to say quite often, this tendency can be quite pronounced.
Please do note that I intentionally use the words “tendency” and “chance” – this is not always a done deal. But in the vast majority of RTS games, a single decisive victory in a single engagement can start tipping the game’s balance in one player’s favor in ways that can feel irrevocable. These games are designed in such a way that balances them along some very thin seams that are subject to disruption. And often, disrupting one facet of a player’s plan (killing an army, destroying an expansion, et cetera) simultaneously confers benefits across a wide swath of the game state.
There are, however, several examples of games that have a trend over time of allowing players to seesaw back and forth across the line of balance. These games trend towards an overall equilibrium between players that requires non-trivial and repeated effort to imbalance, and whose vectors for victory are independent enough to allow a player on the back foot in one regard regain standing via manipulation of other game facets.
It’s my contention that this sort of design, what I like to call ‘homeostatic design’ is overall friendlier to players, resulting in the potential to drive more engagement in competitive multiplayer.
In my personal parlance, homeostatic design in strategy games refers to how difficult it is to achieve an advantage that an opponent cannot overcome. One of the most straightforward examples of this principle are the dynamics of Zerg vs Zerg in StarCraft 2 – due to the nature of Zerg production and the way their economies scale, it is virtually impossible for a player to recover from losing even a handful of Drones in the early stages of such a match. Zerg mirrors in StarCraft 2 have knife’s-edge balancing in the early game, which often leads to a player quitting after only one or two disadvantageous engagements. While exciting and tense, such gameplay is incredibly unforgiving. In play, it is a theory of mine that losses are easier to swallow if a player feels like they understand why they lost, and if they feel like they understand how they have a path forward to improving. What’s harder to swallow are losses that felt inevitable, decided by factors beyond the player’s control.
In many real-time strategy games, it is very easy for slight advantages to snowball as matches are decided in the early minutes of play. Moreover, those early minutes of play are often intensely regimented, as players spend the bulk of their limited playing time building an infrastructure that might not amount to anything. So, ‘homeostasis’ in this context refers to the tendency of any individual interaction to irrevocably alter the course of a game.
What does homeostatic design look like in a real-time strategy game? Easy examples come from Relic’s games, as well as the Command and Conquer series and Supreme Commander. In Company of Heroes 2, player objectives fall into two general categories: capture map territory, and destroy the enemy’s army. Capturing map territory is a system with multiple levels of success: converting a point held by an enemy deprives them of its income, while capturing it yourself adds to your ability to produce units, use special abilities, et cetera. Additionally, the nature of control points in COH2 means that hitting a vulnerable choke point could deprive the enemy of virtually all of their income for a period of time.
Armies in COH2 are relatively small for the size and number of POI they have to cover, meaning that a player who is numerically behind is still able, at least in theory, to continue to contest the map and keep their enemy off balance. The highly specialized nature of units in this game likewise reinforces this sort mentality: many units are able to be effective without requiring overpowering numbers to be produced. This allows players with numerical disadvantages to continue to be effective. Other things can help break up fights and provide situational advantages, as well: mines, barbed wire, smoke, suppression weapons, and more.
Secondly, and I think this is one of the most important factors in the game’s model. The game’s two main objectives: destroying enemy forces, and taking territory, are partially independent. Gaining ground against your enemy in terms of territory doesn’t automatically snowball your chances of victory as, say, destroying an enemy expansion or killing off enemy workers does in StarCraft 2. Likewise, driving off an enemy army (the more common scenario in COH2) doesn’t itself provide a numerical or lasting advantage, mostly giving the successful player room to breathe to take more territory or attempt to secure the territory already in their control.
Lastly, and be assured this is something I’ll come back to: many game objects in COH2 aren’t sunk costs. Unit weapons, support weapons, and even tanks have some degree of permanence on the battlefield. This allows them to change hands repeatedly over the course of a match, and can allow a player on the back foot to instantly and without resource cost acquire the means with which to continue fighting and succeeding. This knife can cut both ways, to be sure, but the system is remarkable for allowing interesting and dynamic gameplay.
Company of Heroes 2 can feature some strong snowballing itself, particularly in team matches – the reinforcing effect of cooperative unit and tank squads can become virtually unassailable when one player or team is faced with recurring or excessive loss of materiel (this is one reason why German teams tend to perform better than Allied teams – their tanks tend to be heavier which means they have an easier time keeping them in tact – a lower replacement rate can add up over time, and their endgame armies are simply harder to kill). But overall, I find it less generally prone to snowballing due to what I’ve listed above.
But is this homeostasis, this natural equilibrium, a good thing? Is it good, generally, that games would tend to ‘revert back to center’ and wouldn’t necessarily reward success with more success? Typically, computer strategy game design philosophy seems to indicate that the makers of these games expect a slippery slope – encourage it even. In a way, I appreciate this. In a genre that is designed to be one of the ultimate displays of skill, concentration, and mental performance in history, any action designed to curb the impact of player skill will hamper a game’s overall appeal.
I suppose this is determined by your definition of what makes a good and successful game. My approach and line of reasoning is driven by the sidelining of the RTS genre. Something, it seems to me, in these games is failing to reach a broad audience. Moreover, the recent trend towards the automation of RTS economic processes serves to me as an indication that simply streamlining is not going well for the popularity of strategy games in general. As ready examples, Act of Aggression and Grey Goo both automate aspects of their economic models to the point where it becomes very difficult to drive a win through economic operations.
So, what I’m attempting is to identify design trends that I feel are keeping players out of RTS multiplayer, and attempting to address those design trends in a positive and reasoned way. Here are my premises, in general:
Snowballing makes players feel powerless and frustrated
Infrastructure should be decoupled from objective
Base management/infrastructure (as commonly implemented) encourages uninteresting choices
Sunk costs increase snowballing
RTS can make room for lessons from other competitive genres.
The early game is one of the most frustrating phases of competitive gameplay. Mid- and late-game are players’ favorite phases because they offer the most freedom to act and the largest number of options
To me, one of the core issues surrounding traditional RTS design is that of sunk costs. A sunk cost is one that cannot be recovered. Commonly in RTS games, virtually every expenditure is fixed. Build a Barracks, and the resources used to produce it are stuck. They can’t be purposed in another direction. Losing that Barracks is far worse: those resources are just gone now. In objective terms, in a concrete way, the player is objectively worse off than they were when they had that Barracks.
Compare this to Command and Conquer, or Supreme Commander, or Company of Heroes. Resources in these games… They’re free to be reused, provided you have the time and concentration to do so. What’s more, resources in these RTS can actually change hands in meaningful ways. Losing a fire base in Supreme Commanders means that your enemy could harvest it to your detriment, while you could simultaneously be scooping up the remains of an old battle elsewhere on the map. This cost reclaiming becomes in itself a strategic and tactical consideration, adding another layer of interest and skill into the game’s resourcing system.
Sunk costs kill players. Losing a battle, or a part of your infrastructure, in StarCraft or Age of Empires is demonstrably worse than in the games mentioned above because there’s no chance of coming back from such a loss. You’re able to attempt to inflict loss on your opponent, or increase your income independently to account for the setback, but at best you’re able to trade some resource/income/infrastructure penalties on your opponent. The idea of economic counterplay, give and take, doesn’t really exist.
One piece of this puzzle, to me, is the idea of the permanence of resources. In the vast majority of real-time strategy games, units and structures are both sunk costs and impermanent. The only investments a player cannot lose, typically, are the research they perform. Research tends to be a permanent facet of a player’s arsenal, even if its impact and utility vary with army composition, unit availability, and owned structures.
In terms of resource permanence, Supreme Commander and other Annihilation-style games take a very interesting view. Everything that is built turns back into resources when destroyed. Everything, even Experimental units. These resources can be harvested, not in the game’s structure-based method, but by engineer units. These resources serve as a balance-tipper: salvaging an enemy’s wrecked Experimental can help fund an additional Experimental of your own. Further, SupCom and its sister games allow the player to steal, well, anything they can: factories, units, anything can be converted back into resources (sold) or captured by engineer units. This is a tremendous amount of fiddly detail in a game already full of things to do, but it provides endless opportunities to tip the scale in a player’s favor in small ways.
There’s a reason the -Annihilation games are so popular and memorable, by the way. It’s good to remember there are reasons for this beyond simply their scale.
Another aspect of common design seen in real-time strategy games is an incredible ramp-up from just a single unit or structure to a massive army of The Traditional RTS build-up phase provides a large number of vectors for success, but also opens up numerous situations that can result in widely unbalanced interactions between players, and create numerous opportunities for incredibly steep slippery slopes.
I don’t think, in some ways, that this is directly due to the game’s economic growth curve. In my opinion, Supreme Commander’s gameplay systems lend themselves towards general homeostasis going into in the mid-game: the number of points of interest, the number of production facilities, and both major and minor ways to tweak cost efficiency (building adjacency bonuses, reclaiming map objects as resources, converting enemy units, et cetera) lead to a situation where players need to find clever ways of tipping the scale.
The most ‘slippery’ portions of strategy games across the board – where interesting play choices are prevalent, but equilibrium hangs on a knife’s edge and homeostatic design breaks down – are often in the earliest minutes of play. Setbacks in the early game have a snowball effect on the late game. This is eminently obvious in StarCraft, in particular. Zerg vs Zerg matchups hang on this harsh truth, as mentioned previously.
The designers of StarCraft realized that these fraught moments, the incredibly imbalanced interactions possible in the earliest moments of the game, the fun-sucking moments that leave people wanting to put their keyboards through their monitors, were not optimal for keeping their community engaged on a casual level, a competitive level, or for observers.
In Legacy of the Void, StarCraft’s designers took extreme steps to truncate the build-up phase to make players less vulnerable in the earliest stages of the game. This opened up a wider variety of interesting strategies, more of the back-and-forth play that viewers love, and opened up the map more, and earlier. LOTV forces players to expand early and often, increasing the number of points of interest, increasing player vulnerability to counterattack while decreasing the overall impact of said counterattacks. While the LOTV changes increase the game’s mechanical demands, which were already intimidating for the average player, they at least band-aid some of what I’m trying to talk about here.
These changes illustrate 2 important things to me: First, that games with more points of interest are inherently friendlier to players than games with fewer POI. We also see this in Homeworld Deserts of Kharak, where the relatively number of POIs lends itself to army blobbing and limits overall gameplay dynamism. You know, without scouting, pretty much where your enemy needs to be and what they care about.
Fundamental problems: geographically constrained economic operations are at inherent odds with expansionist tactical operations. Build up phases introduce a large number of volatile resources that can be lost, leading to an increasing opportunity for unbalanced and, ultimately, un-fun interactions.
To untangle all of that, here’s the point. When you ask players to build a base, you’re giving them a huge and fragile infrastructure they have to protect. That infrastructure, in most cases, is a sunk cost. Losing a significant percentage of that infrastructure leads to a slippery slope. The location of this infrastructure tends to be predictable and geographically constrained, leading to a few areas of high importance on the map. This all adds up to a formula which, while it has a lot to offer, also tends to leave players feeling demoralized and powerless.
To borrow and mangle a phrase, traditional RTS design is the worst system… except for the others that have been tried. It’s a bit inaccurate, but kind of punchy, no? Here’s the problem: when designing tactical RTS, or RTS which attempt to reduce the game’s emphasis on economy, the number and impact of various success vectors is reduced.
If a game is created which, using the “traditional RTS” as a starting point or point of comparison, blunts the various impacts and implications inherent in base building and/or economic (resource gathering) operations, the game has 2 fewer major vectors for players to drive success. If the game includes systems such as terrain bonuses, directional armor, miss chance et cetera, it is just increasing the weight of unit choice and positioning, making that one vector even more important, and forcing players to master increasingly narrow and nuanced skills along this one vector to be successful.
This is one reason tactics games tend not to be as popular as traditional RTS, and one reason that modern attempts to streamline economy tend to suffer as well – in removing player agency and nuanced progression, these games are giving the players fewer ways in which to be successful, and making success along one path increasingly important.
Many tactical games also utilize some sort of control point system. Control points and territories have a number of important features: they force players to focus on something else besides pure combat efficiency. They force players to be proactive, and constantly move their units on the map. They force players to split up their forces to take and contest multiple objectives under experientially different circumstances. But, all or most of these operations are still focused directly around, or influenced directly by, tactical unit operations.
Where tactical games tend to stumble is giving players different categories of operation to perform, or different vectors along which to pursue success. And this is why basebuilding, traditional-style RTS are still the most popular and successful form of RTS design.
The core premise of my article is: players are the most engaged when they feel that the situations in which they find themselves are fair, balanced, and understandable. Competitive games should strive to create situations where players feel that they are engaging in equal interactions, and that their skill (both proactive and reactive, or both strategic and tactical) is the primary determining factor in their success in the game.
Let’s look at the issues again:
In the early game stages of traditional RTS, players are forced to perform a large number of operations in as short an amount of time as possible. This is a concession to the power of incremental improvements to expand the scope of the game in a way that does not overwhelm players, and to limit the damage done by an individual loss of an investment (unit or building). Average RTS ramp up curve is painful to a large section of the player base. Slower ramp-ups, like in COH and DOW series, or much quicker ones, like LOTV, are better overall solutions for increasing player agency and decreasing the wide variety of unbalanced and frustrating interactions that can happen in the early game phases of most RTS.
This is not an indictment of the “rush” as a tactic in real-time strategy games. It is an indictment against a particular variety of rush that is virtually impossible to scout in time to defend against, as well as the fundamental game mechanics whose design results in a preponderance of imbalanced interactions between players and an attempt to identify systems that include aggressive play that feels natural, fair, and engaging.
Player investments tend to be clumped together into bases, since the common protection of a large number of investments is the most efficient path. This tends to limit the number of points of interest on the map, and increase the value (and increase the pain of loss) for each one. A limited number of POIs coupled with extensive holdings to expand and maintain, inherently fosters a passive, defensive mindset. Many players are able to successfully overcome this (at least partially), but I am still noting it as something that must be overcome. Having a large number of points of interest decreases the pain of loss of each, and creates an incremental system of dominance in which the objectives are instantly identifiable and highly understandable.
Player investments tend to be sunk costs. Losing such an investment, especially with typical income generation models, means that the player is now inescapably behind with a limited palette of options to recoup their loss. Reducing the number of sunk costs can decrease snowballing and create more opportunities for dynamic counterplay that is interesting both to watch, and to perform.
Fast, or shallow, build up phases mitigate the most frustrating situations common in RTS. Fast build up phases also puts more pressure on rushers to execute better to be successful.
Thanks for taking the time to read this article. I hope that, at least, it has provided you some food for though about how RTS might be able to grow in ways that keep players coming back. I look forward to your comments.
0 notes