Welcome, Guest. Please login or register.

Login with username, password and session length

 
Advanced search

1411283 Posts in 69325 Topics- by 58380 Members - Latest Member: bob1029

March 29, 2024, 01:05:58 AM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsCommunityDevLogsForesight Fight - A puzzle game with tactical RPG combat
Pages: 1 2 [3] 4
Print
Author Topic: Foresight Fight - A puzzle game with tactical RPG combat  (Read 20093 times)
bayersglassey
Level 0
***



View Profile
« Reply #40 on: December 11, 2020, 10:13:18 PM »

Wow. :O
This seems like a game designed for programmers!

The game is like a pure function: Tuple<Encounter, Party, Tactics> -> Stream<EncounterState>
You have a party, you choose an encounter, you choose your tactics, then play them to see the resulting stream of states. If the stream terminates, the final state can be inspected to see if you won/lost/drawed.

I do like the graphics and sound, but I can only imagine playing this at a REPL.
Something like:


ffight run encounters/1.json party.json tactics.json >results.json


And aside from "run", ffight takes other commands for listing enemies and party members, listing available actions for a given party member, etc.

And for instance tactics.json is something like:
Code:
{
    "party": [
        {
            "type": "warrior",
            "equip": [
                "head": "item.5",
                "left_hand": "item.8"
            ],
            "actions": [
                {
                    "type": "attack",
                    "with": "left_hand",
                    "target": "enemy.0"
                },
                {
                    "type": "attack",
                    "target": "enemy.0"
                },
                {
                    "type": "use",
                    "target": "item.3"
                }
            ]
        }
    ]
}

*Mind drifts away...*
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #41 on: December 12, 2020, 06:40:16 AM »

Yup, that JSON is preeeeetty close to how the game represents its internal state. Including a command line interface like that isn't something I had thought of before, but it's a super interesting idea! I'll definitely make a note of that and see if it would make sense to do. Like, it fits perfectly, and I'd love to be able use my work to encourage learning about this way of thinking.

Also, whoops, I didn't get around to writing a post for this week...

The scenario editor grind has steadily continued. I decided to take on the most complicated part of it to get it out of the way: The formula editor.



Every aspect of a formula can be fully edited now inside the game, and it's actually a lot of fun to play around with it. I've only wired up the scenario editor screen enough for the two formulas that determine champion resource capacity and change per turn to be edited, but the formula editor code is finished and will work the same way for everything else in the formula once they become accessible from the editor screen. I have a lot of things to think about as far as user friendliness and documentation, but it's more than good enough for my purposes, and actually feels a bit friendlier to use than editing the JSON directly. As partial as I am to text editors, it's a lot of syntax to remember, and not having to look up bits of it each time I want to make an edit lets me focus entirely on the math.

Now that the formula editor is done, I'm back to wiring up the rest of the editor categories. Champions can now be fully edited:



The remaining editor screen work is small enough that it's plausible I'll have it all there by my next update. Going to push through and see if I can make this happen.



Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #42 on: December 30, 2020, 08:58:26 PM »

Editor progress. Equipment can now be fully edited, and I finally got around to implementing a save system so that changes can be written to disk.



After checking this off my list, I wanted to move swiftly through all of the other categories of data I can edit. However, things took a turn when I started working on an encounter editor... I'd been accumulating a bunch of notes on aspects of my data structure that needed reworking, and this seemed like the perfect time to do it. I ended up making some pretty sweeping changes that took up most of my time since last update.

Gameplay used to take place in either an "encounter", or a "puzzle". Both of these contained a battlefield with enemies placed on it and actions assigned to them, and rewards potentially earned for clearing, with the only difference being that a "puzzle" came with its own fixed inventory instead of using the player's accumulated collection over the course of the scenario. There were also "challenges", which were alternate starting and unlock conditions for the entire scenario, and I always felt they were kind of half-baked.

