xurxodiz / mariolevels Goto Github PK

Once the package from #22 is done, we need people to execute it and send their data to us. Social networks are our best bet here: Twitter, Facebook, Reddit (games, gaming, favors, samplesize...)

What can we learn for level design from the classic Super Mario levels from the NES game?

Things like gap width, enemy frequency, block-coin relative placement ...

A first draft by hand has been made, but color-coding the elements in Photoshop can throw some new light that help us hardcode the probabilities for the automaton (see #8).

It would also produce some cool graphics for the report, easily reflecting design decisions that may be difficult to notice in text form.

When the post-level survey is displayed, ~1/7 times it will not show up correctly, with the background of the panel missing (thus black) or even with the Mario stage showing underneath. This renders the label text unreadable, though the buttons display ok.

This behavior seems like it only happens on frame mode, but we can't discard it happening in applet mode so far.

It seems like piranha flowers are not jumping out of pipes. Are we placing them properly?

If we have grammars from #36, nicely defined, we can use the percentages of membership from the clusters to mix automatons, evolving them to make them perfectly for for the player.

With a minimal change in the grammar definition, it's not necessary to specify weights. Makes grammars more clear and less cluttered.

A default value of 1 should be set in that case.

The repository should iterate through its dummies, ensuring their chains' odds add up to one.

The algorithm makes two passes over the stage to fill it. This issue takes care of implementing the second, that includes turtles, goombas, piranhas, cannons, boxes, coins...

Note that it doesn't mean we need to get the odds right; that's for another issue. This is just about making sure the functions are there and working.

At the moment of opening this issue, there is nothing done in this regard.

Continuing work from #16, related to #29.

Each cluster will have its own automaton. Design a level flow for each one and write the grammar/automaton accordingly (states, odds).

We have clusters in #25. We have transitions in #26. How do we assign each player, per his metrics, to each cluster, so he can have his assigned transitions? We need a classifier.

There are several kind of enemies. They are all different.

For instance, turtles can kill other enemies, spikys can't be jumped upon, cannons are extremely hard.

Cannons are a good hint of being playing in higher levels of difficulty.

And turtles and goombas can be winged, being harder to face.

Should we implement the enemies as different states in the automaton (#16)? Or just one state, and in it pick by a different criteria, or randomly (bad idea) which enemy to place?

Reflect upon this and decide.

The algorithm makes two passes over the stage to fill it. This issue takes care of implementing the first, that includes plains, hills, gaps and pipes (empty).

Note that it doesn't mean we need to get the odds right; that's for another issue. This is just about making sure the functions are there and working.

At the moment of opening this issue, we can get vanilla gaps, vertical hill changes and flatlands.

There are a lot of states that are basically the same. Couldn't we convert the automata into context-free grammars and thus reduce the number of states and overall make the system easier to manage?

What did we manage to do? What did we learn or obtain? What are the next steps? Where should we go from here?

The platform currently employs several buildThing functions (buildHill etc) to construct a level by concatenating parts.

Are they enough? At first glance, it looks like they could be further detailed, or parametrized, to create an array of possibilities. This could be the base for a genetic programming tree of conjoined level parts.

It would probably be helpful to build prototypes of levels with them to get familiar with them.

As per #7, we now will try to model the level building as a Markov process. We will, therefore, create an automaton in which each state is a different chunk, and upon entering them the map building function is called. The transitions between them represent the probabilities of a certain chunk to sequentially follow another certain chunk.

We must design the different states needed, and the transitions between them (links only, not values).

Absolutely required before proceeding to #17.

For convenience.

For the moment, the idea that seems more appealing is to create a general top level flow that gets the parts further defined by parameters picked from the user. The variation and randomness comes from the different ways that this top flow can be defined (e.g., "high stress" could come from many consecutive jumps, many enemies, or lots of coins).

After issues like #6 or #2 have been worked on a bit, we can further assert if this is the way to go or we need to rethink it.

Finally, a issue that is seemingly stress-free.

Levels can be of three types: overground, underground, or castle. They affect the aesthetics only, unless you want to respect the classic distribution of enemies per stage. Of course if it's underground it would be nice to paint a ceiling.

Easy mode: randomize it (current approach). We don't let enemy placement be affected by the choice, hell, we don't even place ceilings for the underground stage.

Hard mode: make a difference between the choices, and pick a criteria for selecting them.

Setting the transition values is complicated, needs quite the fine-tuning. Could we try evolving them with a genetic algorithm?

The automaton fills the stage and then we superpose the ending platform over the last part. This means that sometimes, we get enemies, boxes, coins, etc in that platform.

We need to clean that when we build and place the exit. Cleanse the wound before the bandaid, if you will.

The tension wave will be one of the factors that generate the chances for the different chunks. Issue #8 will take care of its specific weight (probably in relation with the difficulty of each chunk). But this is about how to generate the value for this factor.

Leading theory now is to use a basic harmonic wave w = Asen(bx).

Factor b should make sure that the wave's phase is a divisor of 320, the current stage width, so it both starts slow and ends slow.

Or should it?

This kind of thing should be figured out.

LakituParameters, or LKP for short, is the file where all the odds are generated. Right now is a messy collection of member fields. As it grows, specially when the functions are added, we should try to institute some order into it.

Bertha provided a template. We should download it, fill the relevant data (name, date, etc) and add it to the repo in preparation for the writing.

After playing a level, the user gets presented with a small survey. Right now, the question is:

Did you like this level more than the previous one?

We are not doing anything with the reply but printing it to output: it should be stored somehow for use by the algorithm.

(Originally part of #3, I thought it better to split them)

We need to process the object-files obtained from #22 into vectors that can be easily imported and processed in #24. It would be best to have a runnable Java script so we can call it whenever we have new data.

Right after #47 or simultaneously, implement chunk functions if they are needed.

This closes and succeeds #9 and #17

Paper is almost finished. Hear what your peers have to say about it before sending it and fix it.

The folder where player data logging is stored varies depending on frame or applet mode due to different values in user.dir system property. In the first case, it's at lakitu/players; in the latter, lakitu/bin/players.

Right now, the data is moved manually in every commit to the first path, for coherence. A permanent solution should be found.

Define the automaton transitions (from #17) for each cluster obtained in #25, according to inferred gameplay style.

We need to explain what is the problem and the domain, what steps have been taken in this area or other similar. Also, gather all the bibliography we've been using for the last weeks to guide us, for reference.

Once we have the data from #22 and the clustering algorithm from #24, feed one to the other. Get the clusters and centroids.

As we traverse the level filling the blanks, there are so many chunks we could include. Some of them have to be more "fine-tailored" by the designer, since they are messy to leave to randomness (say, a gap you need to jump with help of specifically placed blocks).

Moreso, every extra chunk is another probability to generate (see #8), complicating the algorithm.

Alas, we have a time limit so we need to draw the line somewhere. Figuring that line is what this issue is about.

For the algorithm, it would be very convenient to have all chunks to a fixed length of 2. We can predict how many iterations we need to fill a level of a given length. That also ensures that the WorkerState genotype of any two levels of the same length has also the same length. It enables us to use genetic shenanigans.

If we want data for the clustering algorithm (see #8) we need users to play the game. We should create a extremely user-friendly zip package. That package should contain:

• The marioai platform, as provided, ready to be executed.
• Three points of entry (scripts). Double click and the game runs. One each for Windows, Mac and Linux.
• A short readme file, detailing
  • How to run the game
  • What to send and where to

Triple check the working condition for the three operating systems.

To create clusters for the data gathered in #22. Héctor recommends Expectation-Maximization as done by Weka. Is it our best choice?

We'll be giving it a couple dozens of entries, each with around thirty variables, and we expect to get the clusters, the entry-cluster associations and the centroids from it.

Title: clear, colorful and representative.

Abstract: succint summary of the idea and techniques.

Extra hills (beyond the ground) are common places to have coins, enemies or just decorate. How do they fit in our algorithm design?

How did we do it? What were the design choices? Why did we opt for that way? How did we organize everything? What were we trying to achieve or obtain by taking that route?

Sort of a meta-issue, this one. It would be nice, for archiving purposes, to upload to the repository the zip package that was distributed (#21, #22).

I'm classifying it only in clusteringt because I'm too lazy to create a "repository" label that I don't think I will ever use again.

Issue #16 defined an automaton. The new idea shaping the system is to generate the chunks by traversing it, each state producing a new part of the stage lineally.

We should then create classes for both the Automaton, the State interface, the several individual States defined in #16 and methods for traversing them that call the appropriate level building functions.

Build upon the methods already created in #11 and #12, reusing the salvageable code.

After playing a level, the user gets presented with a small survey. Right now, the question is:

Did you like this level more than the previous one?

Is this is the most useful question? Furthermore, should it be the only one?

A report has to be delivered for the thesis presentation.

We should find out:

a) number of pages
b) other requisites.

So far, PlayerDataRecorder stores no record of the level played. (That presents a gaping hole since, you know, we are supposed to be generating and adapting them, so it would be helpful to track their evolution.)

But to implement that, however, we need to first decide on a storage format for the levels, which probably means we need to decide (or at least get an idea) on how are we going to evolve them after.

It came back from the dead! Deadline extended until Sunday midnight.

David will give us some feedback. In the meantime, let's see how far we can go with #36 and #39.

DFP and CG read and write files whose paths are hardcoded in the code. That makes me a sad panda.

They should read them from arguments, and we'll take care of those from our newly minted Ant buildfile (#42).

Implement the algorithm chosen in #23 in Java, integrating it with our current architecture.

The algorithm makes "passes" over the level, filling it with different chunks. The chunks are chosen by rolling a dice and checking the odds for each element. How do we figure out those odds?

Candidates so far include neural networks, clustering, genetic algorithms and basically everything.

After picking the clustering the cluster algorithm (#23) and implementing it (#24), but before hardcoding the transitions (#26), we need to interpret the results so we can assign them values that make sense. What does each cluster represent, according to their disparity in the values?

(Continuing work from #36)

Elements in the grammar should become implementers of the State interface. they can either be DummyStates or WorkerStates, depending on if they actually build the scene of just transition through their chain.

WorkerStates might be Enums, as States of yesteryear used to be.