A challenge for me with any project is to determine its MVP, making it ready for release. But what even is a MVP?

No, in this case it doesn't stand for Most Valuable Player. When it comes to project building, it means Minimum Viable Product. That is, what's the minimum functionality that needs to be included in order to make a first release. The central idea is that it's good to receive feedback, so getting something out there as soon as possible lets the community (or potential customers) tell you what they want next.

For example, if I wanted to release a new Minecraft server plugin, I might not need to include everything and the kitchen sink early on. A basic version, that includes all the core functionality, can be distributed online. Later on, extra features such as configuration files, optional modes and so on can be added. Maybe I would also get feedback on things I didn't even think of, helping to guide the development process!

It's tempting to want to release the perfect website, plugin or tool right away, but it can take a considerable amount of time to get there. By the time that everything is 100% ready, maybe people will have lost interest, or a competitor showed up, or you've built something that people just don't care about. This has happened to me several times already, and that's where starting with a more minimalist option can be interesting.

This doesn't mean that this MVP can be full of bugs! Some incomplete features might be okay, or the occasional glitch happening, especially for something labelled as a beta release. Still, having something unstable can be a turn off and lead people to believe your new toy is best avoided, so finding a proper balance is key.

#projects

– Doctacosa

When I was about 15, I got the idea that I wanted to make my own JRPG, inspired by the Dragon Quest and Final Fantasy series. While that didn't really happen (yet?), I did some research on various needed bits and started planning based on that.

One key element of a JRPG is its player progression system. You know the classic: defeat enemies, gain experience, level up and all that! Part of that early planning was figuring out how to make a progression curve that wasn't linear: if you defeat tougher enemies, you want to gain more experience points, and higher levels should require more experience to progress. Based on this, I came up with the formulas pictured above, which return the HP and MP of a player at any given level (“NV”), plus the amount of experience at which this level starts.

How is this relevant to today? While that game hasn't materialized, the math was sound, and I've kept it aside for later. The same formulas, sometimes with tuned values, have been reused since then in various places. The latest example is none other than the player level stat that was recently added to the Creeper's Lab profiles! Each stat has a set amount of XP assigned to it, everything is added up for a player, then the level formula assigns a level to that player! At the time of writing, I have 570,512 XP, which translates to level 415.

The same pattern has come up multiple times in my life: I get an idea, I'm not sure what to do with it, I shelve it for possibly later, then it gets reused or integrated within something else down the line! If you take something away from this, I suggest not to trash things that seem pointless: they can still have value!

#creepers_lab #projects

– Doctacosa

I've mentioned before that some of my code, most notably several of my custom Minecraft plugins, are now available on GitHub. When I work, I usually save my work in various bites, each containing a feature or specific change. These are called commits and let you track your changes in a project, and possibly review / cancel them if problems arise. These can be as simple as changing the color of an item to adding a whole new feature. Having individual changes logged can be very valuable.

Each GitHub profile includes an activity chart showing the numbers of commits done each day for the past year. The darker the color, the more commits were done in that day. Here's what mine looks like as of this posting:

Nice! But it's also woefully incomplete, because it only includes my code that's available on GitHub! Several other projects, such as the websites, the CL Companion, private plugins and more won't show on this chart.

As such, I set out to create my own visualisation tool, able to read all commits across all projects instead of only the ones publicly available. Here's what I came up with:

That's a lot more colored dots, isn't it? This makes it a much more accurate indicator of how many times I push a feature or change each day. After some polishing, I'm planning to add this somewhere on the main Interordi site, likely in my portfolio.

“But Doc, I don't care about your commits chart!” Maybe not, and that's fine. :–) Showing my full range of commits was one goal, creating that chart type was another. Once completed, I plan to integrate such activity charts in multiple places. There's a limited version of it already available in your Creeper's Lab player profile; for now, it only includes the past year worth of playtime data. The idea is to give it more power by allowing you to browse back in time, up to the day you joined! The extra flexibility will make it even more valuable as a display tool.

