Another jam in the bag!

Unlike with Sour Situation I definitely had way more I wanted to finish than time. It should have been obvious from the start that an application is going to be way more complex than a simple game but I was surprised none-the-less.

The two major issues I ran into, and thus took the longest to work out, was text editing and camera movement.

I also had difficulties with packaging this tool for distribution as I did for Sour Situation… but they were different.

I do plan on using this software myself and am planning on some updates in the near future.

For more detail, read on (or skip ahead to the part that interests you).

Text Editing

I’ve tackled this before in an unreleased windows console application I made and it wasn’t any easier than doing so in LÖVE. The major differences had to do with programming for a fixed cell, terminal layout versus a more free flow text design.

I stuck with a fixed width font for simplicity but tried to account for a variable width font. That means I never (well mostly) made assumptions on the width of the text when placing the cursor.

In a terminal it was easy. Each cell is a fixed width so if the cursor was at cell 10, I could place it at cell 10.

Granted, I could have done something similar, storing each character in an array, but I didn’t think about that at the time. I may try that in a future update.

Overall, I just don’t think Lua or LÖVE is very good at editing text. I’m really asking too much of either application.

Making it Work

I pretty much ignored the constant calls to utf8.len, font:getWidth(), and the numerous string allocations necessary to make this thing work. In my limited experience, it wasn’t really an issue and more importantly it worked.

The main idea was I’d use the cursor as a splitting point for a line. Everything before the cursor was stored in one string and everything after the cursor was stored in another.

Adding text was as simple as appending the new text data to the end of the pre-cursor string.

Updating the cursor meant finding the width of the pre-cursor string and placing a 2 pixel by cell height line at the end of the pre-cursor string. The cell height was determined by the height of the font.

Word Wrapping

I pretty much tossed this idea out.

I tried to make it work but the tools available were not great and I felt to build my own would take up too much time. LÖVE’s strong point here is taking pre-written text and displaying it in a dialog box.

It also would have complicated the note boxes as I would have had to program in resizing the boxes. I’ve done this before but I know it would have taken way too much time to reimplement for this project.

As it stands, the way text wraps is by putting in “hard” line-breaks by hitting the “Enter” key. This solved the resizing issue too.

Note boxes now conform to the width and height of the text contained.

On the plus side, this makes it easier to get fancy with your formatting as you don’t have to fight with word-wrapping.

Overall

I think the text-editing feature I have is good, not great. There’s certainly room for improvement but I don’t hate the behavior either.

It won’t be the first thing I tackle as I improve the app, but it’ll be on my mind. I suspect performance will become an issue as notes get larger in size, but we’ll see.

Camera

I’ve avoided using camera’s in my games. Not necessarily because their hard, but having a static screen is so much easier. The last attempt I made was years ago for a home grown game engine that was a flaming disaster.

Honestly, if I took the time to understand the math a bit better it would have likely gone smoother. Instead I just took the trial-and-error method and came out with a pretty good system.

Everything works smoothly and as intended.

A could of things that stood out to me.

While zooming in and out, it’s necessary to recalculate the camera offset, by finding the new mouse world position and comparing it to the old. This keeps the camera’s zoom centered on the mouse.

I won’t into any detail, but let me know in the comments below if you have any questions.

The second little thing involved panning while zoomed out. At first, the entire board moved very slowly. As fast as when it was zoomed in.

All that I had to do was multiply the change in camera movement by the inverse scale. It was a super easy fix, it just caught me by surprise.

Overall

The camera system (at least when working in two dimensions) is really quite easy to figure out, there’s just a lot of little surprises along the way.

Things that I take for granted required a little extra work to make work. It was eye opening to say the least.

Of course, I know that a 3D camera is an entirely different beast. Which is why I haven’t cared to do much in 3D. I’m sure one of these days I’ll attempt to make that leap again.

LÖVE Distribution

Again, I had trouble packaging this tool up. I tried the same method I used for Sour Situation by only packaging up main.lua but for some reason, that didn’t work this time.

To note, I used LÖVE 11.3 for both releases.

This time, it couldn’t find any assets such as my font and a dummy animation I added to the project. Putting them into the .love archive worked fine.

:shrug:

As far as my source files not loading properly, I’m pretty sure it has something to do with how I load them. I’m using a custom file loader which likely isn’t looking in the .love archive.

This is something I’ll have to focus more on in future releases that I just haven’t had time to do to get these projects finished before a Jam deadline.

I’ll probably have to overhaul the entire system, which is something I’ve been wanting to do for awhile but not something I’m going to do right away.

In the mean time I’ll see what I can do to make the whole process a bit more consistent.

Such as writing a batch script to generate a distribution package each time I cold boot the game.

I mean, I already have the framework in place as I use batch scripts to generate fresh sprite sheets from raw Aseprite files.

A Few Other Things

Lastly, I felt like most of the work was just thinking up a feature and finding a place to stick it.

The code is a complete disaster. A Frankenstein’s monster.

But I rather like it this way. There’s something elegant with getting that beast to work that I simply enjoy.

Of course, for future updates I’ll want to go and clean up a lot of that code because as it stands it’s a nightmare to work in.

I had to make a couple last minute changes that got real ugly, real fast and I can only hope they still work.

But that’s really the charm of working on such a deadline. I trade time and ease of adding features for lots of spaghetti.

Delicious, delicious spaghetti.

Updates

The entire reason for starting this project was because I’ve been looking for a decent note taking application and what I’ve found hasn’t thrilled me.

My goal is to make something that is easy to add ideas and to organize them.

As it stands, I think I succeeded in the first half but need to work on the second. There’s no way to move a group of notes which is the crux of the entire program.

I also want to add a way to show relationships between two groups. Initially I’ll be using simple lines (much like where I got the inspiration from: crazy walls, evidence boards, link charts, or a hundred other names for the things detectives use in police shows/movies).

Having a way to track TODOs would be useful. I certainly could fake a TODO item using the current system (and probably will until I implement it), but the program won’t know about them.

I’ll be playing around with the software myself and slowly adding new features, cleaning up the code, and fixing the numerous bugs I’m likely to find.

My plan is to get the bare minimum features implemented before I proceed too far into the project. I’ll work on a roadmap soon, drafted up in this very piece of software.

If you have any questions, comments, criticism, feature requests, etc., feel free to leave them in the comments below.