I changed all this so that there are now "battles", which are just battlefield and enemy layouts. A puzzle now simply references a battle and has its inventory attached. "Encounter" changed meaning somewhat, and now refers to a location on the map which can reference either a battle or a puzzle, and lists rewards to completing its attached content. This allows puzzles to potentially reuse battle layouts with different starting conditions without having to create additional copies of the data. Challenges are now called "campaigns", and are non-optional - instead of there being one main starting inventory with optional alternates, the main starting conditions are now just the first campaign in the scenario, and alternate ones are on equal footing with their own starting conditions.

I asserted to myself near the beginning of this project that I wanted to remain open to reinventing parts of it if they needed it, no matter how deep in I was. I think this helps me keep poor decisions from taking permanent root, and lets me make large refactors like this the with confidence that I'm improving the project rather than breaking it. It can't stay malleable forever, but it can definitely stay malleable for a while longer yet.



Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #43 on: January 18, 2021, 05:12:24 PM »

My editor work is leading me to some unexpected new insights. It's forcing me to make real decisions about a lot of half-baked ideas that have been swirling around in my head. Something I'd been thinking about for a while was the idea of having multi-battle gauntlets where resources would carry over between battles, thereby making it meaningful to optimize earlier battles to set up winnable conditions for later ones. In the previous design, all resources would refill between each individual battle.

I feel like this idea has so much potential that it might end up being the primary way of playing the final game. It also helped me solve a problem that had been bugging me about how my game data is organized. I ended up once again redefining what "encounter" means. What I'd previously called a "puzzle" (a battle with fixed starting conditions) has now been rolled into the concept of an encounter, alongside gauntlets. Any encounter now has a list of one or more battles, with an optional inventory to use as the starting condition.

This allows four distinct flavors of gameplay:
  • Standalone campaign battles, where you can use all of your earned equipment and start at full strength.
  • Standalone puzzle battles, where equipment earned over the course of the campaign is unavailable, and there's just one unchanging set of starting equipment.
  • Battle gauntlets, where you bring your earned equipment to a series of fights, with non-replenishing resources.
  • Puzzle gauntlets, where you have fixed starting conditions for the first battle, and have to make them last for an entire series of fights.

In terms of the raw work to get the entire editor put together, I think I'm in the back half of it, though there's still a long way to go. I now have a fully-featured battlefield editor that I'm pretty happy with:





Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #44 on: February 08, 2021, 05:06:48 PM »

So, you know this scenario editor I've been working on for the last several months? It's pretty much done now. With only a couple of small exceptions, every piece of data in a scenario can now be fully edited inside the game UI. The editor is definitely in "rough first draft" status, but it will get polished up a lot more as I use it to build puzzles for the game.





The code for the scenario editor involves a whole lot of nearly-identical code for invoking all the UI for editing similar-but-not-quite-the-same data structures, each in their own unique way. In order to get the second half of the editor finished so much more quickly than the first half, I made an aggressive effort to reduce code duplication, so that I'd only have to type out the unique portions of each section of the editor. This was a combination of a deeper class hierarchy so that common behavior could be inherited where appropriate, and some heavy C preprecessor macro usage where appropriate. Macros come with some tradeoffs; debugging becomes a bit harder and readability suffers a bit, but the benefits in consistency and implementation speed have been worth it.

I'm bumping the progress indicator on this thread up to 50%, because I feel like this was a major milestone. Game is getting there!



Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #45 on: March 01, 2021, 05:08:25 PM »

Since the last update, I've been spending my time polishing off the rough edges in my hastily put-together scenario editor. My short-term goal is be able to comfortably use it for all of my work building puzzles without having to leave the application to write JSON in a text editor or anything like that.

On disk, scenario data in Foresight Fight used to consist of three files: A JSON file that lays out all of the game mechanics and encounters; a PNG containing a texture atlas of scenario-specific graphics; and another JSON file specifying regions within the texture atlas of each individual graphic along with its name. I didn't like having three files per scenario, and I wanted to be able to also include an arbitrary number of custom sound files, so I took the time to create a package format that bundles everything together into a single physical file. Using something like a zip or tar file would have been OK, but since I wanted something extremely lightweight and prefer to keep third-party dependencies to the absolute minimum, creating a custom format made more sense. Each package has a header listing file names, types, sizes, and offsets in the package, and then a blob of binary data at the end with all of the actual file contents in it. Easy to use, minimal overhead, does exactly what I want.

