Kevin Song
I'm a student at UT (that's the one in Austin) who studies things.
Most of the time, it's simulated using completely inextensible cloth or very stretchy cloth, and without collisions.
If cloth is used in places where this doesn't work, it's often hand-animated.
Games that don't do this tend to suffer performance issues, even today.
One student noticed that any time their character's clothes stretched or deformed in Star Citizen, they went down to 30 FPS.
Yes. In fact, while small-scale Minecraft terrain generation is done by techniques we haven't covered (Perlin Noise and Perlin Worms), the large-scale stuff is handled by stochastic cellular automata and image kernel-like algorithms.
Vote for procgen as a subject if you want to know more!
treasure?
children?
slovenly?
treasure?
children?
slovenly?
Highly likely!
Not likely, but possible depending on what came before this sentence.
Not actually valid English, highly unlikely.
Of course, if you always construct the most likely sentence, you'll get very boring (or sometimes undesired) results so in practice language models do a little sampling from the space of likely results. This is controlled by the temperature parameter.
Fun fact about the LLaMa models...
Knight to B1. ... ... ... ... Knight to A3 <OR> Knight to C3 <OR> knight to D2. <more moves>
An example of what the model might have gotten during training.
Note: no hard and fast rules about knight movement, just that knight moves to B1 are usually followed up by moves to A3 or C3.
Well the model knows that moves are still of the form <piece> to <square> but it doesn't necessarily know what rules it has to follow.
For instance, queen to C6 is a valid move, but only if the queen hasn't already been captured. If you look at it only from a language modeling point, this is a reasonable move to play.
Note that the model actually plays really well in the beginning, because openers are well-studied and written down in lots of places.
It's only once the game enters a state where you wouldn't reasonable expect to find the game state already studied in written material that the model starts to break down.
Once you start to think of language models like this, a lot of their quirks become a lot easier to explain.
These are currently being worked on, but it is unknown if they are fundamental to the language modeling approach or flaws in our current understanding.
This is a philosophical question and one that I'm not qualified to answer.
Experimentally, the top language models tend to be much better at creative tasks than most people. Whether this is because they're truly reasoning through langauge or because they've basically memorized the entire internet is undecided.
So many of these issues are "solved" in ways that just make the issues non-visible to the user, slightly degrading the quality of the tool in the process.
The things we need to respond to in our program are termed "events."
Events can be system-generated or user-generated, but are almost always external to the program---we can't control when they happen.
When events occur, we execute code which alters the program state. This is termed "event-driven programming."
Taken to the extreme, this creates a paradigm known as "reactive programming."
Unless you plan to write your own user interfaces from scratch (not recommended!), you'll likely be programming interfaces using an existing toolkit.
These toolkits already know how to recognize most common events, like mouse click, mouse drag, window close, etc.
The programmer is responsible for writing functions that will be called when these events occur, and telling the toolkit which functions to call on which events.
void clickCallback(){
playPauseSound();
displayMenu();
pauseGame();
}
// Without being told to, the program does
// not know it needs to run mouseClick() on
// mouse click, so we tell it this in main()
void main(){
GUI.registerHandler(ON_CLICK, clickCallback);
}
A common programming technique: we register a function to be called when something happens. Example in fake-Processing:
Short for "Graphical User Interface". An interface with a visual component.
Designed for easier, more intuitive experience. Typically based on event-driven programming.
Did you know you can browse the web using only the keyboard? To the left is the eLinks browser.
I'm glad I have Firefox.
Question: what are common interactable elements of GUIs?
A general name given to interactable elements within a GUI, including things like:
Give us different ways of interacting with program behavior and configuring the program.
Simplest form of widget. Allows for functionality on mouse click.
Buttons need to be aware of the mouse position and the button boundary.
Button
class. This class should have a method that takes screen coordinates (as separate x, y parameters) and checks whether the coordinates are within the button or not.You will extend the Button for today's second Hands-On.
A specialized button with an "on" and "off" state.
What do we need to store to track a checkbox?
A specialized version of checkboxes. Only one radio button can be on at any given time---when one is set to on, all others must be set to off.
Questions
What value does this correspond to on a slider?
How about this one?
How about this one?
Slider's value is determined by a linear interpolation between the end position of the slider.
0.0 * SLIDER_MAX
1.0 * SLIDER_MAX
0.75 * SLIDER_MAX
This also works for non-linear sliders (like knobs) with some modification.
Make sure you demo them in your sketch.
Existing libraries for Processing can simplify the GUI creation process.
Sketches -> Import Library -> Add Library -> [name]
You are not required to write more than an quick outline of your project. However:
This will depend on group sizes in the class. We might be looking at anything from a very strict 5 minute time limit to a setting where almost nobody needs to watch time very closely.
Explain what you did! There are tons of small decisions and other things to explain to someone who's never looked at your project before.
For reference, I've seen engaging, interesting 7 minute presentations on a 2D "throw a ball" simulator.
Also, look on Canvas for other requirements.
In 1D, there are exactly 256 possible CAs that use neighbor information. Stephen Wolfram has catalogued them in his book, "A New Kind of Science."
Rule 250
Rule 90
Rule 30
Very hard to categorize all of these, but many interesting behaviors.
No, but....
Automata (not cellular in nature) power most rule-based systems.
AIs in games tend to be one of two systems, both discrete automata:
For more general AIs, before the neural network + backpropogation paradigm was shown to be effective (ca. 2010), the primary AI tools were automata-based.
Not with infinite resolution, but yes.
In fact, some of the earliest graphics programs were generated by slightly more general CAs!
Debugging broken code is significantly harder than writing new code. I have never heard a professional developer express an opinion contrary to this.
It's even harder in graphics because certain parts of the "regular" debugging cycle are much harder or even impossible to do, so debugging broken graphics code can become very interesting.
Observe a problem.
Think of things that could be causing this problem.
Try to observe parts of the program that let you distinguish between your potential causes.
Fixed!
Apply change to prevent issue.
Issue disappears
Do we see something consistent with our potential cause?
Dang.
Yes.
No.
* You can do this a few times as a sort of quick-and-dirty debugging path. If it doesn't work 2 or 3 times, then STOP! Back up, take a breath, and take it slow and steady.
My Game of Life was not showing any change in squares.
def calculate(lst):
total_i = 0
total_e = 0
for t in lst:
if t['t'] == 'i':
total_i += t['a']
else:
total_e -= t['a']
return total_i - total_e
def total_income(transactions):
income = 0
for t in transactions:
if t['type'] == 'income':
income += t['amount']
return income
def total_expenses(transactions):
expenses = 0
for t in transactions:
if t['type'] == 'expense':
expenses -= t['amount']
return expenses
def calculate_net(transactions):
income = total_income(transactions)
expenses = total_expenses(transactions)
income - expenses
Good naming and commenting in your functions can save you a lot of grief!
Structuring code into functions can allow you to test things without suffering printspam.
void main(){
// ...
for(int i = 0; i < 100; i++){
for(int j = 0; j < 100; j++){
array[i * width + j] = array[i+1 * width + j] + 10;
}
}
// ...
}
void main(){
// ...
for(int i = 0; i < 100; i++){
for(int j = 0; j < 100; j++){
float val = func(array, i+1, j);
array[i * width + j] = val;
}
}
}
When writing your code, do it as simply as you can.
If debugging is harder than writing, and you're using 100% of your cleverness when writing the code, how are you ever going to debug it when things inevitably go wrong?
NOTE: When you're still learning to program (as you are now), there is a tendency to favor cool tricks over boring code. This is fine (I would even argue that it is good) but remember that this does make it harder to debug later.
By Kevin Song
I'm a student at UT (that's the one in Austin) who studies things.