We have Web! I just managed to test the Qt-game’s WASM-build. It was quick and easy, I just had to downgrade my installed WASM from 4 to 3, and install it from Git instead of Homebrew. I also got a new ground-texture from OpenGameArt, and it looks 10x better already.
I have underestimated the performance implications of evaluating everything as lazy as possible in QtQuick/QML. The col/row-numbers get their color from calculating if there are too many walls in them or not. This routine got executed on each mouse-drag, maybe even on every hover. I added two arrays that hold the count-states, and changed the update-invocations to only happen on adding/removing of a wall.
It may sound like premature optimization, but all levels bigger than 6x6 were really tedious to play on iOS, simulator and iPhone.
The game is running nicely on iOS! That means I can take it with me and make new levels on the go. I had to mess around a bit to combine MultiPointTouchArea and the normal mouse-handling, but it works surprisingly well!
In QtQuick, it seems to be better to use a readonly TextEdit for showing rich text, than just adding HTML or Markdown to a normal Text-Object. Since I’m inside a flickable drawer, I’ll have to somehow disable selection, which seems to be enabled by default.
Quorridors update: A “next level” button and a winning-state for the screen.
The level editor is now usable for me to create more levels. Not really for shipping or for players, but let’s see. There are indicators if the level is valid, and even which of the conditions for completion are fulfilled. I can copy the generated level-string into the levels-object. I could add a paste-new-level-from-clipboard feature, where you copy the level from somewhere else and paste it in the editor. Will I add sound next?
A small update: We have a level editor! I can switch it on/off on every level and it will just edit it in place for now. The goal is to save the edited level in its own category. I got the methods from the JS-version, like adding/removing Drones and recounting the lines. So happy that I made the game-logic pretty functional and pure. Everything that is doing something will receive a board, with data, and return a new board.
Using the QtQuick Drawer to show and hide the games menu. It’s a pretty useful component! I’m still struggling a bit with my habits from years of web. I started as a front-end-dev full-time in 2012. Having a responsive layout was the #1 golden rule, so I get nervous when an interface isn’t liquid and only works for one size. There are more important features at this stage, but fixed layouts are an itch, I can’t help it.
Moved from 2 windows to a single window, it was an experiment, but ultimately it should be easier to handle, especially once I try to export this to mobile or web.
I might add mousewheel-zoom-in/out that resizes the tiles, just for fun.
Lots of issues are only visible after some time away. Yesterday the ship looked harmonic and readable to me. This morning I saw that it’s much too dark. Here’s the improved version.
Some more sprites for the Qt/QtQuick Dungeons & Diagrams clone. Also lots of input handling, hover-designing, and painting. I don’t have a name yet for it.
Painted all necessary tiles (minus one I forgot, the top-to-bottom-connected rock-tile). Still getting used to painting again. But it feels just like 20 years ago. Wacom and PS haven’t changed that much.
The details on the rocks seem to small for the smallish size of the tiles.
In my first Version of Corridors (the Three.js one), and in the original Game of Dungeons&Diagrams, the add/remove of a wall happens on mouse pressed (as opposed to clicked or released). The player can then move the mouse around and “paint” the wall without having to click each tile. When the first click removes a wall, the player can only remove walls while the mouse is pressed, and vice versa. This is vital for levels larger than 3x3 or 4x4.
Didn’t like the pixel-art I attempted for the tile-graphics, so I got out the ol' Wacom and got some months of Photoshop. It’s still my favorite image-editing-tool. Affinity is great, but after decades of usage I feel right at home. Started trying different styles.
Qt has the palette-object, which stores colors for windows, and automatically switches when the OS’s dark mode is activated. Very nice and useful if you want to stick to OS defaults as close as possible.
Some time ago I made a fully working clone of Dungeons & Diagrams in vanilla JS and Three.js. I used JSDoc-comments for some kind of help/hint during development. I never really finished it, but it was a good learning-experience for Three.js and Vue, which I used for the UI. This game is a great practice for my current QtQuick adventures! I already have all the game-mechanics done. And since QML can talk to JS, and I designed the functions to be pure and stateless, it was a breeze to get a first version running.
I further refined the UI and added some responsiveness, so it’s usable now on a phone. I’m missing some UI debugging/inspection features that are normal in other layout-solutions. Finding out where a gap or width is coming from is a bit clunky.
Progress of my LCARS Todo-App. Played around with animations, but that’s something for later. First I’d like to have a “clean” look, with a color-scheme I’m happy with. Went with Lower-Decks-LCARS-Colors for this one. Also got the iOS-Simulator-Build to run today. At first I got cryptic errors, but I just had to install the whole iOS-dev-package with XCode. I think I’ll keep this one just for Desktop. I could add some interface-sounds from Star Trek.
In QtQuick whenever you change data within a QAbstractListModel, you have to notify Qt in some way. It’s not as straightforwardly reactive as in modern web-frameworks. When adding, moving or removing items from the list, the operation needs to be enclosed by beginInsertRows/beginRemoveRows/etc and endInsertRows/endRemoveRows/etc.
Changing data inside the list-items needs to be followed by an emit of dataChanged, which takes the item-position in the list as argument.
Qt is fun! I spent some later nights now getting my ToDo-List to work. I’m also not very versed in C++ so it’s two new things. Thankfully, Qt has fantastic documentation!
It had to be LCARS colors of course.
You can connect a C++ Class to a QML-View by making it a Q_OBJECT (a macro that gets called in the header-file), and in order to work with a list, it needs to be an AbstractListModel, with some required methods that help the ListView getting the right data for rendering, and knowing when the data has changed.
It’s a great way to learn to first do a course-project (Youtube, Article etc.), and then do a small similar thing by yourself. Use the course-code as reference when you’re stuck. Helps to persist the material so much better.