Each scenario's texture atlas used to be packed at compile time by a command-line utility I wrote, but in order to allow importing of custom graphics in the editor, I needed to be able to do it at runtime. I extracted the relevant code from the build-time texture packer utility into a static library that the game now uses to repack texture atlases when modified. There was a lot of UI work to make this process feel good, so that was where most of my time went these last three weeks. There are still a few bugs to track down, but I can now import, export, and manage images inside the editor in a pretty satisfactory manner:



I might end up implementing a rudimentary image editor for small tweaks someday, so that I wouldn't have to go through an export/edit in GIMP/import cycle for everything. For now, image import will do the job OK.

If you want to see me doing some serious work in my own scenario editor for the first time, that's the main activity of this week's devlog video:



Logged

Alain
Level 10
*****



View Profile WWW
« Reply #46 on: March 02, 2021, 09:49:01 AM »

Man, this is a really elaborate editor, I envy you for your patience! I have a tendency to dive into creating content too soon instead of building proper systems Wink
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #47 on: March 02, 2021, 10:38:48 AM »

Heh, I think I have the opposite problem - I enjoy building tools so much that it's sometimes hard to pull myself out of that loop and actually make something real with them. My hope is that making the process of building puzzles as frictionless as I can will help me get into a mindspace where I can do a whole bunch of puzzle design without feeling the need to interrupt it and tweak the technical side of things endlessly. If this also turns into a tool that other people will want to use to build levels, then that's a nice bonus!
Logged

Alain
Level 10
*****



View Profile WWW
« Reply #48 on: March 02, 2021, 10:44:39 AM »

If this also turns into a tool that other people will want to use to build levels, then that's a nice bonus!

That's what I thought, too. It seems like your tools could easily be used by enthusiastic players.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #49 on: March 22, 2021, 03:03:10 PM »

I keep to-do lists for a lot of things, and something I've noticed is that when I'm actively working on them, they have a tendency to grow a lot faster than they shrink. These last 3 weeks were one of those rare times when this game's to-do list actually got smaller. In addition to putting finishing touches on the scenario editor, I tackled three outstanding design issues with core game mechanics:

1. Previously, equippable items were split into three categories: Gear, items, and spells. Gear could only grant stat bonuses. Items were essentially spell invocations that could be used once each per battle. Spells had to be assigned to the party member who would be using them, and would grant a reusable ability that had some resource cost. Champions also had innate abilities, which were essentially spells that didn't need to be equipped.

It kept bothering me that abilities, items, and spells were almost the exact same thing. I came up with a new system that both simplifies everything and gives me some more flexibility. Spells and items no longer exist, and equipment can grant abilities usable in battle, potentially with a maximum number of uses. This covers all of the previous use cases, and additionally allows me to do things like have a potion that can be used twice before being depleted, or a weapon that can be swung with a different range while equipped, or consumable items that continue granting stat bonuses even after they're used up. More design space!

2. In addition to granting stat bonuses, a piece of equipment can require certain minumum stat values in order to be equipped. Implementing this required me to solve an interesting constraint problem, since one piece of equipment could grant the necessary stats to equip a different one, or potentially come with a penalty that would make something else no longer legal to equip. I've posted about how I solved it here: https://forums.tigsource.com/index.php?topic=4103.msg1436749#msg1436749

3. In combat situations with multiple enemies behind each other, I needed a way for farther back ones to be reachable with melee weapons after the front ones had been defeated. My previous attempt at solving this was a weird system where the tiles making up the front of the battlefield would disappear when they became unoccupied, collapsing the space and shifting everything toward the opposing team so it would be in reach. This didn't make a whole lot of sense, and restricted my design space around the idea of reviving downed champions, since the space they previously occupied might not exist anymore. I worked out a more reasonable system where empty spaces at the front of either team's battlefield are ignored for weapon range calculations. The tiles remain where they are, and everyone can reach each other when appropriate. Much better!



Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #50 on: April 16, 2021, 07:44:12 AM »

A few posts ago, I mentioned the concept of gauntlets: A sequence of battles where resources aren't restored between each one, so that optimizations on earlier battles can have cascading effects on what's available for later ones. It was just a concept then, but I've been working on the implementation, and finding that there's a bit more to it than I expected.