#charts #profiles #projects

– Doctacosa

As you might have seen in the Creeper's Lab news this weekend, I released three more plugins to the public: kicks and bans management, Race Away and Grindatron. I first distributed five plugins last summer, which I wrote about in this space. I explained how an extra layer of polish was necessary before others could really use these tools properly, but you might be wondering what type of work that involves. Let's take a look!

A first important step is to ensure that the plugins can run on their own. It might seem simple, but some of these need me to do manual corrections once in a while, or handle some tasks by working directly on the database's records to complete them. This isn't something I want others to have to handle, so I usually need to complete and automate some processes. The bonus of doing this is that I no longer need to do these steps by mistake afterwards, so that's a win-win scenario!

On a similar topic of automation, the initial setup is important: something that I added when necessary is for each plugin to automatically create its database tables and/or configuration files when it first runs, so that everything is ready to go. I didn't include this step on the first versions I used on the Creeper's Lab because I didn't know what would be needed, plus needs grew over time!

Something important that many developers don't like to do is documentation. “Why should I be writing text when I could be writing code?”, many seem to think. In this case, it's important as any other server owners wanting to use these plugins need to know how to set them up and use them! A full documentation involves what each plugin does, how to install it, setting permissions, any in-game commands available, and possibly more. This gives people the feeling they can trust the thing to do what it's meant to, and hopefully reduces the amount of questions I have to deal with.

Another element is the branding: how to name them, and what logo to give them. I usually prefer a descriptive name so you can get a vague idea of each plugin's purpose from the start, with the IO prefix for Interordi. For example, the plugin used to synchronize player inventories across multiple servers is named IOSync. A logo isn't strictly required, of course, but it adds a way to quickly identify something and make it stand out. I developed a basic visual identity for all my server tools, so you can tell they're from the same family!

These are the main steps! Most of that work only needs to be done once, and I usually do it close to release. This way, I know exactly what's necessary and don't need multiple do-overs.

#gamedev #projects

– Doctacosa

So many ideas, so little time.

It can be easy to come up with a project idea, it's something else to bring it to completion. I have several things always bothering me at the back of my mind, and it's easy to always kick that can forward thinking that I'll look into it some other day.

Something I've taken to doing is to try and build a demo on each interesting concept. Without too much effort, this can reveal quite a bit! One idea that I initially had a good feeling about ended up being cast away after only two days as I quickly realized it would be too unreliable a service. Another would have been interesting, but the data I needed wasn't really available. A third definitely seemed possible, but I caught on to the fact that I would be miserable working on it, and life is too short for that.

Some of these demos I completed, then set aside as I had no direct plans for them. Others were saved for later, as potential components of something larger. A few have landed on my public GitHub account, waiting to be discovered and built upon by someone else.

And a precious few seemed to hit both the “possible” and “fun” factors. These can be saved to be revisited later: either it can stand on its own, or become a part of something larger. It's also entirely possible that what sounded like a good idea at first isn't so attractive later on – that's okay too!

My main point? If you think something sounds interesting, consider trying it. You don't have to get overly attached to it, or invest a lot of energy into it. Messing around with a project, an activity or even a game can give you a better picture than just thinking about it again and again. An hour, a day, a week maybe? And if it doesn't keep your attention after all, that's okay – now you know, instead of having it constantly bugging you.

#thoughts #projects

– Doctacosa

Back in January, I wrote about the steps I went through in submitting apps to various app stores. To summarize, Google Play happened just fine, the Microsoft Store version was rejected, and iOS wasn't possible as they don't support this type of applications.

Things changed in the meantime, and I'm happy to report that BiteReads is now available on the Microsoft Store, giving it some extra exposure! You might be wondering what happened in the past eight months to allow this.

