music

hopefully I can get some microphones and record this stuff so it sounds better before we finalize things, but here are some midi files of game music.  yayyyyyy music.

The importance and role of state machines

At the core of the new design is a state object that is shared between the multiple helper objects in the system. This separation of state and function enables coherency throughout the entire system, a coherency that was not possible in the first design. While every piece of software is what we call a state machine (including the first design), the realization and exploitation of this fundamental nature of the system empowers the designers to more fully understand and more effectively implement the functional requirements of the system.
But what is a state machine? Defined by Wikipedia's article:

A finite-state machine (FSM) or finite-state automaton (plural: automata), or simply a state machine, is a mathematical model of computation used to design both computer programs and sequential logic circuits. It is conceived as an abstract machine that can be in one of a finite number of states. The machine is in only one state at a time; the state it is in at any given time is called the current state. It can change from one state to another when initiated by a triggering event or condition; this is called a transition. A particular FSM is defined by a list of its states, and the triggering condition for each transition.

In simpler words, a state machine is a conceptual device composed of distinct states and transitions between those states. As an example, consider an ATM: simplified, it has quite a few states:

logged out

Nobody is using this ATM

logged in

Someone has logged in

card-check

Somebody has put in their card

transaction in place

The user has requested a transaction

These are all potential states the ATM can be in, but it can only be in one at a time. It is the interaction with the ATM that constitutes the transitions between these states:

• When logged out, enter card-check upon a user putting in their card
• When in card-check, enter logged-in upon credential confirmation
• Upon appropriate input, enter transaction in place as appropriate
• When logged in, enter logged out upon appropriate input

Additionally, each of these states causes the ATM to exhibit certain behaviors:

logged out

display advertisements

logged in

display possible transactions

card-check

display progress bar

transaction in place

display progress bar

State machines are all around you—you need only look around.
Our game is now very similar. While every piece of software is a state machine in the end, coherent pieces of software usually have some sort of state the the explicitly keep in some custom data structure. We now have exactly this; our implementation keeps track of many different states of the game (while DFAs are one-state only, equivalent NFAs allow multiple concurrent states), such as which way the player is facing, what power they've selected, what map their on in the world, their current position on the map, etc. By sharing this state object between the interface and the player, we can keep consistency in the design and keep the code clear.

The Great Refactoring

It's high time for a technical post. I'll have to edit it tomorrow morning to clean it up, though. Two line breaks do not constitute a paragraph.

In fact, this desire for good structure is the cause for this post. The development team has been working hard on rewriting the game engine to be more manageable, more extensible, and frankly more readable. (For those not technically inclined, programmers do need to read code to be able to understand it.) This logical restructuring takes an incredible amount of time, effort, thought, and forethought to be effective, and we have come up with such a system.

We are still fleshing out the implementation and, in the process, refining the architecture of the system to line up with what is technically possible within LibGDX (our core engine). With beta tests a mere week away, we are working around the clock to bring a fun and functional game to the table.

Dealing intuitively with game objects and design patterns (such as Model-View-Controller) and finally collaborating in development via GitHub, development is moving quickly. In four days, we have centralized all game logic and assets, simplified the workflow by which tests are run (to nil in comparison with the previous state), and have created a framework that separates function and responsibility between multiple concepts that interact in simple ways. Over fifty nontrivial commits in, it has been a very productive week.

Main Screen

Butterseal Title Page

Power Buttons

Fire

Growth

Jumping

Light

Strength

Swimming

powers

today we figured out what our powers will be!

1.fire
2.jumping
3.strength
4.light
5.swimming
6.growth

we liked natalie's idea about having a deeper section of the cave that you cant see without light, but we want it to be something to return to which is why we have light later on in the game. we're also working on puzzle design.

a running sprite (i might still change the character design a little so it's cuter / not as brown idk) and a VERY sketchy in progress map concept for the ice caves. i'm thinking, to get into the cave, you either need an ice-melting ability that you collected previously, or you just need to collect enough music that the ice blocking the cave entrance is melted.

then when you're inside you will walk around and get by icy obstacles by melting them with your MELTING ability. at the bottom you will enter a new map which is darker/deeper and might involve sliding ice puzzles. to the right is a pit, and you can go down it but you can't move into the black area without a light! so, in the sliding ice puzzle area, you'll have to find a music note that will give you a LIGHT ability.

then when you can navigate the dark area, maybe it will be a tunnel that returns you to the surface -- but a different part of the map you couldn't access before.