To recap: An encounter is a single space on the map, which might give equipment rewards and/or unlock additional encounters when solved. A battle is a single arrangement within an encounter where a formation of enemies is placed. All battles within an encounter must be solved for the encounter to give its rewards. When an encounter has more than one battle, each one must be solved in order, and each battle following the first will carry over the state of player characters and resources at the end of the previous battle. Player resources always start full for the first battle in an encounter.

I first needed to define exactly what state is carried over between battles, and what can be changed per battle setup. Metaphorically, the battles in an encounter gauntlet happen one after the other with no time in between, so I thought it would make sense to lock each player champion's equipment once it was assigned in a battle. No time in between to change armor or anything. If you lose health, there's no time to heal back up. If you get a status effect, there's no time for it to wear off. So, equipment gets locked once assigned, resource levels carry over, and status effects start on the next battle as they had been when the previous one ended.

What can be changed every battle is formation and battle actions. Being able to change formation means that if you have a lot of champions available to be placed on the battlefield, you could potentially swap out one who's almost dead for another one who still has all of their health. The one who gets swapped out still has all of their equipment on, so the fresh one will have to pull from the pool of whatever else is available. If someone wasn't placed in a prior battle, their equipment doesn't get locked, so you always have the opportunity to set them up however you like in the first battle they appear in.

Each gauntlet has its own branching timeline, since the state of each battle depends on how the previous one ended, and it might be necessary to try out different endings to find a viable route for what comes next. What I'm working on right now is a UI for switching timelines, but the necessary data is already stored to make this possible. Each battle solution gets a unique ID, as well as the ID of the previous battle in the gauntlet where applicable, so I can walk upward in the solution graph to compute the state at any given branch. This all works, and survives scenario changes in the editor if progress is saved for a scenario still being modified - since it's pretty inexpensive to simulate each battle's outcome to derive the resulting state, I only need to store the inputs of equipment, formation, and battle actions. Editor changes could invalidate previously-achieved outcomes, and I don't yet have a way to mark saved solutions as no longer valid, but it should be a pretty simple extension of the current system to do so.

Since I needed to make a bunch of changes to the data format of saved solutions, it made sense to go ahead and implement another thing on my to-do list, which was to allow for multiple player profiles. There's now a single file per player which stores all progress and solution data in one container. If you wanted to have the experience of unlocking each encounter in a scenario again without erasing your previous progress, you could make a new player profile to have a separate set of save data. Player profiles can be exported for backup and reimported. The file is written atomically on the platforms where that's possible (thanks to this article) to reduce the likelihood of losing all progress due to a power failure or something while saving.

When I went to record the video below, I found that I don't really have a good testbed for gauntlets that shows what's interesting about them. After I've finished the UI for changing battle timelines, I'm planning to build a scenario specifically for this. Gauntlets deepen the puzzle potential of my game significantly, so it'd be good to have something that can demonstrate that. Working on it!



Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #51 on: May 04, 2021, 07:50:12 AM »

I decided to take the last 3 weeks to focus on overall look and feel, doing an iterative process where I'd take the thing that bothered me most aesthetically, fix it, look for the next thing that bothered me, and repeat. Some of the changes I made:

Character sprites that were drawn from the front are now side-on, and I added a black border to make them stand out from the background a bit better:


I replaced a bunch of hastily-assigned placeholder graphics and effects for the scenario I'm building specifically for the purpose of being able to show something during development without spoiling anything in the main game campaign:


I created a new transition effect between the map screen and the encounter setup screen, which shows the relationship between the small preview of a battle and the way it looks during setup:


My goal was to build some puzzles to show off what's interesting about the gauntlet system, but it turned out that the mess of aesthetics I had left behind was bothering me too much to feel like it made sense to focus on puzzle design. Now that everything is smoother and more built out graphically, puzzles will be able to show a whole lot better. I know there are some core game mechanics that still need to change, so my near-term focus is going to be iterating on puzzle design and discovering what tweaks I still need to make for my mechanics to really shine. It took me a long time to get to this point, but I think I'm finally where I need to be for it. Should be exciting!