With the upcoming release of Windows 11, Microsoft announced a set of changes to the rules of their applications store. One that caught my eye quickly was the fact that they now allow third party payment platforms, as long as that's clearly mentioned. This was the very problem locking me out initially: as BiteReads requires a connection to the Pocket service, people were getting redirected to their platform on login, also giving them a detour to their paid features. Under the new policy, this was allowed, so I went back to work. I modified the product description to cover this directly, updated the in-app description accordingly, submitted the new version, and it was approved after about a day! This means that two of the largest platforms are now within my reach for this and any future project I release.

You can now download it from the Microsoft Store, along with the already available Android version on Google Play.

#bitereads #projects

– Doctacosa

I've written before about my work on plugins, either to fix existing ones or create new modules entirely. Some of the new work happened to replace older options that stopped working or weren't reliable enough, while others have been designed to add some brand new functionality. While I had made a few available online already, I decided to go the full distance and release as much content as widely as possible!

There's now a main section on Interordi to link to the full set of plugins I've made available so far. This includes information and downloads on Spigot and Polymart, plus the full source code on GitHub. Five plugins are available now, with more being gradually prepared.

This might not mean much to most of you reading this, as you're players of the Creeper's Lab and don't need these files. Instead, these are for server owners, a group of people that I haven't been actively targeting until now. Since I'm already making the effort in developing these features, I thought I might as well use the opportunity to reach out to more people. This includes a new crowdfunding campaign, this time on GitHub Sponsors, which targets developers and server owners interested in supporting my work.

Now, this doesn't mean that this was a simple fire-and-forget thing. As I was telling someone else a few days ago, I tend to classify my code in three categories:

1. The tools I create for myself only. These can be very unpolished, as I can easily work my way around their limitations or problems.
2. Things that are shared among the staff members. While they can come with warnings about rough edges, something that's more intuitive is my goal.
3. What gets published for everyone to see and use. This needs to be fully secured, as fool-proof as possible and with a solid production quality.

Moving anything forward from one level to another can be a significant effort, and often takes way longer than one would think. Most of the plugins that this post is about were in the second tier, although some were in the first; making sure that everything was easy to install and understand required some careful review work.

More in this direction will happen in the upcoming months. Do you have any thoughts on which of the tools I've mentioned over time that would be the most useful to other people? If so, please, I'd love to read about it!

#minecraft #plugins #projects

– Doctacosa

Bold. Italics. And many more.

We know what to call these visual effects, but how do you type them?

Some platforms, such as here on Patreon, display a toolbar where you can click icons (or use keyboard shortcuts) when writing posts. It's not as obvious if you want to write something in its raw form to include somewhere else. In that situation, you need a way to define a set format. After considering many options, I settled on Markdown and I've been working to integrate it everywhere whenever possible.

Markdown is a format that you might already be familiar with from platforms such as Reddit, Discord or GitHub. It's meant to be simple to type and remain readable even in raw text. For example, to write something in bold, you surround it with two **asterisks** on each side. Even if the text conversion isn't available, you can easily tell that the focus on that element is important.

Over time, I successfully integrated this as the default syntax on the Interordi Forums, the news system, the Creeperpedia, and even for my personal note taking. Having a single, standardized form means that text can be copied from one location and then pasted in another without losing any information of formatting, making work all that more efficient.

I ended up developing two tools related to this. The first is Markdown Syntax, which is both a guide to the full syntax and a near real-time preview, so people can try it without risking any live data: reload the page, and any changes are reset! The second is the creatively named Markdown Viewer, which allows multiple pages of raw Markdown to be browsed as if they were full web pages, similar to how a wiki would present its information. I use that one to take project notes in Markdown, then share them easily with others without requiring any manual conversions.

Some alternatives that I considered but tossed aside include the following:

• HTML (bold sample). It's ubiquitous, but it's also blocked in many places due to the potential visual and security risks. It's possible to try to strip out unwanted elements, such as images and rogue Javascript code, but why risk it when better alternatives exist?
• BBCode ([b]bold sample[/b]). IOBoard, the software in use for the Interordi Forums, supports a form of BBCode. It's a facsimile of HTML, using square brackets. While functional, it also needs more characters to write out any element, causing the raw text to become harder to read.
• MediaWiki ('''bold sample'''). This is the syntax used by Wikipedia and its sister sites. While used by millions for the encyclopedia project, it's also one not available on many other platforms. This would mean adopting a different syntax elsewhere, forcing users to learn different variations, and I wanted to avoid that at all costs.

The end result is that as many tools as possible across Interordi share one common syntax. One syntax to rule them all!

---

This post might be a bit more focused on a single issue than most, but it's something that I've put a lot of thought into for the past two years or so, so hopefully you still found it interesting!

#projects #markdown

– Doctacosa

Recently, I reorganized the entire support system of the game servers as I described in this news post. The servers are now able to turn themselves off when empty, then wake back up whenever a player tries to access them. The main result is the empty ones no longer use any RAM or CPU, letting the other worlds have more resources to themselves.

The results were clear: we have had some instability for the past several weeks, including crashes every few days, and that cleared up pretty much instantly. I'm satisfied to see that it was all worth the effort!

This is something that I had been thinking about for a while and then spent most of the past month developing. The dedicated server was getting full, especially on RAM usage, causing instability. Plus, this meant that I couldn't run any more servers in parallel: bringing Seasonal and Tasmantis online for some weeks already increased the rate of issues, which is no fun for the player base, so something had to be done.

Sure, I could have opted to rent a dedicated server with higher specs, or outright get a second one, but I like to maximize what I have before getting more. Plus, this keeps the entire operation running at a lower budget, freeing money for other ventures.

Another feature that I introduced helps me keep the game servers up to date: whenever the servers wake up, they also pull the latest versions of the game itself, selected plugins and their configuration. If, say, Rodinia wakes up 10 times in a given day? That's 10 opportunities to update its files and get the latest improvements and corrections! Before, that was only possible when I did manual restarts, which could be as rare as once every few weeks.

This replaces the Python script that I mentioned back in 2017.

To summarize, this work had three main results: * An immediate, positive effect on game stability. * Easier server updates by fetching files on every wake up. * New opportunities for special projects by freeing resources.

I'm proud of the result. This required several weeks of development but will definitely pay off in the future!

#gamedev #projects #minecraft

– Doctacosa

Following up on my previous post, here are some more of the plugins I've developed over time.

IOServerMonitor

The newest on the batch! As you might guess from the name, this plugin is used to monitor the status of the game servers. Nothing of this is visible to the players; it runs quietly as it lets me keep an eye on valuable data like the last time a server was restarted, how many players are on or how fast it's currently running. Bonus, this one is available for download on Spigot!

IOTrails

IOTrails replaced the older SmokeTrails, which I had been maintaining for a while. This full rewrite allowed me to add new options, most notably in letting players choose a trail once and have it apply on all servers simultaneously. Before, the setting was applied per-server, causing people to often have the wrong one applied. Also available for download!

IOBattleStats

I already did a full write-up on this one nearly two years ago, but I feel like it's worth another mention as tracking all gameplay stats was a very big bite to take. Thankfully, this has been very reliable overall in the meantime, with little maintenance needed. I'm planning a release once I work out a few known issues.

UHC and Grindatron

Both rotating challenges within Kenorland, I developed custom solutions from the beginning to have all the flexibility I needed. These aren't set for public release, as the UHC one is probably underdeveloped compared to some existing options, while the Grindatron is a special feature that I'd like to keep as a Creeper's Lab exclusive.

While I don't have more to mention right now, I'm often considering the time cost of maintaining existing plugins vs finding new ones vs developing my own, so there might very well be a part 3 in due time!

#projects #plugins #minecraft

– Doctacosa