Logged

Alain
Level 10
*****



View Profile WWW
« Reply #52 on: May 05, 2021, 10:29:53 PM »

Thanks for the update! Nice improvements, I'm getting a Windows 3.1 vibe from the sprites. And I think the transation between map and setup screen looks great.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #53 on: May 24, 2021, 03:06:22 PM »

I ran across an interesting bit of graphics technology recently, and realized I had a use case for it in this game. Signed distance fields are a way to render smooth contours at an arbitrary size from a low-resolution texture input, and they seemed like a natural choice to me for the text on my title screen. Up until now, I had been using simple bitmaps exported from Inkscape, and I was never satisfied with the workflow or how the anti-aliasing came out. I spent a bit of time writing a tool to convert my vector shapes to SDF representation, and the supporting code in my renderer to be able to handle them, and ended up with a title image that I can customize in all sorts of ways:



Tweaking these parameters in real time makes for a fun little toy. In addition to being able to control the weight, outline size, and anti-aliasing, this would allow smooth scaling and rotation with minimal artifacting. It's not necessarily the perfect fit for a game that renders to a 640x360 fixed resolution canvas, but I felt like it was worth trying to see what it got me. I'm not 100% satisfied with the results yet, so I'll keep playing with it until I find just the right way to make a first impression on game launch. Those colors almost definitely need to change, and I'm thinking of adding some sort of backdrop behind the text. Not sure what that's going to look like yet.

Most of my other time was spent on puzzle design. I built two more encounters in my showcase scenario to get a feel for the puzzle potential with my existing elements. I'm learning that the mechanics I've chosen don't lend themselves to the type of puzzle I'm more accustomed to building, which would normally involve choosing a central mechanism or a realization I want the player to have, and constructing the puzzle around that. What I've ended up doing so far with this toolkit is putting together what looks like it might be an interesting situation, and then testing it out to see whether it's possible and how interesting it is, without really being able to judge those things in advance. This is...fine? As I work with it more and learn the dynamics, maybe I'll find ways to build puzzles using the kind of reasoning I'd normally tend to apply.



Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #54 on: June 15, 2021, 11:47:06 AM »

I decided to take some time away from the main codebase of Foresight Fight to focus instead on a tool I needed to build for it. The sound effects that had gone into the game so far were all made with bfxr, which did a pretty good job at the time, but for various reasons I wasn't comfortable using it as part of my workflow anymore. This resulted in no new sound effects being made for the game in a very long time, and I needed to do something about this to be able to continue expanding my sound library.

The first thing I felt was necessary was to ensure that I could preserve my existing work. Conveniently, bfxr is open source, although it's not written in the same language as my tools and the game. I ended up writing a parser for the existing bfxr files I had saved for all of Foresight Fight's sound effects, and porting bfxr's audio synthesis code from ActionScript to C, which was about as straightforward as I could have hoped - it was mostly a matter of find and replace for syntactic differences, and a little bit of bootstrapping to get the parameter data parsed out of my files into it.

So, I now have full control over resynthesizing my existing sound effects, with the ability to edit their parameters as necessary if tweaks need to be made. This would give me the option of performing synthesis at runtime instead of loading ogg files if I desired. Because this tool is part of my build system and integrated into the framework I use for all of the code I write, its lifespan will match or exceed whatever Foresight Fight's ends up being, eliminating the possibility of losing access to my work due to a third-party dependency breaking from something outside my control.

bfxr does a lot of stuff, but I ran up against some limitations when I was making the sounds I have now, and my next step is to expand the new tool's synthesis capabilties to eliminate those limitations and make it do everything I need. The plan is to make this tool my all-in-one audio workshop, and eventually use it for music sequencing since I hadn't yet chosen a tool for writing music for the game. By starting with a custom tool instead of something third-party, I can skip past the problem I had with bfxr that necessitated reverse engineering the format of my existing saved work and porting over code to be able to preserve it.



Logged

TwoSaint
Level 0
**


View Profile
« Reply #55 on: June 17, 2021, 02:31:51 PM »

I enjoy watching the growth of this game Smiley. It is looking more and more intriguing.
When developing the menus do you keep in mind visual simplicity or do you think it can harm gameplay when you try to simplify the interface? Is there a middle ground?

Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #56 on: June 17, 2021, 08:08:01 PM »

Glad to hear it!

I'd say that visual simplicity is something I probably don't think much about until later stages of UI polish. A lot of the menus you see in the game now are still in rough draft form, where I felt like it was most important to expose the underlying data structures in whatever way was easiest for me at the time. Once I'm able to play with the data interactively, I can start to get a feel for what parts of it I end up manipulating most/first, and can use that to design a more refined version that makes the most expected interactions front and center while tucking less frequently used things out of the way, but still accessible with a few more clicks.

I don't have anything resembling a formal process for this - it's mostly just iterations of "OK, it works", followed by "hmm, this would feel better another way" after using it for a while until it stops bothering me. Once I get to playtesting with other people, I'm sure a whole lot more of these rough edges will become visible than what I see using it on my own. One thing I notice that recording devlog videos helps me do is to see the game from a fresher perspective; in recording mode, my observations seem to work differently, and I'm always able to spot a lot of unpolished areas that I need to tweak.
Logged

ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #57 on: July 12, 2021, 11:12:27 AM »

Continuing my deep dive into audio synthesis, I spent some time thinking about what I wanted to do for music sequencing. One of the first steps was to get my sfxr synth implementation to produce tones at musical frequencies. With the knowledge that A4 on a piano is 440 220hz, going up an octave doubles the frequency and going down halves it, and that there are 12 keys per octave spaced apart evenly, I put together some simple math functions to map from a piano key and octave to a base frequency input value - which sfxr maps to a nonlinear 0-1 range rather than hertz, so there were two separate transformations to get the correct value. Once this was done, I was able to get it to play a perfectly serviceable C major scale:

http://ludobloom.com/audio/audiolab_cmajorscale_sfxr.wav

Turning this into something I could use to construct actual music took a bit more effort. After some thought, I came up with three data structures at different levels of abstraction: A list of samples to play at a specified time with a list of synth parameters which can composite its data to PCM audio output; a pattern of note inputs quantized to beats in a time signature which can composite its data to the aforementioned sample timing/parameter list; and a meta-pattern with a BPM value assigned, which can sequence together multiple patterns of note inputs to construct an entire song.



My next step is to figure out synthesis for different types of instruments, since I'm just working with a simple sfxr square wave tone right now. While I could attempt to continue contorting sfxr or bfxr into producing the sounds I need, I'm now in the midst of writing my own low-level synthesizer using what I've learned from porting the other two and extending it to better fit my needs. I'm having a lot of fun right now reverse engineering recordings of real instruments and working out the math to synthesize approximations of them from pure waveforms. I'll probably have more to say about this in a few weeks when I've developed it further.





Edit: Had some math wrong. A4 is actually 220hz instead of 440, but I had an off-by-one error in my code that made it sound like what I expected for what I thought was a value of 440. Whoops!
« Last Edit: July 14, 2021, 10:33:00 AM by ThemsAllTook » Logged

bayersglassey
Level 0
***



View Profile
« Reply #58 on: July 15, 2021, 07:25:09 PM »

Mmm, writing music by hand as code. That's how it starts... Smiley
Pixel (of Cave Story fame) started by writing his own music program, I believe it's the entry for 2008 in his archives: https://studiopixel.jp/archives/index.html
Here's somebody trying to use it:



Foresight Fight is a pretty epic project, you've got dedication for sure.
How many years until you get around to adding multiplayer? :D
Logged
ThemsAllTook
Administrator
Level 10
******



View Profile WWW
« Reply #59 on: July 16, 2021, 12:57:29 PM »

Ooh, nice! That does look pretty similar to what I'm trying to make. Got a few ideas from seeing how his version works. It's always fascinating to just watch someone make something with a tool like this. I still haven't gotten used to that sudden transformation from "this is a collection of noises that don't really sound like much" to "this is an actual piece of music". It just sort of happens like magic when the right ingredients come together.
Logged

Pages: 1 2 [3] 4
Print
Jump to:  

Theme orange-lt created by panic