Good grief. Its already the end of the year. The last day in fact. Since this is the last couple of hours given to me of this year 2021, I figured that I might as well put something out. Something to inform you as to what I have been up to, and what you can expect from me in the future. Hopefully my more personal ramblings will still provide some entertainment value if nothing else. Obviously I will limit the subjects to those relevant to this website’s remit.
Time limitations and prioritisation
Ok. Where to begin. Well, it has been sometime since I last released an article. Nearly two months in fact. And what’s more, the last article I released wasn’t even all that interesting if I am honest. It just involved repairing a knife for a friend, and a rather shallow inspection of it’s mechanism.
So what have I been doing in the meantime, eh? Well it’s multifaceted. I have been doing a lot of things. Mostly working a new job and collecting money – so that I can hopefully have enough to move on to the next chapter of my life within 2022. (I will talk more about that at a later date.) Add to that all of life’s other important obligations. The kind that tire a person out. Mentally and physically.
That being said: I still made some time for tinkering with crap and writing about it. Unfortunately none of my various completed drafts have passed my personal threshold of quality *pause for laughter* in time to meet the self-imposed obligation of publishing at least one good article a month.
Projects currently worked on:
Device repairs and analysises
I have been working on several things including: a repair and device analysis article on an incandescent handheld torch, as well as a device analysis on an old nightlight and bicycle lights. Add to that an update on the tap cartridge article – where I replace the old cartridge as the temporary repair discussed in the first article has now since failed, and I don’t feel like redoing it again to buy a little more time. Within this article, I go through the process of measuring a cartridge using a caliper and noting all the most relevant dimensions for identifying and then purchasing the correct model replacement part.
Moving on, I also have some product reviews in the works; as well as various other repairs, refurbishments, and modifications. And since arguably the best times to shop for a good bargain is in November / early December: I have been purchasing a lot of tools and equipment in “spares and repairs” conditions. Ones’ whose repairs I have been / will continue to document.
I find myself now sitting on a veritable dragon’s hoard of broken electronic crap. Including everything from power-tools such as angle grinders and cordless drills, to useful devices such as uninterruptible power supplies, projectors, radios of several different stripes, as well as a sewing machine and a typewriter. All at rock bottom prices. And providing that I can repair them economically, all of these items will become a major boon once fixed: as they will assist me in future endeavours.
Theoretical subjects
Add to that the fact that I have several different drafts of a more philosophical nature or that deal with a theoretical subject in the works. Articles for example that discuss the economical aspects to repair and why it is difficult to maintain a profitable business repairing consumer electronics. As well as article that discuss subjects such as: methodical troubleshooting, true/perceived obsolescence, the nature of consumerism, and the dis/advantages of multi-tools such as smartphones.
Funny thing. Initially I started writing the more philosophical articles as a way to either whine about something that irks me, or as a way to create what I perceived as easy content. All I have to do is make a coffee and sit down and write. Right? Well no, this is because as I started writing on any subject of this nature – where ideas are explored: I become acutely aware of the gaps in my knowledge base. However often with no easy or sign-posted path to fill those gaps. Just an uneasy feeling of helplessness as one grasps at nothing in the darkness.
This is why these article are the ones least likely to get published. As I don’t want to advertise my ignorance, and doing some of these subjects justice requires writing a formal essay. With structured research and citations. And once you reach that point, it is no longer easy content now is it. Easier to just fish a used smart-dildo out of the dumpster, wash the shit off, then crack it open and throw a schematic up on here. I could probably complete that project within a single productive afternoon. And be less likely to embarrass myself in the process.
Project updates: Remote PI
I also have not forgotten the fact that I want to get back into making video games. Its just that operating as a solo developer is a heavy burden. It really is. And adding it to everything thing else that is going on – well I just haven’t had the time to put work into it as I should.
However, having said that. I am still chipping away at it. Right now I am playing around with creating pixel art. This skill will be relevant to the game. You might have spotted some of my work on this site. The Warhammer 40k Ork on the main page, or the Pokemon Magnemite on the “post index” page.
I even have heaps more that are unpublished. Including a bunch of pixel art icons and sprites that I intend to use in the role-playing tabletop game Shadowrun. I will use them to make decking (i.e. hacking) more compelling and attractive. By using the pixel art icons as visual indicators of networks, devices, as well as virtual entities such as AI sprites, ICs, and other deckers. Basically to add a visual flair to the game and give it some flavour.
So, even if I am not directly working on the game by creating assets for it. I am still developing a skillset relevant and conducive to the production of Remote PI. Its the main reason why I am creating pixel art. These other products are a side effect of that.
Software projects
I have several other software based projects that are currently ongoing, other than Remote PI. These include, creating a HTML wrapper, or converting my old Flash games so that they can be played here online. Alternatively, I may just make them downloadable. Either by bundling a portable Flash player with the .SWF files or by finding their original project files and recompiling them into an executable binary using the Adobe Air library.
I am also working on smaller HTML programs that I want to incorporate into this website itself. Such as an analogue clock widget, like the one in the Windows Vista sidebar; or a quote of the day program. Fun little things that add flavour to site like mine – albeit mostly by cluttering it up.
Closing statements
Broadly speaking, I think that I have achieve my stated goal with this first post. You now know what I have been up to this last month or so, and what I will be generally posting in the future. Although I haven’t mentioned every little thing, I think I got the big ones out of the way.
Having said that, going forward I will need to create a better daily routine for myself. One where I can have both the time and mental energy to work on these project more. As they are important to me, believe it or not.
This website enables me to look back on my work and experience it again. It enables me to put something useful and good into the world that I otherwise wouldn’t be able to. Even if I am the only one who reads this. Documenting things here is at least therapeutic. And I think that I will continue to do so.
If I did new years resolutions – which I don’t because they are for weak people, as they are usually used to give these people an excuse to procrastinate important life changes by delaying them until an arbitrary time period. At which point they half-heartedly promise themselves the opportunity to change, only to inevitably fail and resume their previous life habits. But don’t worry dear reader, there’s always next new year. Imma rite?
Anyway what was I saying before I started preaching like a clergyman? Oh yeah. New year’s rez.
Find a good daily/weekly routine that enables me to have the time (and mental energy) to work more on my projects. This includes cutting out bad time, where I am tired and instead of sleeping. I veg out in front of the computer. That’s probably one of the most cut and dry changes I can make to improve my productivity, as sleep restores brain plasticity.
Anyway. Thank you for reading, and happy new year.
#0035: repair and analysis of a talon style folding lock knife
Preamble
I was recently given this folding lock knife to fix for someone. The internal mechanisms of which I found mildly interesting, so I figured it would be worth the time to document it. It may also prove useful for future reference incase I come across something similar.
Initial observations
The first thing that I noticed whilst examining this unit is the unusual blade shape. This is a talon type blade. It is a single edged, crescent shaped blade that curves forwards and terminates in a single point. It’s crescent shape, coupled with the blade edge being on the inner concave curve: give it both a visual as well as function resemblance to the talons of birds of prey. The blade is designed to roughly function in the same way: to pierce and then to hook. This shape of blade can easily convert slashing motions into pierces, due to the blade tip being the leading contact point.
The blade description above may lead you to think that the pictured example knife is a deadly weapon. And that would be the case, at least if not for my second immediate observation. Which is that this knife is a mass produced (I assume) chinese special tacticool toy knife.
It is rather cheaply made, and only really aesthetically resembles the weapon that it is aping. This pictured knife is just a box cutter. That is also it’s literal function currently. Its what the knife’s owner, who is a warehouse operative uses it for. It is also the only thing that it can be used for in my opinion.
Faults
The main thing that was wrong with this unit is that it was not maintained properly. The owner did not tighten the various torx screws on this thing as they worked themselves loose. This led to various joints and mechanisms developing too much play in them. This then resulted in the blade being seated at a crooked angle. Which in turn allowed the blade tip to scratch the handle as it was retracted into it.
Additionally due to the owner’s negligence: some of the various screws that loosened over time, fell out entirely and were consequently lost. This is rather unfortunate, because these fittings consisted of a paired torx screw and socket nut; that where sized to fit flush into the recesses of the handle plates. The socket nut especially is rather annoying to replace. Requiring a specific purchase as it is rather uncommon, and wouldn’t likely be present in any of my bins of miscellaneous salvaged hardware.
The blade itself also has an issue. The main one being that it is made from a miscellaneous soft junk metal; and the second one is that it was currently dull. So it required a basic sharpening, in order to make this knife operable. At least for the relatively short time period that the blade’s soft metal can maintain a serviceable edge.
Parts list
A complete version of this locking knife consists of several discrete components:
1 x camouflage painted outer metal knife handle plate (left)
1 x camouflage painted outer metal knife handle plate (right)
1 x black painted metal inner frame with spring compartment insert gap
1 x black painted metal inner frame with blade locking wedge
1 x black painted metal finger guard with box cutter point
1 x grey painted talon style blade
1 x metal spring
1 x metal spring compartment
2 x plastic washers
4 x smaller black painted metal hex screw and blind nut set
1 x larger black painted metal hex screw and blind nut set
1 x black painted metal trouser clip
3 x black painted hex screws for the trouser clip
Tools and materials
Tools:
Round edge metal file
Knife sharpener rod
Torx screwdrivers (T7, T9)
Tweezers
Materials:
plumber’s grease (or equivalent)
Repair
There really isn’t much to say on the repair itself, as its pretty straight forward. I disassembled then reassembled the knife; fixing everything dodgy about it as I went.
Actions:
Completed knife disassembly.
Bent the blade locking wedge on the inner frame so that it stops the blade from folding closed more reliably.
Greased the blade’s damaged plastic washers to help prevent future wear.
Bent the blade spring’s hook into a right angle in order to get a better hold on the blade.
Re-greased the blade spring within the spring compartment due to presence of dry grease here.
Re-tightened all the screws and socket nuts that keep the housing together.
Added a stand-in replacement for a missing screw and socket nut pair that consists of two screws and a salvaged threaded brass insert nut.
Added a plastic screw and nut to help hold frame. I chose plastic so that I could cut down the screw and round off the nut easily so that it doesn’t snag the user’s hand.
Performed a basic sharpening on the blade using a metal file, then honed the edge using a knife sharpening rod.
The actual repair itself is hardly anything to be proud of. It wasn’t a hard repair and didn’t even take long. However this knife has been saved from going into the rubbish bin, for at least another couple of months, and that should be the main take home. This thing is ready for work again; and should stay that way for quite a while.
Before and After video demo
Before
After
Recommended modifications
1) Grinding the blade edge and sharpening.
The knife blade could use a proper grinding and sharpening: if it to be used for anything more involved than opening boxes. I recommend grinding the blade down so that the angle of the blade edge slopes smoothly up to the mid-ridge. That way the blade can have more acutely angled edge.
This will consequently make the blade sharper than it currently is. A smaller angle will also remain sharper for longer whilst in use, due to the relative thinness of the new blade edge. Even as it dulls. Although the blade will also likely become more brittle and likely to snap as a consequence of the severe loss of material this newly angled edge will require.
2) Installing a blade backstop.
A blade backstop will stop the blade from over-rotating when it is extended. It will also prevent the blade from wobbling when extended by sandwiching it between the backstop and the blade locking wedge.
This knife likely already had a blade backstop of sorts, as it already has the screw holes where on could be mounted. However it was probably lost during use. As it is the blade overextends backwards when it comes in contact with any material that resists it.
3) Thread locker on the screws.
Thread locker such as “Locktite 243” when applied to screws prevents them from slowly working themselves loose during operation, due to factors such as vibration. This will extend the lifespan of this knife when applied to the screws that hold the frames together, as it will mean that they will (largely) no longer need to be checked and re-tightened at intervals.
And since we have already established that this knife’s owner is averse to maintaining his equipment: the lower the level of maintenance this knife needs, will be proportional to the extension of it’s operational lifespan. I.e. it will last as long as it lasts, if the thread locker can keep it together for longer, than it will last a little longer as a consequence.
4) Installation of additional retaining bolts.
I think that installing a few additional bolts and nuts to keep the frame together would greatly increase the overall structural strength of this folding knife. As it would share the strain of keeping the unit together amongst more points. This would allow this knife to be used in applications that require more force.
Although one has to be careful not to drill and install any bolts within the blades seating area within the knife handle housing, or within it’s pathway. Common sense right?
Post mod roles
As it is this knife tool is weak and too dull for any real work beyond cutting the tape off of cardboard boxes. however I theorise that if the above mods are made, then one would end up with a stronger, sharper, and more stable tool.
This would then allow the tool to used in a broader array of applications. For example light wood working, or bush craft applications. A talon style blade is good in both of those applications. The sharp hooked point is good for carving detail into wood. The concave blade is good for gripping and working with rounded objects like natural woods (sticks and branches). For example: for sharpening sticks, or for feathering wood to create tinder. It is also good for harvesting (in this case smaller) plants; as the concave blade helps bundle the stems together when cutting. Like a miniature sickle.
I could go on but I hope you get the point. The issue here is not with the knife’s design, it is with it’s flawed construction. If that could be remedied (or at least alleviated), then this knife could actually become a useful tool. It just requires work to get there.
Closing thoughts
Honestly, I actually rather dislike these types of low-cost low-quality mass produced items. This knife for example: it’s low-cost promotes replacement rather than repair: as it can very quickly make many repairs in it’s owner’s eye deemed as uneconomical. And that is assuming that the owner has a mend-and-make-do mentality to begin with. Most contemporary consumers do not. They have a use and replace mentality.
The main reason why a person may want to repair these things in my mind: is either philosophical (i.e. environmental conscientiousness, fiscal responsibility, anti-consumerist sentiments, etcetera); emotional sentimentality (e.g. hand-me-down from a relative); or if they are in severe financial strife and literally can’t afford to replace a £3.99 work knife.
Now look at it’s cheap build and materials. This factor exacerbates the issue above. Chiefly because it lowers the tools operational lifespan. This is the time it is in use, before it somehow breaks on it’s owner. Hence sooner putting them in a position to make the call on whether or not to either repair or replace the tool.
I do consider a knife like this to have been built with planned obsolescence in mind. Even though the term is hardly used for mechanical hand tools like knives; as it is usually reserved for electronic or computer products.
However, consider this: if the user does no maintenance on this knife. Then there are only so many operational hours that it is capable of before completely falling apart, or at the very least becoming inoperable. It’s shoddy build quality purposefully limits this simple hand tools lifespan. And when it is over, the user is expected to then purchase another one. That is a form of planned obsolescence.
I hate preaching, but please consider not buying this kind of shite. There are better alternatives available. Such as buying second hand quality tools. I always advise that people do the requisite research first. Then spend what they can afford in order to get the best value tools that they can, for their specific use case.
I said “Best value”, not most expensive. A chrome-vanadium spanner is a chrome-vanadium spanner at any price. Just because a person pays more for a brand name, doesn’t necessarily mean that their chrome-vanadium spanner is better than the off brand one.
Nowadays, it’s rather likely that they were both made in the same factory from the same material stock. An idea that would be laughable, if it wasn’t also true. Many brands on the market don’t manufacture anything. They purchase orders from the same OEMs then label the products as their own.
*proceeds to mount high horse.
If you absolutely have to purchase at the bottom of the market because you absolutely have no more money to spend. Then spend time instead. Time upgrading, fortifying, and maintaining your tool. This is so that it can last as long as you need it to. Or at the very least extend the time intervals between new purchases.
That being said, it is an unfortunate reality that most people who do mindlessly purchase bottom of the market products like this knife: are either unable; or more commonly, unwilling to invest time in their tools. They are in many cases content to use the shoddy tool in the short time until it breaks. Then purchase another bottom of the market shoddy tool to replace it with. Repeating this loop of short-sighted wasteful false-economy ad infinitum.
*proceeds to dismount high horse.
I feel that I should somewhat qualify my rather negative sentiments against these types of bottom market products. In the past I have worked within a small recycling facility, one that primarily serviced my local community on behalf of the local council, as well as the surrounding areas. (The point is that we weren’t shipping it’s garbage in.) I worked there as a materials sorter.
It gave me a certain perspective on the sheer volume of material wastage people engaged in. For a supposedly poor community, the amount of waste of useful materials was astounding. Every night I came across hundreds (not hyperbole) of very useable tools of all kinds. Everything from: screwdrivers, knives, drill bits, and spanners, to pots, pans, skillets, as well as whole bicycles some nights. All of that thrown away for recycling.
Many of these things were in decent conditions. Conditions that required either basic maintenance such as: sharpening, some hammering, replacing a handle, or realigning, or even a simple old fashioned cleaning. Gasp! Working there made me dislike a lot of these products; as when I now see them new: I think of where they’ll likely end up in less than a years time … In the fucking trash.
I just don’t like companies purposefully making tools/products that have such a short lifespan designed into them. I doubly don’t like it when these same products are purchased, used, and then wastefully discarded, by people whom I have heard a thousand times: claim poverty. But that’s another rant entirely.
I recently had to repair a constantly dripping kitchen faucet, and thought that I may as well document it. Especially since I found the construction of the cartridges within the tap to be rather interesting. Although I must say that the title does make me feel a bit silly.
Tools and Materials used
Tools:
crescent wrench / 17mm wrench
nylon spudger / pry tool
phillips screwdriver
soft bristle toothbrush
plastic container
pipette
teaspoon
Materials:
petroleum jelly / plumber’s grease
vinegar
water
Tap cartridge inspection
I’d like to start by examining the water faucet’s cartridges themselves, as this information will be relevant later during the repair. The two pictured cartridges were taken from a quarter turn kitchen tap. This is a tap that only requires the handle to be turned 90 degrees around it’s axis, in order for it to go from a fully shut to a fully open state, and vice versa.
This type of cartridge is designed so that water flows into it from the central hole at it’s bottom inlet. This water then flows up inside it’s shaft, and through the two holes within the first ceramic disc. It is then diverted out through the two radial holes on it’s side via the second ceramic disc. At which point the water has a direct route to the faucet head.
This particular type of cartridge has two ceramic/plastic discs within it, that in conjunction with each other operate as a single water control valve. They do this by establishing a water tight seal between them; a press fit seal that is created by the two discs merely pressing against each other in a way that eliminates any gaps between them.
This seal is demonstrated within the video below, where you can see a suction effect take place between the two discs. This suction helps the two discs adhere to each other when wet. This is only possible due to the absolutely smooth surface of the first disc, coupled with the hollow cups present on the second disc’s contacting surface.
These two ceramic valve discs are both keyed to fit into their brass metal shaft in one particular orientation. This orientation has the bottom disc operate as a fixed or stationary valve. Whose job it is to split the ingressing water into two separate streams. It does this via the two distinct triangular quarter-circle holes within it. This lower disc is keyed to fit into the inner wall of the cartridge’s cylindrical housing in a way that makes it immovable.
Whereas the top disc is keyed into the rotating tap handle cylinder attachment. This allows the tap handle to control the rotation of the upper disc. This upper disc is cut in a way that either blocks the two water channels provided by the bottom disc when closed; or when open: diverts water from the holes of the bottom disc outwards to the radial holes in the cartridge housing. This water is then further diverted up and out of the tap for use.
The reason why it only takes a quarter turn to fully open the water channels of this type of cartridge: is due to the placement of holes and channels within these ceramic discs. The first (bottom) disc has two oppositely placed holes within it. Each taking up approximately a quarter section of the circular valve.
This quartering is then reflected within the top ceramic disc. Which consists of two opposing cupped flat plates, and two opposing angled wedges: which veer off to the radial holes within the brass cartridge housing. And since these channels take up opposing quarters of their discs – it only takes a quarter turn to either align both holes of the bottom plate with the upper disc’s water outlet ramps, which then allows water to pass; or with the flat plates, which then blocks the water at both holes.
Cartridge operation demo video
Valve operation demo video
Suction effect demo video
Dripping fault Analysis
Dripping fault cause theory
The fault that causes a dripping tap can be due to a number of different factors. Probably the most straight forward scenario includes water simply making it’s way around the rubber o-rings and/or water gasket. This could happen if the rubbers have gotten old or heat damaged, and started contracting or cracking as a result. Alternatively, they could’ve been disturbed or are otherwise not seated correctly in order to form an effective water barrier.
This means that whatever water does manage to get around these seals can then bypass the cartridge altogether and shortcut it’s way to the faucet head. The severity of the leak in this case would be directly proportionate to the ineffectiveness of the rubbers to seal out water.
Another issue could be within the cartridge itself. With water entering the cartridge and then passing through the cartridge valve by squeezing between the two ceramic disc plates due to an imperfect seal. This pressure fit seal between the two disc plates could be undermined by a number of different factors.
The most likely of which are a build up of limescale on the the ceramic discs themselves. Limescale is a broad term to encompass residual build up of the carbonates present in drinking water; such as calcium and magnesium carbonate. Water rich in minerals like this is often referred to as “hard water”.
Limescale build up on the contact surfaces between the ceramic discs, can cause them to then become uneven as the limescale adheres to them. Specifically the drip issue is caused because the valleys in this now uneven surface provide the water a small pathway across the pressure seal’s threshold when it is closed.
Another issue that could cause the valve to no longer function effectively is scoring of the inter-disc surface. Essentially scratches that then allow some water to pass through their valleys when the valve is closed. A likely cause of this could be something as basic as wear and tear. The two discs grinding each other down over an extended period period of time due to standard use. This happening with just the minor friction created from repeated opening and closing over time, eventually compromising the watertight seal as disc surface material is lost.
Before moving on, I should mention that this section is largely speculation. Basically educated guesses based on my observations during the disassembly. That being said these theories above are the one’s that I went into this repair with.
Dripping fault effect
A continuous drip may initially seem like a minor fault, because it is. However, this fault incurs a waste of resources. A slow but continuous one, that is hard to easily assess. Simply put it wastes water, and probably more than you might expect as well. Just because it only wastes a drop at a time, it doesn’t mean that it isn’t wasting a lot cumulatively. It just makes it difficult to easily see the totality of wastage.
Sampling methodology
Let’s try to get a rough idea of how much water is lost due to this fault. Note that this is not going to be very scientific. It is just a test to get a rough idea of water wastage. With that in mind, there are two discrete pieces of information that are required: 1) is the average water droplet volume; and 2) the number of water drips within a set period of time. In this case the sample time will be 1 minute.
I captured a single drop using a teaspoon. Then sampled it using a random plastic pipette that I had on hand. I repeated this a few times and found the droplets to be rather consistent in volume. Unfortunately, due to the pipette’s lack of precision, I was forced to visually estimate this volume between it’s labelled increments.
Collected observations
This leaky tap consistently provided around 13 drips within any one minute period.
With each drop having a volume of approximately 0.3 ml each.
Water drip rate and predictive volume lost
1 minute: 13 drips @ 3.9 ml
1 hour: 780 drips @ 234 ml
1 day: 18720 drips @ 5616 ml (~5.6 litres)
1 week: 131040 drips @ 39312 ml (~39 litres)
1 month: 524160 drips @ 157248 ml (~157 litres)
Leaking faucet demo videos
Droplet sampling demo video
Leak conclusion
Interesting result. If a household either has a limited water supply (e.g. off-grid), or is on a metered supply where they pay for water by volume; then 157 litres lost in wastage in a single month by a single tap is not insignificant.
I hope this has illustrated how important it is to fix even minor faults such as this as soon as possible. 157 litres of water used could very well cost a metered household more money on the fault’s first month on the household’s monthly water consumption bill, than a complete cartridge replacement for that tap otherwise would have.
Repair process
Getting at the parts
First thing first. Common sense. I switched off the water by closing the main water valve for the house. This was located under the kitchen sink for me. This is an essential step in the same way as one would switch off the electricity before working on an electrical outlet, one needs to turn off the water before working on a water outlet. You’d think that was common sense right? But I have seen too many plumber fail videos online that say otherwise.
After giving the kitchen faucet a once over, and looking online I decided that the tap cartridges are the most likely suspects for the drip, so I set upon getting at them. Since I have never taken a kitchen sink tap apart before, I engaged in what I call an exploratory disassembly. Prodding and poking the device looking for hidden clips and screws.
To cut to the point: I used a nylon spudger to pry open the (metal coloured) plastic screw cover on each tap. I recommend using a plastic pry tool to avoid scratching the finish off of any part of the tap. Next. I unscrewed the phillips metal screws which attached each tap handle to the rotatable cartridge cylinder section below them. After setting aside the tap handles, I then removed the full cartridge assembly from the faucet housing using a wrench. As for disassembling the cartridges themselves, they come apart toolessly in-hand. That’s it. Easy.
Inspection
Like every repair, this one begun with a thorough inspection. A basic visual inspection did not reveal anything obviously wrong with either cartridge to my eyes. However once I disassembled both hot and cold units, I noticed that the internal plastic disc valves on the cold water side felt rough to the touch. Likely indicating a build up of limescale. Most notably this was even apparent on the surfaces between the two valves. And since these two surfaces come together to form the press fit seal that controls water flow: I concluded that this was likely the specific cause to this particular leak.
Limescale build up is nothing unusual for my particular location, as I do live in a heavy water area. However the odd part was that all the limescale build up was on the cold water side cartridge of our kitchen tap. With little to none on the hot water cartridge. This is really unusual in my opinion because I believe that higher temperatures should exacerbate limescale build up. The average water kettle should be a testament to this theory. However in this case the limescale build up was only sufficiently present on the cold water side.
A working theory I have concerns the on demand water heater which directly supplies this tap – a boiler which my household recently (1.5 years) had professionally installed. I believe that it has some-kind of water filter (or softener, or descaler…) that has been fitted to minimize limescale build up within the unit as it heats water. This means that the hot water provided by it to the tap would have less mineral contaminants (i.e. be softer) than the cold side. I would verify this, but it is not a pressing issue and not worth digging the unit out at this moment to confirm.
Cleaning the cartridge
Once I decided that it was limescale that was undermining the valves press-fit seal, I decided to take the already disassembled cartridges and submerged them into a vinegar solution. The idea is that the mild acid of vinegar will react with the alkaline limescale and dissolve it into the liquid solution.
After about an hour, I removed the parts and brushed them all down with a basic toothbrush in order to remove any loosened remaining debris. I did however take care not to scratch or score the plastic valves as any scoring would also undermine their ability to form a watertight seal; as this would allow water would pass through the miniscule divots that would be present on the seal’s contacting surfaces.
With regards to this method, I should note that I made exceptions for the rubber parts of the cartridges. The blue o-rings and red/blue rubber gasket. I just did not feel comfortable submerging them in an acidic solution for extended periods. I feared that it may affect the chemistry of the rubber material and ‘dry’ it out. Thus causing it to crack or split; and consequently be no longer effective as a waterproof seal. (FYI the pictures below are lying.)
Testing
After a quick rinse in tap water I decided to reassemble the cartridges and put them back into service for extended testing. Although the leaking was significantly reduced as it didn’t drip continuously as before: it still dripped regularly. This was tested by leaving an empty cup under the tap head overnight. I’d regularly find the typical coffee cup I used at least half-full come morning.
This lead me to surmise a number of scenarios:
1) That the water was making it in between the the plastic valve seals. Likely due to surface scoring caused by either my cleaning/brushing of the valve discs; or the limescale itself being ground into the discs as they operated over the years.
2) Water is making it’s way around the gaskets and o-rings, in addition to bypassing the valves. And that I have only remedied/alleviated one issue.
Greasing the cartridge components
With these conclusions I decided to then purchase some plumber’s grease. Thinking that it would be perfect for the application of assisting the plastic disc valves and rubber gaskets to form water tight seals. The Ebay listing for it explicitly stated just that.
However once the product arrived, I decided that I wouldn’t be testing it’s efficacy as I decided that it was not fit for use. The reason why: was that the little tin came with a whole host of warnings on it’s label. Warnings typically associated with poisonous chemical products.
Particularly the “Do not eat, drink, or smoke …” around this product warning gave me pause. Especially when coupled with the fact that the very vapours from this thing were an irritant. It emitted a vapour that was a mild irritant to the eyes and nose, smelling almost minty like the ointment “tiger balm”.
So despite the labelling assuring me that it is indeed appropriate for use within water faucets, I decided that this was not something that I wanted coming in contact with my drinking water – and ultimately ending up inside me. Maybe I am just paranoid. Maybe not.
Either way if an irritant chemical has warnings not to ingest it, and by using it for it’s intended purpose you are essentially guaranteeing ingestion. Maybe don’t use that chemical. Ultimately, it all just comes down to personal choice, and how much you trust anonymous Ebay sellers over your own intuition.
Personally I just found a substitute: Petroleum Jelly. A non irritant, non toxic chemical that routinely comes in contact with human skin and lips. So chances are good that it won’t do any harm if you accidentally ingest some with your drinking water.
Additionally unlike the plumber’s grease, the jelly can be used with rubbers like the o-rings and gaskets. I used to use some back in school within the science lab. A small amount was applied to the mouth of a bunsen burner’s rubber gas hose in order to help form a gas-tight seal between it and it’s brass attachment. I remember it even hydrating the dry red rubber of those hoses. Although I am pretty sure that petroleum jelly is also flammable so I’m not sure if that was a particularly safe application for it. :/
However within this application: my only concern with petroleum jelly is it’s longevity in the system, and heat resistance. However those are considerably less concerning than putting poison in a drinking tap. So after greasing everything up: the o-rings, the rubber gasket, and the plastic valve discs, then tighten everything down properly – I did note further improvement. Now the faucet barely leaks at all. Barely being the keyword here.
Jobs a gudd’un mate.
Post repair review
I left some time after the repair for observation before writing this review and it seems the leak is slowly returning after a month. A month of constant use keep in mind. I am still chalking it up as a success because this repair really only needed some basic tools and materials. The only consumables used are just household sundries like vinegar and pure petroleum jelly. So it can be done for next to nothing.
There are even more things I could do short of purchasing replacement cartridges, and that would be to use an additional o-ring under the main water ingress rubber gasket. This will put more pressure on the plastic disc valves. Squashing them together to form an even tighter pressure fit seal between them.
Although there are likely drawbacks to this, including and not limited to: firstly, a stiffer tap – the more downward pressure on the cartridge mechanism, the harder it would be to rotate it; and secondly, the higher pressure on the discs themselves would cause them to grind against each other more, and likely shorten their lifespan by promoting scraping of their contact surfaces.
Although if you are repairing it in the first place, chances are that they are already well towards their end-of-life, in which case this fix will extend it couple of months before they likely fail into a unrepairable state. At which point replacing the ceramic discs will be needed. Just my guess.
Closing thoughts
Not much to say here really, I surmised my thoughts on the repair itself within the Post repair review above. So I’ll go with a more personal note here.
I actually enjoyed looking at this tap cartridge more than I thought I would. It really is amazing what people are capable of creating through iterative design and mass production. It reminds me of the gaming concept of min-maxing: of getting the most out of the lest.
I mean look at the simple design and construction of this cartridge. It uses two plastic/ceramic discs to create a watertight seal by just pressing against each other. Undoubtedly the results of iterative cost cutting to the point of being adequate or acceptable, and little more.
I know that when I usually talk about cost cutting, especially when discussing mass produced goods: its usually in a negative light. That’s because the stimuli or catalyst for those tangential rants tends to be a product that is sub par, and in my opinion not fit for purpose. Products that I refer to as “factory fresh e-waste”.
However that is not the case here, these cartridges are fit for purpose. But they are also (in my humble opinion) built down to a price point. One that makes economical sense. Look at the bill of materials here for example: a brass housing and insert, a retaining clip for the insert, a metal washer, two o-rings, a water gasket, a metal screw, two plastic/ceramic discs, and maybe one or two additional miniscule hidden parts that I missed. That is a list that has been reduced to the absolute necessities and little more, but nothing less either. I admire the philosophy honestly.
Anyway, enough gushing about the tap. Since I repaired it: it’ll do that itself in a year or two ;). Upon looking up the Ebay prices for replacements, I noticed that they are very cheap. (At least the generic versions.) The average price for a set of two is £10; and if you wanted to repair your own two cartridges with a kit of replacement o-rings, gaskets, and ceramic discs, then that’ll set you back around £2.50. Very doable.
As a final note, if you found yourself confused as to why I kept referring to the cartridge discs as both made out of plastic and ceramic. Well, this is because the unit I was working on (pictured) felt like plastic to me. A hard somewhat brittle plastic.
However upon looking them up online, apparently they are all ceramic. I also wrote the repair section during the repair process prior to this; and I decided to leave it as plastic because that’s what I felt that material was while I was handling it. Although I am by no means an expert on such things, if the internet says that it’s ceramic then I guess it likely is.
As a bid to get myself into creating music – or at the very least something music adjacent: I decided to purchase a Stylophone. A simple and cheap electronic synthesiser. Something budget friendly and fun looking with which to test out the waters.
What is a Stylophone and how does it function?
If you are unfamiliar with what a Stylophone is, I will briefly explain. A Stylophone is a handheld electronic musical instrument. A synthesiser that creates audible waveforms from electricity.
The most notable feature of this instrument is it’s set of oversized PCB (Printed Circuit Board) pads, which operate as musical keys. These keys are accompanied by an electrically wired stylus, which functions as their activator. To play a note, one just has to touch the stylus to a keypad. This then closes an electrical circuit within the device, in essence mimicking a keyboard (button) press.
Broadly speaking, component-wise: at the heart of a typical Stylophone lies a voltage controlled oscillator. This component creates a waveform when fed a DC voltage. This waveform is then fed to the speaker to create an audible tone. Since this is a voltage controlled oscillator, it means that it’s output waveform is dependant on the input voltage supplied. Thus voltage is used to control the specific sounds produced.
To control the oscillator input voltage, each musical note key on a Stylophone has it’s own circuit with it’s own unique resistor values that are different from all the other note keys. These resistors are used with the intention of stepping down the 9 volts input into whatever each note-key’s desired oscillator supply voltage is.
Although there is undoubtedly more to discuss on Stylophones; such as how the pitch change, or vibrato functions operate: they are largely out-of-scope for this simple introduction. Although I will go into further detail if/when I do a full device analysis on this Stylophone. (Link below when/if that article is written.) However in general Stylophones like this one are really not too complicated devices.
Tools and equipment
Tools:
soldering iron
hot glue gun
toothbrush
tweezers
desoldering pump
Consumables:
hot glue
isopropyl alcohol
desoldering braid
(leaded) solder
solder flux
Components:
red 5mm⌀ through-hole LED
ethernet wire (multi-strand copper wire)
10kΩ potentiometer
toggle switch
Device Repair
Fortunately (or perhaps unfortunately for this article) the device needed very little fixing. It’s main faults were either cosmetic in nature or trivial to fix; and since the Stylophone was basically fully functional, other than the dirt and grime that had gotten into it over the years: there’ll consequently be little to say about it in this regard.
I will say that the sound it produced was a bit choppy (intermittent), probably due to dirty contacts on the keypad. This issue of dirty contacts applied to the two built in slide switches as well, as they where notably unresponsive. Flicking them produced unreliable results.
More specifically: flicking the power switch on didn’t always cause the device to power on. I had to toggle it a couple of times for it to operate as expected. Additionally I couldn’t even tell at the time that the “Vibrato” button wasn’t functioning. It was only until after it was cleaned and started working, that I realised what it actually did. It makes the sound of the notes “wobble”.
Since these slide switches were built into the PCB itself, rather than a discrete component than can be easily removed: I decided that the best course of action was to simply inject some isopropyl alcohol into them. Then work the switches on and off until they self cleaned. The combination of the alcohol breaking down the embedded grime chemically, and the friction from mechanical manipulation cleaned the electrical contacts.
Moving on. I cleaned the PCB keypad in a similar way. Dousing it in alcohol and scrubbing it with a toothbrush to remove any loosened debris. This simple cleaning fixed both the intermittent connection issues of the switches and keypad.
Another small but annoying issue I encountered was with the stylus’s wired cord. It was damaged. The cord had a deep nick on the inner side of a loop that it had to fold in on, in order for the stylus to fit into it’s receptacle. Because of the location of this damage, it meant that I couldn’t simply just put a layer of heat-shrink tubing over it and call it a day, as it would limit the cord’s flexibility. Which in turn would make it no longer able to fold up and fit into place.
Instead I decided to just replace the entire wire. This lead to the next issue. The stylus’s original wire is somewhat unique. It’s inner structure consists of loose bundles of stranded metal conductors (presumably aluminium) interlaced with plastic (nylon?) fibres. This made it significantly more flexible than any of my wire stock. This flexibility allowed the wire to fold in tight under the stylus when placed into it’s receptacle.
Since I didn’t have an appropriate substitute wire, I decide to just use the best that I had on hand. This consisted of a single line of pure copper multi-stranded wire that was salvaged from an ethernet cable. Since this wire was considerably less flexible than the original, it meant that I could not use the original cable hole to enter the stylophone, if I also wanted to use the stylus receptacle as well. This is because the new cable could not fold into the same tight space under the stylus the old one did. Prioritising the stylus’s use of it’s holder, I decided to just drill another hole for the wire towards the back of the stylophone’s plastic housing.
Now, with regards to the more cosmetic elements of this repair: firstly, I removed and straighten the bent metal grill top plate. I then scraped it and the plastic housing clean of all that yellow hard glue using a scalpel. Ultimately I replaced all the old yellow glue with hot glue after I cut up the grill to fit my additions.
Although as a whole, probably the most noticeable thing about this Stylophone: was the prominent yellowing of the plastic housing. This yellowing is caused by ultraviolet (UV) radiation in sun light. The more sunlight a plastic enclosure like this gets in it’s lifetime, the more yellowed (or even brown) it becomes. Ironically to restore these plastics to their original colouring, one has to use a UV light in conjunction with hydrogen peroxide.
I briefly considered whether or not I wanted to restore the plastics to their original white. And if this was a full restoration project I would have done just that. However this wasn’t the point of this project, since at the end of the day: I was planning to add some crappy home-brew mods to it.
Additionally, I actually rather like the yellowing of older machines. Computers especially. I find it nostalgic. It reminds me of a simpler time: of a young boy listening to the hum of a beige box as it powered on, and the clicking and chittering of the various drives as they promised quality escapism. Insert Sierra logo tune here.
Device Modifications
First things first: for anyone who might raise an eyebrow at my choice of components below, I wish you to know that I basically decided to modify this Stylophone with whatever junk I happen to have on hand at the time. I was unwilling (and somewhat unable) to purchase or salvage more appropriate components for the task.
Not a single part that I put into this machine works as well as they could if I did take the time to source (or install) things properly. However I think that for this particular use-case, such perfectionism is unnecessary. It was just a fun and experimental hack together; and ultimately a learning experience.
With that in mind, I made three simple mods. These were made with the aim to better facilitate my particular use case of this instrument. Something I will explain as I go on.
These mods are:
a power indicator
an internal speaker cut-off switch
and a volume dial for the internal speaker
1) Power indicator
The necessity of an indicator was made apparent to me: when I first picked up the Stylophone to find that I had left it on between sessions, and that the battery was now flat. Now that isn’t to say that the Stylophone definitively uses power when on but not actually playing. I’d need to test whether or not that is the case to say for sure. Either way really, a power status indicator is needed on this device to remind me to turn it off when putting it away. Simple as that.
To install a power indicator, I just used a basic 5mm⌀ red through-hole LED paired with a 330 ohm resistor. I tapped into the 9 volt positive side just after the power switch, and the negative side to the common device ground.
Unfortunately, this resulted in the LED being far too bright for my liking; with a light output that is more applicable for illumination, than as a device power status indicator. I really should have ran some basic ohm’s law calculations on this. Instead I simply used the same resistor value that I was accustomed to pairing with these types of LEDs on the 5 volt circuits that I am used to. Even then, they were rather bright. Now they are even brighter. I should have used a resistor with a much higher value. 1kΩ would likely do for a status indicator on a 9v circuit.
RED 5mm⌀ LED amperage and brightness comparisons
maximum continuous amperage: 30mA
recommended continuous amperage: 20mA
setup I am used to: 5v/330Ω=0.015A (or 15mA) –> reasonably bright
current setup: 9v/330Ω=0.027A (or 27mA) –> too bright
future amendment: 9v/1000Ω=0.009 (or 9mA) –> perfect for a status indicator
I should state that in my experience using ohm’s law like this is a good guide for component choice. However components are all variable. The vast majority of components all operate within certain tolerances of their stated values. Additionally they can also behave differently once within a circuit.
For example I tested a red LED with a 330Ω (actual value 329Ω) resistor in series on a breadboard and provided it with 9 volts. It’s current draw was 22mA. I don’t really know why. It should still be 27mA. I’m guessing that I am likely not adjusting for something, such as the inline resistance of the breadboard and it’s contacts. Either way, these simple calculations still allow a technician to set their general expectations with regards to component behaviour.
2) Internal speaker cut-off switch
In addition to the internal speaker the Stylophone also comes with an amplifier output socket (3.5mm audio jack socket). I intend to use this socket to sample the audio. Either directly, or via an intermediary signal amplifier of some sorts. This is an alternative to recording using a microphone as you would with an acoustic instrument for example. I think direct sampling like this would produce a cleaner signal, and ultimately better audio.
I added the speaker cut-off switch because I didn’t want the Stylophone itself emitting sound while I was sampling it using a computer. Additionally, since I am likely to be plugged in to PC audio using headphones during the process: the Stylophone playing to the room is unnecessary in this scenario. Hence it might as well be silenced in order to minimised noise pollution and/or disturbance to others.
To make this happen, I just added a switch to the line between the main PCB and the speaker. I decided to use a toggle switch because they are cool. Very simple stuff. That being said, I probably wouldn’t have bothered with a speaker cut off switch if I though of installing the volume dial first. This is because it effectively performs the same function. By lowering the speaker volume to virtually nothing, it does the same job of silencing the speaker.
This was however the first thing that I installed into the device, and I have to confess it was predominantly because I thought that toggle switches were rather neat. I like the tactile feedback of flicking a switch like this, and because of that, I then went looking for a reason to install it into something. I actually almost used two switches like this to replace the two built in slide switches; but decided against it when I saw how they where integrated into the actual PCB itself. Too much work for too little return.
As it is I did notice something interesting about this toggle switch. When flicked off, the signal outputted to the 3.5mm audio jack socket lowers in volume. I think this might have something to do with the cut-off switch taking the internal speaker out of the loop. Perhaps the lower impedance of the speaker coil draws a higher amperage. Which would provide a stronger signal which then would have access to the audio out socket: since it has been place in circuit parallel with the internal speaker.
It’s just a guess, I honestly don’t know why removing the internal speaker from the circuit would result in the signal volume on the audio output lowering. I’ll look into it further when it comes time for a full device overview of this Stylophone. Just for clarity, I should also mention that this does not happen when the internal speaker’s volume dial is set to lower the volume to zero. With it’s potentiometer adding ~10kΩ in series with the speaker in the process. It only happens when the switch cuts the speaker out of circuit entirely. Hmm. :/
pins bent to fit space
3) Volume dial
This is probably the only add-on of mine that is actually an absolute necessity in my opinion. Simply put: the Stylophone’s default volume is too loud. It’s tinny high pitched notes can easily come across as obnoxious and irritating at it’s default volume. Especially, when the player is using it to learn by playing the same little tune again and again, and fucking it up half the time.
To install a volume dial, I placed a potentiometer in series with the speaker. That’s it. In this case I used a 10kΩ pot as that’s what I had to hand. Once it came to testing however: it became apparent that I was using less than a quarter turn to effectively move the volume from 100% to 5% volume. With the other approximate two quarters moving the volume from 5% to 1%. Interestingly, the volume never does go down to zero. Even with the full 10kΩ of inline resistance: I can still hear the notes coming out of the speaker faintly. (For context: this pot only rotates to approximately 225 degrees; i.e. to a little under three quarter turns.)
I think this may be the reason why older devices’ volume dials ended with switches. For example with mono-sound CRT televisions: they’d work the volume level with a potentiometer, and then once the volume was below a certain threshold the dial switch would click on to either mute the volume entirely, or switch the device off all together. With that in mind, it makes the unnecessary speaker cut off switch sound almost useful. Eh?
If I were to redo this add-on: I would probably replace the potentiometer, with one with a smaller resistance value range. Maybe a pot that caps at 2500Ω. This is because only the first quarter of the current 10kΩ pot is in effective use, as it represents the most dramatic change in resultant volume.
The main reason why I may want to use a smaller value potentiometer is because it will increase the amount of incremental control the user has over the volume. This increase in precision is caused by adding a larger number of degrees that the dial needs to be rotated in order to increment the volume. Ideally this will result in a full turn of the pot corresponding to the volume scaling accordingly (100% to 5%). As opposed to the current setup of 0 to 90° rotation representing a 100% to 5% volume level, with the other 160° of rotation essentially going to waste.
Another way I could possibly achieve this is by using the same 10kΩ potentiometer and pairing it with a fixed value resistor in parallel in order to bring it’s effective max resistance value down to around the 2.5kΩ I desire. I am honestly not sure how that would work out, as I am only thinking of this while writing. I will experiment with putting resistors in parallel with the potentiometer when it comes time to revise this device.
volume differences on external output w/ using speaker cut-off switch
Music demo (internal speaker)
Music demo (external speaker)
Closing thoughts
Ya’know reading back on this: it really is funny how much I could say about so little. At the end of the day all I did was purchase an old Stylophone, clean it up, and then stick a bunch of bullshit in it.
Now, some people may be mad that I did this to such an old device. I noticed that it was made in the 1970’s; and honestly it’s age did give me pause. However I paid very little for this Stylophone, and bought it for the express purpose to tinker with. Additionally, it was literally the cheapest one I could find. Spares and repair condition, economy delivery, no returns accepted. You know the drill.
Also let’s be honest here: not everything old is an antique (e.g. your mum ;)). A mass produced low price point item like this Stylophone is not going to be worth much any time soon. However my innate preservationist did have to hold his breath while I butchered this wee lad. I’ll say that much.
I will be revisiting it, mostly to repair my repairs. To lower the power LED’s brightness, to decrease the volume potentiometer value, and to look into the utility of the speaker cut-off switch. I did have a few other mods in mind as well for it. Such as a 9 volt DC barrel jack socket and power source switch. That way I can run it off a wall charger in addition to battery.
That’s right you heard me. If I am going to butcher a beloved piece of British history, I am going to go all out.
Thank you for reading.
Term glossary
CRT – Cathode Ray Tube DC – Direct Current LED – Light Emitting Diode PCB – Printed Circuit Board UV – Ultra Violet
#0032: Instructions on digitising physical documents
Preamble
This will be a quick guide to anyone who may be interested in creating their own digital archives of physical documents. Although there are undoubtedly any number of different ways to achieve this task: I only intend to show you one method. The method that I specifically use (at the time of writing) in order to create, label, modify, and archive document files. Files such as the ones hosted on this website’s “Device Document Scans” page.
1) Scanning the physical document. 2) Initial edit, and virtual file export of scanned images. 3) Edit of image dimensions and watermark application. 4) Creation of alpha-less versions of the edited images. 5) Compilation of all alpha-less images into a single PDF file. 6) Test, organisation, and archiving of files.
Process explained
1) Scanning the physical document.
I use the flat bed scanner on a Pantum M6607NW laser printer scanner combo, in conjunction with a standard GUI GNU/Linux program called simple-scan. One by one I scan all the document’s pages using a 300 DPI (Dots Per Inch) image fidelity setting.
2) Initial edit, and virtual file export of scanned images.
I use simple-scan to export all the raw scanned images in a lossless PNG image file format.
Although simple-scan has some basic image editing functionality, such as image rotation and cropping; I tend to shy away from cropping images here due to the lack of precision available with the tool. However a rough crop to minimize image file size can be useful at this stage. Especially when scanning documents with a smaller page size (e.g. A5); which would otherwise have a lot of needless (memory consuming) white-space in each image.
Additionally, I find that rotating whole images at this stage using simple-scan to be a better experience than rotating them later using GIMP (or even xviewer). This is because, anecdotally: it seems to use less system resources for some reason. It’s just a smoother experience.
As for the outputted files themselves: I like suffixing metadata information onto the file name. In this case “_300DPI_scan”. This is to help identify specific files when they all get archived together.
It also adds a certain element of future-proofing because I may want to create higher or lower DPI versions of the same documents for specific purposes in the future; without it causing a naming conflict, and upsetting my global naming scheme.
3) Edit of image dimensions and watermark application.
I use GIMP (GNU Image Manipulation Program) to crop each page image with pixel perfect uniformity (i.e to the same image dimensions). Then I apply my watermark to each page and then export them as PNG images again. I mark the exported PNG files with the ‘WM_’ prefix to differentiate them from the original PNG images, which would otherwise have the same file name.
For the sake of clarity I should state that I keep all the original files (raw scan images) just incase I need to work with them again, and for some reason I do not wish to use the edited versions. It’s good practice to always keep and archive the original unadulterated images for instances like these.
4) Creation of alpha-less versions of the edited images.
I use the terminal “convert” program to remove the alpha layers of every PNG image. This is because “img2pdf” can not compile PNG images into a PDF that contains alpha layers. (I.e. clear sections/layers within an image). If you try to, img2pdf will return an error message that contains additional instructions. Unfortunately it will still also output a 0 byte PDF file which you will have to delete.
Error message:
WARNING:root:Image contains transparency which cannot be retained in PDF.
WARNING:root:img2pdf will not perform a lossy operation.
WARNING:root:You can remove the alpha channel using imagemagick:
WARNING:root: $ convert input.png -background white -alpha remove -alpha off output.png
ERROR:root:error: Refusing to work on images with alpha channel
The “convert” command options assigns the background colour to the image as white. This is the colour that replaces any clear (or alpha) sections of the image. Next the alpha sections of the image are removed, then all alpha functionality of the PNG file is switched off.
Please note the exact order that the command options are passed to the program is not important, I only state this order for human understandability. Additionally the “convert” program does not actually convert the original files inputted into it, it instead outputs a modified copy. It will however overwrite the original file if you give the output file an identical name.
I suffix the “_no_alpha” label onto the the outputted files to differentiate them from their predecessors. Although as you can see the file names are getting long and unwieldy, especially if the manual itself already has a long name. However the various prefixes and suffixes all serve a purpose and are necessary for file version distinction.
Command:
convert WM_generic_manual_p1_300DPI_scan.PNG -background white -alpha remove -alpha off WM_generic_manual_p1_300DPI_scan_no_alpha.PNG
This stage firstly involves testing if the PDF actually works as expected. Whether or not it is functional and whether or not all the pages contained therein are in the correct order. As well as rendering and scaling correctly. To do this I just try to open the file using Mint’s default PDF viewer program (namely xreader), and skim through the document’s pages.
This stage also involves putting each different collection of images from the various stages of this process into their own labelled ZIP format archive file. Then placing all these files into another container ZIP alongside the ultimate resultant PDF.
It is then placed into the local “device_document_scans” folder. Which is then copied over to the backups. Finally, I also upload the PDF by itself onto this website.
As far as hardware requirements go, its just the bare essentials really: a decent scanner and computer. Neither devices need to be anything special, just fit for purpose.
Computer
As for computers, whatever computer you are currently using is likely to be just fine. The main thing that may become an issue is probably system RAM size; and even then only when scanning large (600+ DPI) multi-page documents at the same time.
This is because the scanning program will have to hold all these rather large images uncompressed within the RAM as you scan through the document. RAM may also become an issue when using image manipulation software like GIMP. If it is too low it may limit how many images you may work on concurrently. At the very lest it may limit your ability to do other things on the machine as you process these images. For example running a RAM greedy application such as a modern internet browser (e.g. Firefox or Google Chrome).
Another thing that may be a limiting factor with computers is CPU processing power. When converting file formats or compiling a series of images into a portable document file: your system may freeze or become unresponsive. Especially if the programs used/running aren’t optimised to be multithreaded. Resulting in the instruction sets all getting queued on the same CPU core and thread. This in turn causes the unresponsiveness as user input is queued behind these instruction sets.
To sum it up, any computer with more than 2-4 gigabytes of RAM and an early generation Intel i3 processor will likely suffice. However there are too many variables that may affect whether or not these system requirements are adequate; such as the desired scan image size, resource use of the operating system, scanning program, as well as background processes.
Scanner
Now onto the scanner. Most if not all modern flat bed scanners should be adequate. Chances are if they connect to your computer via USB 2.0 protocol or better than they are new enough to provide the 300 DPI (dots per inch) image quality that I use for digitising my manuals. If you are scanning photographs you may require a higher DPI rate such as 600 DPI to maximize image detail retention.
However since the value of my manuals is rather utilitarian in nature, 300 DPI is a fine image quality for my use case. By ‘utilitarian’ I mean that the information printed onto the manuals is what I am primary preserving, and not each page’s visual aesthetic. Because of this I just need them to be legible without necessarily preserving every minute page detail.
Heck, an argument could even be made to go down to a 75 DPI scan setting: as it’s perfectly useable whilst also minimizing all file sizes; including all intermediary portable network graphic images, as well the final portable document file.
However I find that working with 300 DPI images (which translate to a maximum of 2550*3507 pixels for an uncropped full scan) are a good compromise between image detail and workability/use-ability.
Example of 1200 DPI scanned image unable to be displayed with xviewer
1200 DPI / 10200*14028 p / 211.9 MB (lossless PNG)
Software
Since my operating system of choice is Linux Mint running the Cinnamon desktop environment, I just use the programs that are either available with the initial install package as standard; or downloaded from the standard Ubuntu repository if necessary.
Simple-scan comes preinstalled with Linux Mint. It is the default scanning utility program. There are more robust alternatives such as ‘xsane’; however my philosophy with regards to tools like this is that one only upgrades tools or seeks alternative tools when the default tools are found to be wanting. I.e. when there’s a particular functionality or quality that the current toolset doesn’t provide; and since the default simple-scan program provides adequate functionality, I don’t need to seek alternatives just for the sake of it.
Moving on. Both GIMP, Image Magick and ‘img2pdf’ are available within the standard Ubuntu software repository. So both can be downloaded using the ‘sudo apt-get install’ commands. However it is recommended that you first use “apt-cache search [program]” command to ascertain whether or not they are available within whatever repository that you are using, if you are using another Linux distro to Linux Mint.
To sum up GIMP. If you are coming from Windows, you may be used to other image manipulator programs like ‘paint.net’ or ‘Adobe Photoshop’, if not GIMP itself since it is a multiplatform program and available on Windows. Anyway if you have used any modern full-suite WYSIWYG image manipulation program, then GIMP will be an easy enough program to jump on to.
Finally Image Magick. This is a software toolkit that you access via the Bash terminal. Many people, including myself prefer TUI based programs like this due to their ease of use, user interface uniformity, and functional robustness.
I often write scripts including commands that utilise programs that can be accessed via Bash. The programs provided by Image Magick are no different. Once a person gets used to using them, it becomes a natural progression to create scripts which then automate the process.
This would be useful for situations such as batch conversion of multiple files: as scripting allows the user to go AFK or do something else, rather than babysit the process. Scripting and chaining commands like this is probably the greatest strength of CLI/TUI programs over GUI programs.
Closing thoughts
If you aren’t already accustomed to using any Linux based distro, then one thing I recommend keeping in mind is hardware compatibility. It is probably this platforms biggest weakness.
This is specifically because most companies build their products to target the Windows platform. Often facilitating device functionality by using proprietary drivers, and oft times even programs: such as with proprietary controller programs for LED keyboards. These drivers are sometimes absent in Linux. However in most cases there are open-source alternatives.
In the past this used to be a bigger issue. Thankfully the list of supported peripheral devices has gotten much better as of late. As it is at the time of writing, and according to my personal experience as well as as some online reading: most devices work flawlessly plug-and-play; however, some devices work for the most part but are missing some advanced functionality, and some devices don’t work at all.
Unfortunately the best way to tell whether or not your device will work, is by simply plugging it in and fiddling with settings and open source drivers; until it either eventually works, or you give up. Whichever comes first.
As an example: I had quite a few issues with my system not recognising my Pantum M6607NW printer-scanner combo properly, despite official Linux drivers being available on the standard repository, and via the companies website. Even now, after resolving that problem and getting the thing working, I am still having some minor issues with the device.
For example if you paid attention to the images above, you may have noticed that Simple-scan allows for a 2400 DPI scan in conjunction with the Pantum M6607NW. Unfortunately this setting doesn’t work as expected. It does scan the document, and it does it noticeably slower than on the 1200 DPI setting. Which is as expected, due to scan heads collecting more detail from each page segment. However the resultant image has the same pixel dimensions as a 1200 DPI scan. So if there is a higher detail density, it isn’t reflected in a larger image dimension – as is the case with all other DPI settings.
Although xviewer failed to open images of this size, the Firefox browser did not; and upon visual inspection and detail comparison between the 1200 and the 2400 DPI scans: I have concluded that they are identical. See for your self, the files are listed in this article. Knowing this, it is likely that simple-scan is providing an option that the scanner can not support. Although the Pantum’s slower read speed on the 2400 setting has me doubting this conclusion. Since it seems to exhibit a programmed hardware response to this setting.
I could likely find the solution eventually by combing through the official generic M6600 series online manual for my machine, then hunt down more specific documentation … although it is frankly not a priority at this point. As I am not planning on using a 2400 DPI scan setting anytime soon. I only highlight this specific issue to make you aware of the kind of troubleshooting fun to expect on this platform.
So if you are moving to a Linux based platform for productivity purposes, well you can’t say that you haven’t been warned. Having said that, don’t let that stop you from using this platform for this purpose. When it works it works fantastically, and when it doesn’t there is always something that you can do yourself to make it work. You have to get used to being your own tech support.
Best of luck archiving your documents, and as always: Thank you for reading.
Glossary of terms
AFK: Away From Keyboard Bash: Bourne Again SHell CLI: Command Line Interface DPI: Dots Per Inch GIMP: GNU Image Manipulation Program GUI: Graphics User Interface PDF: Portable Document File PNG: Portable Network Graphic PnP: Plug and Play TUI: Text User Interface WYSIWYG: What You See Is What You Get
#0031: Creating a TF2 themed RimWorld scenario mod
Preamble
I recently decided that I’d like to try dipping my toes into creating mods for RimWorld. Incase you are unfamiliar with the game: RimWorld is a base builder; where the core objective is to try to create a functioning base or colony.
Building and maintaining this colony is achieved by issuing orders to various pawns. Examples of orders include: building the structures you designed, hunting animals, farming crops, fixing broken items, creating tradable goods, and cooking food to name a few. Additionally, it also includes arming up and engaging in combat.
RimWorld is a game that is in a similar vein to the venerable classic that is Dwarf Fortress. And like DF, once you have built a base that is halfway decent, you can then move on to secondary objectives such as: exploring the world, or actively trading and warring with other factions.
I decided to start modding RimWorld with something very small. Something that could be done in one or two sittings and with minimal research and planning. That way the mod doesn’t risk spiralling out of it’s initial small scope. Which can likely result in an eventual state of demotivation and ultimately project abandonment. Which is primarily caused by ongoing feature creep due to poor project management (scope discipline).
With that in mind: I decided on a simple custom scenario, coupled with a preset roster of pawns. For nostalgia’s sake: I decided to give this scenario a Team Fortress 2 theme. As a rule of thumb (and for obvious motivational purposes) I only really create things that I myself would like to play with. And to me at least: the idea of playing with the TF2 roster within the RimWorld settings sounds pretty fun. I hope you agree.
Creating a custom scenario
Scenario creator tool
Straight off the bat I should mention that the built-in scenario creator tool does not facilitate editing the individual starting pawns itself, just the world conditions and the equipment that they start with. In other words it does not allow for the modification of each individual pawn’s variables such as traits and skills. To specify pawn variables, one has to use an additional mod called “EdB Prepare Carefully”. Which I will discuss in more detail later.
With that said, let’s begin. Creating a custom scenario is a rather straight forward affair. All you need to do is navigate the menus within the RimWorld game, and follow their very simple instructions.
There are several game options available from the scenario editor. However for the most part editing a game scenario consists of choosing how many pawns the player is able to choose from, and then start with. Then choosing their starting load-out of equipment and resources: weapons, tools, food, animals, building materials, etcetera.
Additionally one could also add various world conditions such as periodic events (e.g. meteorite crash), permanent weather conditions (e.g. toxic fallout), a game time limit, as well as more wacky things such as every world pawn exploding upon death.
It seems like a rather fun thing to play with, however I only required an equipment list that vaguely resembled something that the real TF2 cast might have. I tried to give each pawn similar weapons and tools to the characters that I modelled them after. However, the group got little else in terms of general equipment and technology, outside a handful of exceptions for narrative reasons. Namely the ground scanner and a drill; since they are technically (narratively speaking) on this rim world in order to survey it for Australium.
I should also mention that I designed this equipment list with the mod “Simple Sidearms” in mind. In other worlds each character pawn was designed with the intention that they have the ability to carry more than one weapon. For example the Sniper was given either a sniper rifle or recurve bow to equip as a primary weapon, with the gladius (a functional surrogate for his kukri or bush knife) to be used as a secondary weapon (sidearm). Although the mod itself isn’t strictly necessary. If you choose not to use it, you’ll just be saddled with an abundance of surplus weaponry sitting in your stockpiles. That’s all.
Pawn equipment list
Sniper:
[x1] sniper rifle
[x1] recurve bow
[x1] plasteel gladius
Pyro:
[x1] incendiary launcher
[x1] molotov cocktail
[x9] incendiary shells
Scout:
[x1] shotgun
[x1] wooden Club
Soldier:
[x1] shotgun
[x1] plasteel breach axe
[x3] triple-shot rocket launcher
Engineer:
[x1] shotgun
[x1] autocannon turret
[x1] plasteel mini-turret
Medic:
[x1] revive serum
[x18] medicine (x18)
[x1] vitals monitor
Heavy:
[x1] minigun
Demoman:
[x1] frag grenade
[x1] plasteel longsword
[x60] beer (x60)
Spy:
[x1] revolver
[x1] knife
Miscellaneous:
[x1] ground penetrating scanner
[x1] deep drill
[x18] packaged survival meal
Alongside the equipment list, I also wrote some flavour text for the scenario. However, as far as what I wanted to achieve with this mod, this is as far as the scenario editor went. The next thing I needed to do was edit the nine random pawns the scenario provided into the TF2 mercenaries using the Prepare Carefully mod.
Creating custom pawns
In order to create my custom pawns I needed the mod “EdB Prepare carefully”. This mod allows the player to edit their pawns to a far deeper level than the standard RimWorld tool does. Which only really allows rolling a completely new character with randomised stats. Before this mod, I remember having to keep clicking the randomise button repeatedly until I eventually got something halfway decent. A process that honestly gets old rather quickly.
Using this mod I created a custom nine pawn preset. With each pawn having their own unique appearance, backstory, traits, health conditions, and skills. Once finished I saved this configuration locally, in a file named “TF2_crew.pcp”. It saved as a custom XML file that was suffixed with “.pcp”, which I assume stands for “Prepare Carefully Preset”.
And that’s it. That is all that there is to the process. Easily really. Although I must say that: it actually took me several hours to get all nine pawns’ various stats just so. This is because I can be a rather pedantic perfectionist when it comes to the little (read: insignificant) details. Things like which eye is the Demoman missing (left), and whether I should give him a peg (left) leg or not.
That’s not even to mention assigning each pawn’s skills, since they absolutely have to be (in my mind) representative of the character. This was then exacerbated by the fact that I also tried (and mostly failed) to balance the pawns in terms of usefulness and general colony value. That is, as well as retaining each character’s unique flavour; like Pyro’s oddness, or Demoman’s alcoholism. Needless to say it took some time to settle on such things.
This balance of priorities, often working against each other ended with a reasonable compromise in the final version. At least I think so. Still, I learned that Engineer and Medic are by far the most useful pawns in application, and that if you allow the other pawns to drink Demoman’s beer, causing you to completely run out by day four … well let’s just say that I nearly put a bullet in him myself, after his third low mood tantrum due to the alcohol withdrawal debuff coupled with his natural pessimism.
Scenario narrative and expected gameplay
Explaining the narrative premise
Yes, there is indeed a story here. There is reason for these guys to be on an extraterrestrial planet 3000 years in the future. The story is rather simple. 3000ish years ago, after exhausting the Earth’s supply of Australium: TF Industries decided to look for it on other planets.
So they built a fleet of Mann Co. brand low cost space rockets. A thousand of them. Each rocket containing 9 cryogenic life support pods designed to keep it’s occupant in a state of suspended animation. The occupants naturally being clones of the mercenaries. Cheap, useful, and expendable. These clones were then shot into space with the mission to survey any planets that they land on for Australium.
That is if they actually make it to one. And after three thousand years of drifting in space, and against all odds: one rocket managed to actually make it to a habitable planet. It also somehow manages to deposit it’s cargo of crypto-sick mercenaries and their gear; just in time to avoid catching them in the fires of it violently exploding in the planets atmosphere.
Now these mercenaries find themselves on a hostile planet with minimal supplies other than guns. And with no direction other than a 3000 year old order to survey the planet for a rare resource.
Just for the sake of clarity, I should mention that the resource Australium is not implemented within this mod. It is purely a narrative plot device. Funnily enough, implementing an extra resource like this is exactly the type of feature creep I mentioned earlier that end up killing my projects. Its a rabbit-hole that I don’t want to go down, nor need to go down as I simply want to bang out a small mod that consists of a custom scenario and character roster. That’s it.
I designed this setup for a combat heavy game. Since the player only starts with 18 meals (enough to feed a team of nine for about a day), no money for trade, no animals, and only a little medicine – it incentivises more aggressive actions in order to survive the early game. Especially at higher difficulties and challenging world conditions. Keyword: “incentivise”, not force.
The players are encouraged to strip the map of resources early. Steel, components, herbal medicine, berries, as well as deconstructing buildings for their materials, and attacking the ancient danger room much earlier than usual. This is because they don’t have the time to build up resources normally; by for example farming and stone cutting blocks. The nine pawns will just eat too much in the mean time.
Additionally the fact that every pawn also has the “psychopath” trait means that many of the drawbacks to bloody play-styles are removed. Such as emotional debuffs due to executing prisoners, butchering humans, or harvesting organs.
All of the above factors leaving early bloody aggression as a very viable and deeply incentivised play-style. Basically, I designed the TF mercenaries to play like the TF mercenaries. In other words: a hostile invasive violent paramilitary force, and not an agrarian farming community. Thank you very much.
Having said all of this good stuff, I should also parenthesis it with this final sentiment. Don’t feel like you have to to play these characters out in the way that I designed them. Feel absolutely free to tinker with them however which way you wish. Is Demoman’s alcoholism annoying you? Remove it. Don’t like how slow Heavy is? remove the Slowpoke trait from him. Pyro burning down your cornfield in the middle of the night for no reason? You get the message. Although I designed things in a way I personally find compelling; it’s your game at the end of the day. Play it your way™
Technical issues explained
RimWorld UI and editing XML files directly
Although creating a scenario using the in-game menus is simple enough, the cumbersome basic user interface for this can get rather frustrating rather quickly; because of this I quickly made an initial save of the scenario with all the basic fields and variables populated. This is in order for the RimWorld binary to create an XML file for the scenario. A file that I then chose to edit directly with a text editor.
I find that editing XML files in this way with a text editor to be a preferential experience, to fiddling with the game’s user interface. For example if I wanted to reorder a list of items, by taking the bottom item to the top of the list or vice versa: using a text editor it is as simple as cutting and pasting the textual data set into it’s desired place.
Whereas doing this within the game requires one to to click on either the up or down arrow button in order to make the list item move a singular place; by swapping positions with it’s respective neighbour. I should also mention that when the item swaps position with it’s neighbour, the list item itself moves on-screen and not the list items around it. This means that you can’t just keep smashing the arrow button to skip several places quickly; because the button moves from under your mouse once clicked. Imagine wanting to order a list alphabetically and then having to do something like that for every item on a 30 item list. Tedious. You’ll have to essentially manually bubble sort the entire list.
Using a text editor to bypass this went fine for the most part. I was able to reorder the populated list of equipment easily enough, as well as change item quantity and material (when applicable). I did however reach a sticking point here. After several edits I found that the RimWorld binary no longer recognised the scenario file. Something within the file was breaking the program’s ability to read data from it.
Naturally I thought that it was a syntax error. Maybe I forgot a character of syntactic punctuation somewhere, or forgot to enclose an XML data set properly with their data syntax. No. After much double checking for errors; followed by more back and forth: changing one thing at a time within the file, then rebooting the RimWorld game to test if it now recognises it. Well after that process, it turned out that adding comments to the data set broke the RimWorld binary’s ability to read the file. Just for clarity when I say comments I mean fully syntactically correct XML comments.
Example:
<!-- this is my comment -->
I can only conclude that the XML interpreter within the RimWorld binary for whatever reason does not have the functionality to understand comments and skip them. At least when specifically talking about reading data from either files that it originally generated or from scenario files in general (.RSC file format).
After a little additional testing: apparently I may put comments in and have it still load but only if it is not within the <parts>…</parts> section and in between list items <li>data</li>. In other words as long as the comments aren’t in the only useful place to have them, in order to meaningfully separate a run on list of items into recognisable categories.
I’m guessing that the RimWorld interpreter probably has a very rigidly structured read protocol; and why shouldn’t it, since it is only expecting to read files it itself created. Please note that I am not an expert on XML nor the interpreter RimWorld is using, I just can’t help speculating when I observe such behaviours.
Honestly it much doesn’t matter anyway, I only mention my experience here in the case that you choose to add comments to your code base, and then it suddenly stops working despite having no syntax errors. I hope to save you some time needlessly troubleshooting and head scratching.
Text-field character limits
The RimWorld Scenario editor has an upper limit to the number of characters each text-field box can contain. (As of version 1.3.3117). I first realised this when my initial draft of the scenario description did not fit into the intended text-field box when pasted into RimWorld. What followed was a tedious process of trimming my sentences (narrative) until it finally fit.
To save you having to do the same, I decided to get the character limits of each text box. The process that I used was by inputting the character ‘0’ into each text field until full. Then CTRL+A, CTRL+C, and CTRL+V into an empty text file. I then used Xed text editor’s built-in tool that counts words and characters to get these results.
Text-field character counts:
Title: 55 Summary: 300 Description: 1,000 Game start dialogue: 20,000+*
*doesn’t seem to have a fixed upper limit (possible dynamic text-field)
I spent quite a bit of time going back and forth between the scenario editor and the equipment section of the Prepare Carefully mod; as I wanted to make uniform both lists. Even though technically only the Prepare Carefully equipment list actually matters from a gameplay perspective since that is the one that overrules the scenario’s list and actually makes it’s way to the game. I still wanted both lists to be the same since the scenario list is the first one the player sees, and consequently informs them of what to expect.
I should mention that the reason why the two lists of equipment weren’t always identical is because as I edited the pawns, and looked through the (quite frankly better) Prepare mod’s equipment chooser: I got motivated to give and take equipment. For example I added the Auto-cannon to the list rather late, as only once seeing it’s graphic in the mod’s loadout section: did I get inspired to use it as a surrogate for the Engineer’s big turret.
In order to avoid this tedious back and forth editing, I would recommend that you plan ahead and write down the complete equipment list before initially creating a custom scenario. Alternatively, don’t worry about the scenario editors equipment list at all while making the custom pawn presets. Instead circle back to it at the end and essentially paste in the equipment list from Prepare Carefully.
Instructions for running this scenario (GNU Linux)
1) firstly make sure you have the mod “EdB Prepare Carefully” installed 2) download the file archive here: “rimworld_tf2_scenario.ZIP” 3) unzip the file archive 4) move/copy the file “TF Industries Australium survey force.rsc” to “~/.config/unity3d/Ludeon Studios/RimWorld by Ludeon Studios/Scenarios” 5) move/copy the file “TF2_crew.pcp” to “~/.config/unity3d/Ludeon Studios/RimWorld by Ludeon Studios/PrepareCarefully” 6) boot the game, it should show up as a custom scenario 7) choose it, then click on the “prepare carefully” menu button 8) click the “Load Preset” button and choose “TF2_crew” 9) edit the pawns to taste 10) start game
Note: Windows and Mac instructions are basically the same but with some variation around the location of the RimWorld data directory.
Closing thoughts
Simple one this time round. Like I said I wanted to complete something small in a timely manner, just to dip my toe into the waters of modding RimWorld. I hope you enjoy playing with this mod as much as I did. Hmm, is this thing even technically a mod? Does it matter? I guess not.
Funny. It actually took me longer to do this write up, then it did to create the actual thing that it is about. I guess that’s not that odd, considering the fact that explaining things properly can take it’s time. Especially with my signature caveats and addendums … and waffling.
I hope this article motivates you to at least try out getting into modding games, if you aren’t doing it already. Never be afraid to start something new. But start small. Start with something that can be completed within a timely fashion and with your current skillset. Then iteratively add complexity with each later thing that you complete.
I know this is rich coming from me, but remember that “perfect is the enemy of done”; and that there’s nothing more motivational than finishing something that you set out to do. It’s better to complete 100% of something small, than 66.6% of something big. One can be released out there for people to enjoy, whilst the latter is rotting in your “ongoing_projects” folder. Or maybe that’s just me.
#0030: Game review: Princess Remedy In a World of Hurt
Preamble
I wanted to feature this game here as I think it is rather interesting, and I have a few comments I’d like to make about it. The game is called “Princess Remedy In a World of Hurt”. It is a bullet hell game created for the PC platform. However interestingly, it was made with the design limitations of a game targeted for the Nintendo Game Boy Color portable games console; as least it appears that way superficially. This article will feature a review and discussion of the game as well as a play-through or two to demonstrate the gameplay, visuals, sounds, and general game mechanics on offer.
Screenshots
Pixel art samples
Sprite size: 16×16 pixels
Grid cell size: 16×16 pixels
Grid size: 10×8 cells
Status bar size: 160×12 pixels
Game Review
Before I begin it is important to get a bit of context on the circumstances of this game’s creation. According to the read-me file that I found within the Steam version of this game’s directory (‘remedy.txt’): ‘Princess Remedy In a World of Hurt’ was originally created in 2014 during a livestreamed four day charity game jam by a group of four people. This initial completion constituted their version 1.0.
Although this version lacked certain additional features present in the latest 1.5 version that I have played. Features such as: gamepad support, options menu, multiple difficulties, and additional endings. The version 1.0: although undoubtedly rough – established a set scope of gameplay mechanics, narrative, and player experience; that was then subsequently refined and improved upon.
With the exception of the ‘Jealous Chest’ mechanic and extra endings: the additional refinements were mostly quality of life features, and in my opinion do not necessarily constitute raw additional game content. Like a new area, or new enemies would for example. As such the final version still feels like a game that could arguably be created within a short amount of time.
I only mention the game’s humble origins because it is apparent by the restricted scope of mechanics present, story, and short playtime: that not much in terms of resources actually went into the game’s creation. By resources I mean time taken to either plan a deeper narrative, create additional gameplay mechanics, or create more materials (i.e. media like image sprites and sound effects). Add to that the necessary programming time taken to implement and test every additional element.
Although it may come across as a criticism, I do not mean it as such. Rather it is by virtue of it’s spartan nature that I am attracted to this game to begin with. I wish to emulate it in my own way, and create a similar title as a practice game for a larger project I have in mind. Also I rather like the minimalist approach to game design presented here, a design that discards all but the essential components needed for a viable gameplay loop. As a hobbyist game designer who has discarded games mid-development due to feature creep (and the frustration that it incurs): I actually admire an approach that respects the limitations of available resources and deadlines, and operates with a more prosaic ‘get it done’ attitude as a consequence of that.
Now onto the game itself. The core gameplay experience consists of walking around and exploring a classic 2D RPG world like the one of ‘Final Fantasy I’ (FFI). Here you find people to talk to, to then enter a battle instance with. This battle instance consists of a unique bullet hell mini-game; as every NPC has their own custom setup of enemies and terrain layout to contend with. Winning these battles provides rewards that come in the form of a stat boost called ‘Hearts’. Hearts are the most important stat booster in the game. This is because in addition to marginally boosting the characters health (or hit) points, a set number of them are also needed to open the specific gates that lead to other map areas, and thus progress the game.
The game has a simple and concise gameplay loop. It may superficially look like a classic RPG title such as FFI, however all the extraneous RPG mechanics from a game like FFI are not present here. There are no items (beyond gate-keys), status effects, nor any character abilities, or levelling. There is however a basic system of stat progression that involves collecting stat tokens.
The full list of stat tokens include: the aforementioned ‘Hearts’ which marginally improve HP, ‘Power’ which increases shot damage, ‘Multi’ which increases the number of shots fired at a time, ‘Regen’ which increases the HP regeneration rate, and finally ‘Flasks’, which increases the number of uses of the special attack action during combat. In addition to Hearts, all of the other stat boosts are exclusively found in chests dotted around the various towns and caves.
The actual game world itself consists of a simple world map, which links together a series of higher fidelity maps. These higher fidelity maps primarily come in two forms: towns and caves, but also includes a few castles, a pond, and several other unique areas. The world map only contains heart-gates and key-gates. It is the higher fidelity maps that contain all other interact-able objects. These come in two formats: NPCs and chests. Each NPC only offers a quick dialogue on interaction. This dialogue either contains game hints, or instigates that specific NPC’s bullet hell mini-game. Whereas the chests contain either stat upgrades, or keys for opening shortcuts.
I should mention that the higher fidelity maps also contain a puzzle element. Some chests are set up in a way to resemble secrets from other visually similar RPG games. Specifically, in order to get to them they require the player to walk off of the displayed tile area, by passing through normally impassible terrain tiles (like walls): into the black space in and around the map that traditionally denote impassable terrain. Links to secret paths like this are marked by a slight imperfection on the terrain tile that connects to them. Thus marking it as passible terrain.
That’s it. That’s the game. Talk to people, then win the bullet hell battles they offer to get hearts; find chests, get stats, and more hearts; then open the heart-gate to get to the next area. Rinse and repeat until you get to the final boss. Where you play an extended bullet hell battle. Done.
Screenshots from Princess Remedy
Screenshots from Final Fantasy I
The only real deviation from this formula that this game offers is via the ‘Jealous chest’ mechanic. Within an advanced area of the game – one that is gated by three separate heart-gates, and hidden within the town map there: exists the Jealous chest. This is a special chest that will give the player a shot power boost, but only if the player has not opened any other chests before it. Meaning that in order to acquire that shot boost, the player will have to win (nearly) every battle up to that point in the game without any of the stat boosts that the other chests offer.
This challenge adds significant difficulty to game and I personally found it rather engaging. However there is a down side to this. The problem comes in when you actually get the Jealous chest. Shortly after opening the chest and getting the extra power boost contained within, the player gets the contents of all the normal chests in previous areas, even the ones hidden by secret passageways that may otherwise be missed.
This gives the player a very sudden and dramatic power boost. Which on one hand feels great, due to the fact that up until this point the player has been surviving the battles with mere base stats. ‘Surviving’ being the operative word here for the experience. Then all of a sudden you gain all the stat boosters from three zones, giving you the power to nuke previously troublesome enemies like the Ghosts.
The problem with this sudden dramatic power gain is that it causes an inversely dramatic drop off in game difficulty. Even though technically the enemies fought in the later game after this point are stronger than the previous enemies, the same level of planning and skill required to survive up to this point and win battles is no longer necessary due to the raw power output the player now has.
This phenomenon causes the player to experience a significant spike in difficulty in the mid game levels just before acquiring the Jealous chest. Which is then not surpassed by any of the other following levels, including the final boss fight. This is due to the smaller disparity of power between the enemies and the player. In other words once you get the Jealous chest, you can essentially coast the rest of the game, even though you’ll technically be fighting stronger enemies. It will not feel like it.
Luckily the Jealous chest is an add-on mechanic, and is only really necessary if you wish to get the full 101% completion rate. If you don’t care about that, then you’ll likely experience a far more gradual and balanced difficulty curve as you progress through the game the normal way: haphazardly collecting (and missing) chests as you go.
Moving on. As for the bullet hell battles themselves, they are also very simple. They consist of manoeuvring an auto-firing character around, and occasionally using the catch-all action button to throw a flask; which functions as a grenade: doing AOE damage across a three-by-three (nine square) grid. The standard shots fire automatically from the character as is standard fare in bullet hell games.
What isn’t standard is the fact that the character can change which direction she is facing; meaning that in Princess Remedy you can fire in all four directions. This is due to this game taking place in a sandboxed square area. Unlike more traditional arcade shooter bullet-hell games, which tend to play out within either a vertical or horizontal scrolling stage. In which the player character’s firing direction is fixed to face in the direction that the stage scrolls into frame from. As that’s where the enemies are coming from. The most typical example of this, is that of a spaceship themed vertical arcade-style scroller like ‘Ikaruga’.
Ikaruga Steam trailer
The enemies in this game are rather varied. There is a mixed bag of enemies with differing movement patterns, health points, and who emit different shot types, in different numbers and frequencies from each other. There are enemies such as the Spike-ball which just moves towards the player when within it’s line-of-sight, as well as the Ghost which follows the player whilst also intermittently disappearing and shooting a terrain piercing shot toward the player. There are a handful of iterative enemies like this Ghost, i.e. harder versions of previous enemies. They utilize the behaviour patterns of the previous lower tier enemy, but then with a little extra mechanic added on.
I should also note that enemy behaviour actually changes across the difficulty levels. To me it is always a pleasant surprise when the actual enemy AI is tweaked to be more difficult on harder levels. In my experience playing video-games in general: it is far more common to see developers simply tweak stats like shot damage and hit points, then call it a day. All whilst maintaining the exact same enemy patterns of behaviour. This game probably does buff the stats of enemies in the harder modes, although I haven’t played enough to verify enough to the point that I could confidently state so here. Its not important either way. What is important is the fact that the enemy AI is tweaked and geared for the difficulty.
An example of this would be with Bat enemies. Bats are enemies that move in a random direction at a set time interval. They damage the player by colliding with it. In normal mode when a Bat dies, it simply dies. In hard mode, Bats shoot out three regular bullets in the direction of the player upon death, and in master mode the Bats move considerably faster whist also doing everything from the lower difficulties.
Moving on, now let’s discuss the more technical specifications of this title. This game was made using the Game Maker engine and targeted the PC platform. However more interestingly the game was visually designed to imitate a Game Boy Color game. It has the same resolution as GBC games (160×140 pixels), as well as similar colour pallets, and sprite types (8-bit era 16×16 pixel sprites).
It also uses a severely limited range of player inputs for interacting with the game. Although it maps multiple buttons/keys to each input type. For example the ‘action’ input is mapped to multiple keys including Enter and Spacebar. This is where my first real criticism of the game comes in. The ‘action’ key, the in-game results of pressing this key are highly contextual.
If pressed next to an NPC, it will engage them in dialogue; if pressed whilst moving, the player character will start running in the same direction; and if pressed whilst stationary and not facing an adjacent NPC, it’ll pop up the menu screen. Needless to say it has caused me to misclick a couple of times. Mostly by throwing up a menu when I intended to run. But that could just as easily be an issue with me and my keyboard. Although I found this catch-all action key to be a rather clunky method of input, it is ultimately a relatively trivial matter.
The main thing that I have encountered within this game that is actually worthy of criticism is it’s pixel scaling methods. At higher resolutions than the base times one (‘x1’) or 160×140 pixel screen size, it looks absolutely awful. The sharp clean pixels at the base size get blurry even at the times two (320×280) screen size.
Honestly, I am not sure about the technology being used here to resize the window and rescale the display assets within it. If I were to guess, I’d say that it is the functionality of one of Game Makers image manipulation libraries. Judging from what I can observe: I assume the image is actually being scaled using a form of on-the-fly interpolation. Such as linear or cubic interpolation.
Essentially algorithms (used within this application that are) designed to guess at what colour the pixels should be within the newly created empty regions, between the separated pixels of an upscaled image. Unfortunately, they do not have the context that they are dealing with a pixel art that requires clean lines, and consequently blurs edges in a bid to establish some kind of smooth colour gradient. At least that’s my guess as to what is going on here.
I think the window and asset scaling in this game was something of an after-thought honestly. Especially since the ‘options’ menu containing it was introduced to the game in it’s 1.1 patch. After the conclusion of the game jam. Meaning that the 1.0 game jam version was only made with the fixed Game Boy Color screen size in mind, and with all assets specifically scaled for it.
Only afterwards did the programmer who is maintaining the game decide to add additional resolutions. Unfortunately they did not recreate the art assets to be more scalable. For example by using large images designed for a modern full-screen display (e.g. 1920×1080) then scaling them down.
Although this has it’s own issues such as image artifacts being created by aggressively compressing image dimensions. However in my opinion, a little artifacting is considerably more palatable then the horrendous blurring incurred by the current solution of upscaling tiny images to large resolutions. This is most comically apparent when in full-screen mode. Imagine what happens when you upscale (essentially stretch) a screen with a height of 140 pixels to 1080 pixels. Needless to say it is virtually unplayable.
Now upon hearing this, you may think to yourself: why don’t they do that? I mean it won’t take long to use an image manipulation software (like GIMP) to upscale each image asset by raw pixel doubling; and without introducing blurring via interpolation techniques. Well, another reason why the current maintainer of this may not want to use upscaled images may include the related image code itself.
Considering that this game was initially made in a span of four days for a competition, then things like proper planning and future proofing of code goes out the window. It it very likely that this game has been hardcoded with strong references to the current image dimensions throughout the codebase. If so it will also explain this slapdash box-ticking approach to getting higher resolutions, as it likely avoids having to deal with the technical debt incurred by hard coding the image dimensions into the game logic in this manner.
What do I mean by this? Let me illustrate the problem here: imagine if you had a line of code that moved the Bat enemy for example. This enemy moves every other time tick in a random direction the full length of it’s size (16 pixels). Assuming that the code for this is hardcoded (i.e. code containing asset dimensions, or verbose inflexible instruction sets). Then the code for moving the Bat across the vertical axis may look something like: ‘moveBatY(){bat.posY+=16; updateSpritePos();}’.
Now, let’s say you want this game to also work at a times two scale (or at 320×280) resolution. This instruction set will have to be modified to allow the bat to move it’s full length. Which is now 32 pixels and not 16. If the code is left as is, then the Bat will no longer function as intended/expected. This is a form of technical debt, i.e. creating your codebase in way that will require reformatting/rewriting before significant additions can be made to the feature set; by in this case adding additional game resolutions. And considering the volume of image interactions going on in this game, likely having to reformat the entire codebase will not be a trivial matter. After a basic cost-benefit analysis, the programmer here probably deemed it not worth pursing at the time. Instead opting for the sub-optimal (yet viable) solution that is currently implemented.
Resolution scaling screenshots
open image in a new tab to see fullsize
Manually scaled examples
X1 (game)
X2 (game)
X2 (GIMP)
X4 (game)
X4 (GIMP)
I’d like to leave this review on a positive note. As I was doing a final check after writing this review I found out that the main developer, namely Remar has very recently updated this game. The latest version at the time of writing is 1.6; however this version (at lest currently) is only available on Remar’s personal website. The update included a few things: most notably a dedicated run button. Which addressed some of my criticisms I had made prior. So discount those if you play version 1.6.
The real cool thing about this situation is that you have a developer here who decides to update a now 6-7 year old game; that they made available to the public for free. That’s a developer that cares about their craft, and cares about their legacy. At least I’d like to think so, I mean they sure as shit aren’t making any money off of it. And as a guy who is currently trying to port his old garbage flash games to HTML5 – love for the craft and posterity is the only real reason I can see for a person to go out of their way and tweak/improve something like this.
If you want to play ‘Princess Remedy In a World of hurt’ it is available on the Steam PC platform and also on the Developer’s personal website with no Steam DRM. Download link: ‘https://remar.se/daniel/remedy.php’. It is a free game so give it try. If you really like it you may even want to purchase it’s paid sequel: ‘Princess Remedy In a Heap of trouble’.
Video Play-throughs
Difficulty: NORMAL
Completion: 101% (jealous chest run)
Time: 42 minutes 5 seconds
Game version: 1.5 (Steam)
Difficulty: HARD
Completion: 101% (jealous chest run)
Time: 52 minutes 41 seconds
game version: 1.5 (Steam)
Game credits
Game copyright Remar Games and Ludosity 2014 Design, script, code, SFX edit: Daniel Remar Design, graphics: Anton Nilsson Music, SFX: Mattias Hakulinen Final boss songs: Stefan Hurtig
Nintendo Game Boy Color reference images
image taken from wikipedia.org
image taken from nintendo.co.uk
image taken from nintendo.co.uk
Closing thoughts
This is the first actual game review that I have done on this site. I hope that it proved to be insightful and useful to you. Whether you wish to simply play the game (and you really should as its free on Steam), or whether you are simply interested in a hearing about a game’s systems and the interplay of mechanics within it. I hope that I at least entertained you if nothing else.
The main reason why I covered this particular game is because I intend to create a clone of this title. I like the very limited nature of it, and genuinely think that I could make a copy in order to sharpen my skill-set. I needed a small but genuine gaming project to try out my tools, and to practice my pixel art and music creation. So look out for that game when it is out. I’ll pop a link here for it when available.
It’s sort of funny when when certain coincidences happen, and one gets that feeling of living in a small world. The name ‘Ludosity’ came up a couple off times while I was reading up on this game. I just thought ‘huh, that rings a bell’ and moved on. Its only once the review was almost finished and I decided to actually visit the website links within the readme files, did I find out who it was. They were the people that made ‘Card City Nights’, a game that I really enjoyed years ago. I even 100% the game, blue Steam ribbon in all. I remember it was also a game of limited scope, being just a series of card battles attached to something almost akin to a visual novel, with a simple collectable card game or deck builder core. It also had a simple but very compelling gameplay loop, and lovely art…
On that final nostalgic note, I’d like to say:
Thanks for reading.
Glossary of terms
2D – 2 Dimensional AI – Artificial Intelligence. Although in this context it doesn’t refer to real AI, but rather patterns of situational behaviour that non-player controlled entities engage in or act out.
AOE – Area of Effect. NPC – Non Playable Character RPG – Role Playing Game Sprite – Simple low resolution image of an entity. E.g. NPC.
#0029: Dev-blog #001: plans and preparations (‘Remote PI’)
Preamble
I wanted to create something of a diary to collate my thoughts, experiences, and general progression towards completing a large multimedia project. One with a significantly wider time-scale and scope of disciplines than I am accustomed to. It will be a multi-session project that will require several months to assemble the knowledge and materials, necessary to ultimately produce a playable video game demo. The working title for this project will be “Remote PI” or “R-PI” for short. Not to be confused with “RPi” (Raspberry Pi).
This project will require creating a proof of concept video game demo as a solo developer. By ‘proof of concept’, I mean a vertical slice of gameplay that will feature all the core gameplay mechanics layered atop each other in a cogent manner to form a functional and hopefully compelling system. The demo will also require thematic art and music, as well as featuring a narrative hook designed to entice players to support the production of the full game.
Essentially I plan on documenting the creation of a playable teaser trailer here. In addition to writing about the development of the demo itself, I will also document my personal relevant skill progression. Since this project will require me to become practiced at all the disciplines that are needed, for realising an interactive multimedia product like a game; I will need to acquire passable skill in art, music, as well as brush up on my general programming fundamentals. During this process I will no doubt have to also learn a few new tools (IDEs, programming languages, etcetera); and that’s not even to mention the more mundane skill-sets like script writing, project organisation, and time management.
This series of post entries will journal my progress in this endeavour.
My current skill-set (or lack thereof)
Before we go on I think it’s best that I identify to you where I am currently with regards to my skill-set. This is in order to understand what I need to work on to realise this vision. At the time of writing this (2021), I have been a hobbyist programmer for a few years now (since 2013-14 I believe). Being a hobbyist I have pursued programming for pleasure primarily.
This however meant that I was largely unguided and unfocused with regards to what I learned and how. This resulted in the collection a more shallow and eclectic experience base, rather than a more guided and structured one (i.e. comprehensive and useful), like the kinds associated with formal education. More aptly it also dictated how long I stuck with things after the initial fun dries up and the laborious hard-work begins. But that’s a more personal failing of mine. I can’t blame the books that I bought, for me not reading them. I mean most of them had pictures and everything.
Anyway, I started with making short text adventures in an IDE called Bloodshed Dev-C++ using the C++ language. On a technical inspection: these games could be boiled down to basically a series of if/else statements, with their function calls nested within another series of if/else statements. If I got fancy, I might even throw in a switch statement here or there. The only one I remember completing and being proud of was called “A little after midnight”.
It’s most notable feature was that it had a rudimentary inventory system that simply fed into the cascade of if/else statements that constituted that game. I vaguely remember codifying the handful of items in the game as individual boolean variables. Example use-case: “if (isGotKey == true) open_door(); else locked_door_dialogue();”, or something to that effect. Like I said it was primitive.
At the time: I remember just wanting to create a game, any game, and have it work. I liked “choose your own adventure” books like “Island of the lizard king” by Ian Livingstone, and the various MSDOS text adventures that I played as a child, all who’s names unfortunately escape me right now; and simply wanted to have a go.
After wetting my feet with text adventures, I transitioned to making flash games using the ECMAscript derivative language Action Script 3. This was on the FlashDevelop IDE. In this time of approximately 3 years I only managed to complete two games. Keyword: ‘complete’. A basic 20 level platformer with godawful hit-detection called “Runaway Units”, and a single room point-and-click adventure called “Last Life: The Blue Key”. In both games I was helped by my friend Kross Drayllih who created the music to Runaway Units and did the majority of the art and all the music for Last Life. However, I did the artwork for the user interface for that game. This will be relevant when I discuss the pixel art of this demo later.
Around this time I started dabbling with modding games. I created a few JSON mods for a community driven game called Cataclysm: Dark Days Ahead. Notables include: a mod that gives early game access to mutagens via (IIRC) an XCOM-esque gene-therapy clinic building, and a more general extra buildings mod called “OA’s additional buildings”. The later of the two mods even got folded into the main game. If you ever find a sex shop, internet cafe, walled park, cruise ship, or ranger’s lookout: well, that might be my work you’re exploring. In addition to CDDA I also created a few simple ship mods for a space logistics game called Endless Space.
After this I fell out of love with making games, and moved onto playing with mini-PCs and microcontrollers. Namely, Raspberry Pis and (clone) Arduino boards. I wanted to make robots. With these I was introduced to Linux based operating systems, specifically Rasbian. Which I accessed remotely over WIFI (via secure shell protocol) using a program named Putty on my Windows 7 machine.
I remember using bash as a remotely accessible text user interface to run custom bash scripts and programs written in Python 2. These programs were for controlling the RPi’s GPIO (general purpose input output) pins. Which in turn controlled peripheral components like sensors, lights, relays, and motors. These programs were very utilitarian in nature and simple, as they were merely concerned with converting button presses into signal outputs, or interpreting signal inputs from the sensory peripherals and converting them into a textual output for the console. The RPI’s GPIO library was the one who really did the heavy lifting there. Similar story with the Arduino IDE. My instruction sets where pretty basic there too.
As you probably have put together, I am just a hobbyist programmer. I’ve read a few books, did a few online courses, and played around with a few tools; including everything from complete development environments like the Unity engine, to simple graphics libraries like SMFL, SDL, and Allegro. But never to a serious extent. I also have more general knowledge about programming. For example: programming paradigms like functional programming, versus procedural programming, versus object orientated programming. But since all of my projects have either been small enough that I didn’t really need to research proper code organisation for creating a maintainable codebase, or that the project was so large that it has been abandoned for other reasons before necessitating an ordered big-picture view approach to coding.
As I am now, I am even rusty at the basic programming level I once had. This is due to my interests moving on once again. I’m not sure when exactly it happened, but as I started working and acquiring money: my interests gradually drifted towards the hardware side. As I am now I am more versed in repairing devices like power-supplies and old games consoles, than I am programming using a graphics library like SDL2 (Simple Direct-media Layer), in order to do something simple like create a window and render an image onto it.
You might have also sussed out from it’s absence of mention in the above summary, that I am not an artist. Although I have dabbled with some watercolours during my poetry writing teenage phase. I even had a Deviant-art account (“night-eater”) that I used to host the handful of halfway decent things that I did managed to create at the time. But it didn’t stick. As for music, as I am writing this I don’t even understand basic music theory. For example what the notes mean: like A# or B flat. No idea. It’s embarrassing to write this down but it is also the truth.
And that’s my starting point here. A rusty ass second-rate programmer, who can barely art, and can’t music. Still though I think that this project is within my projected ability to complete. It’s like that chess adage: “the only way to get better, is by playing a better opponent”. The same I think it is with creating and refining a skill-set. It needs a specific objective or challenge to be measured against. Otherwise its easy to just end up drifting around aimlessly without ever feeling the need to work hard and develop the skills that have been acquired, at least not to a point where they can bare tangible fruit.
I know I said otherwise in the preamble above, however I do think that the scope of this project is actually relatively small (compared to what it could be). It’s just a short demo; and whose music and art only need to be functional, they don’t need to be masterpieces. Still, lets not risk falling for the Dunning-Kruger effect and underestimating the energy and time taken to develop the relevant skills. That’s a lesson I learned the hard way when making LL:TBK, where everything took three times as long to get done as initially predicted. All in all though, I do think this is doable for me.
Game Outline
Without any further ado lets outline the game that this demo will come from. Please note I will go into much further detail on the game’s mechanical substance during it’s dedicated article. This is just the declaration of the initial parameters that I wish to work within.
Game Specifications:
Working title: “Remote PI” Genre (mechanics): (primary) point-and-click adventure, (secondary) hacking simulator Additional mechanics: puzzle mini-games, rouge-like (permadeath and multi-run unlocks), survival (resource management) Genre (narrative): detective thriller Art style: medium-low resolution pixel art Music: low key techno synths (i.e “electronic music”), or something closer to chip-tunes Playtime (demo version): approximately 15-30 minutes Playtime (full version): around 1 hour per complete run Technology (for game): C++ and SDL2 using Code::Blocks IDE Technology (for demo): HTML, CSS, JS, and a simple text editor like Xed Target platform (game): personal computer (Windows, Linux, Mac) Target platform (demo): web browsers (specifically my website)
Synopsis:
Remote PI is a game in which you play as a private investigator working in a particularly seedy part of (an alternate history) London in 1999. It will have a gig type gameplay loop where the player is offered several cases via email. These discrete cases are then shown to contain an over arching narrative. One that escalates the stakes by tying the the jobs to a central story about national security.
Thoughts on game ideas
You may be wondering why I am just listing out my game’s premise here for something that one day I’d very much like to turn into a real commercial product and sell? Why I am revealing how this sausage is going to be made, secret family recipe in all? Well its because I don’t value ideas (and thus “idea guys”) very highly. They’re not something to be jealously guarded like a dragon on a pile of gold (at least not at this level). I mean I’d be willing to bet that you reading this could probably come up with a better idea for a video game. For example: Pacman but sexy. Boom! Million dollar idea right there. You just thought up Ms Pacman. Genius.
The idea of a detective noir, point-and-click/hacking-sim thriller that is set in late 90’s London is not unique or special. It’s just a disparate amalgamation of various things I like (and am familiar with) that I think will work well together. It’s the execution of the plan that dictates whether or not this product will be worth anyone’s time. Not the premise and promise provided by a “good idea”.
Thoughts on developer teams
You may have been wondering why I don’t team up with other people for these types of larger projects? I mean many hands make light work, after all. Well, in my opinion its more often than not the opposite case of too many chefs spoiling the broth.
This is especially true in cases such as where a group of friends decide to work together. Typically having vague workload expectations, job roles, schedules, and naturally differing creative visions for the final product. In such situations, I expect people to essentially waste their time and energy before the inevitable fruitless dissolution of the project. Also likely with some hurt feelings incurred in the process.
To give you a more personal and direct answer: I simply don’t like working with others on creative endeavours like video games. Especially in smaller more intimate teams, where each individual has significant influence when it comes to whether or not the project is ever actually completed. The idea of expending myself: pouring serious time and energy into a project, only for it to still fail to finish due to someone else, either not pulling their weight or spitefully sabotaging it for some interpersonal gripe — actually genuinely frightens me. This is because It’d leave me in a situation where I can’t get that time back, and I’d also have nothing to show for it.
In the case of shared revenue projects (i.e. a project where money only comes in after it is completed, if at all): people tend to start behaving oddly as the project progresses and the initial new project enthusiasm drops off. I find it is at this time that people begin to gripe about things like: creative control, division of labour, maintaining personal morale, as well as time keeping, and deadlines.
Oh and lets not forget people’s general trouble with listening to basic instructions and specifications. And quite frankly when I have worked with “creative types”, I find that I quickly can become frustrated with the development process, and risk factors associated with co-ordinating various people who say that they are invested in the completion of the project, but whose actions say otherwise. I find co-ordinating with these types of people to be a generally draining experience, closer to an exercise in herding cats than co-ordinating with professionals.
This feeling is exacerbated when these people then choose to organise themselves into flat leader-less structures. I believe this is due to the incorrect assumption that such a small group will not need a leader to organise and co-ordinate the membership, especially when they can all join the same chat group and co-ordinate that way. Like a group of friends might do for example. This type of headless group structure is generally bad unless everyone in the group genuinely holds themselves responsible for making their contributions on time and on par. Even with the absence of the downward pressure and authoritative structure a clear leader would offer.
For example: I have had experiences with creative partners who would only work on things as they feel like it. On one hand I understand creative desire and that sometimes it can dry up. However when working to deadlines it really can become frustrating, especially when they hold up the supply lines by making others wait on them for materials. And since no-one is currently paying them for their contributions, they don’t take their responsibility to the group seriously and prioritise it within the routine of their lives appropriately.
I once had a partner who decided to create a superfluous website and start writing a script for a sequel to the title we were working on at the time. This was at a time when the actual current title was about halfway done, and I was waiting on them for materials. That’s got on my nerves, and the worst part is that I had to find the nicest way to ask the person to go back to making what we actually need; rather than what the person felt like doing. I was also acutely aware of the real chance that my criticism my disenfranchise the person into quitting all together, if I happen to upset them. In which case that project is dead in the water. That tiptoeing around people’s feelings is honestly exhausting.
I could gas on about this, but it ultimately comes down to me not wanting to work with others for this type of thing. Things just have a habit of getting complicated when working on creative (and potentially commercial) endeavours with others. Who owns what and how much is also a headache of a conversation (argument) to have, especially when the group can end up fighting over scraps or (fantastical) projected earnings.
That’s as far my experience with shared revenue type deals go. I have looked at alternatives such as hiring artists and musicians. However I don’t really want to work with freelancers I meet online. I may for discrete commissions of work, such as for character profile pictures or wallpapers for a game. However I don’t really want to get into in more extended business relationship with freelances if I can avoid it. As I fear being nickel-and-dimed for every alteration or modification I may request.
I can’t say I’d blame them for having a mercenary attitude in this case either. They make their money during the development process, and strictly in exchange for their work. It’s not like I’d be willing to share revenue or copyrights of the finished game after-all. So the only way they make money is by charging for everything that they do; including time working on alterations.
Additionally, I am not in position in my life right now where I can invest the time necessary to source and vet good contractors; research contract and copyright law to the point of competency, as I want to legally own the commissioned work; and finally (and most importantly) cough of the dough to pay for all this. So its all academic at the end of the day.
Closing thoughts
As I write this I ask myself: What is the purpose of this blog? Given a moment to think – I believe it’s main purpose is as a public declaration of intent. (Not that there’s anyone actually reading this mind you.) I have had many similar projects in the past, one’s that I have quietly started, worked on for a couple of months, then just as quietly abandoned them. I always justified the abandonment with one reason or another. I am sure that at the time, they were good reasons and not just excuses. However I can not deny a certain emergent pattern of behaviour of mine: I have started many projects but only really have ever completed a small handful. And all the effort that went into those unfinished works is largely lost, not having paid me back any sort of tangible dividends.
The only exception is probably some skill building experience acquired whilst creating and prototyping new systems and mechanics. I have many unfinished games that have their core mechanics articulated to satisfaction but not fleshed out with actual game content materials. Like a functioning inventory system filled with placeholder articles, and having all it’s item population and depopulation event calls coming from one central controller function. So that I could test and trigger the events at will. (Needless to say: this event controller function is to be removed once the system is placed into an actual game, and has all it’s event calls tied to in-game trigger events.)
Additionally, I have created systems like dialogue trees, local saving and loading, and 2D weather effects. Experience modelling these mechanics does in my opinion carry over. Even when tools like engines and languages change, understanding the fundamental principals of how something like saving a game state to file works, and actually having an instance of implementing it, is valuable in my opinion. Although nothing beats the grim satisfaction of actually finishing a fucking project.
Anyhow, here’s to this thing. *downs an alcoholic beverage* burp… cheers.
#0028: Game Boy Advance SP audio/power port analysis
Preamble
This article consists of various labelled pinout diagrams. They specifically feature: the charge port, and accompanying plugs, of the Nintendo Game Boy Advance SP (GBA-SP) portable games console. These diagrams will also include annotations on various notable details regarding these pins and their functionality. Additionally I will also feature some of my personal commentary on the port in general.
It should be noted that the information gathered for these diagrams is collected first hand, without the use of any official reference materials. As such I can only discuss the functions of the various pins that I have personally identified and mapped out. Whether or not this port or any pins within have any additional functionality beyond this is unknown to me. Since I have only identified this port as being used for either power ingress, or audio output: I will henceforth reference it as the “audio/power port”.
GBA-SP
Note: I feature this image set in order to establish a basic reference for the GBA-SP: in the case that the reader is not familiar with this device. The GBA-SP only has two ports on it. These are the audio/power port (on the left of the images), and the COMMS (or communications) port (on the right). This article only features details on the audio/power port.
Notables:
The audio/power port has six pins within it. Four on the under side of the plastic support, and two above it.
The port also has a retaining spring that looks like a pin. This clip holds any inserted plugs in place. It is located between the two top pins, on the centre part of the plastic support, that juts out toward the inner wall of the socket.
GBA-SP charger and plug pinout
Notables:
There is a pinout diagram (or legend) of the charger’s plug on the charger’s plastic housing.
Despite the unique plug, the GBA-SP actually uses a very basic AC-DC power-supply that provides 5.2 volts DC @ 320mA.
5.4 VDC is the charger’s measured open circuit output voltage. I assume it drops to ~5.2V once loaded.
The output power (both voltage and ampere) is within/around the USB standard. Nintendo could have arguably used a standard mini-USB port at the time (2002) to power the device instead.
GBA-SP audio cable plug pinout
Notables:
It is keyed for stereo sound, having two different audio channels that then share a return line.
The audio ground (or return, or drain) is not electrically connected to the device ground.
When inserted, the plug shorts the audio switch pin to ground
The only pin missing from the audio plug is the pin that corresponds the device’s V+ inlet pin.
Pin: Audio channel (right): carries the positive signal for the right channel (of stereo audio).
Pin: Audio channel (left): carries the positive signal for the left channel (of stereo audio).
Audio ground: functions as a return for both the right and left audio channels.
The GND pin, as well as the metal sheath of both the audio/power port and the adjacent communication port are all electrically connected.
The Audio switch pin has a floating voltage of 0.5 volts.
To activate the Audio switch: tie it to GND.
Pin: V+ is for the 5.2 VDC input from the charger.
Testing the audio switch on the GBA-SP
control test with an audio plugtest by manually shorting the audio pin
System freeze demonstration
While I was recording the testing of the audio/power port on the GBA-SP I came across a system freeze. Initially I placed it here because I thought it might be relevant to the audio/power port in some capacity. However after I had some time to think about what might have caused this system freeze, I have come to the conclusion that in all likelihood this freeze was caused by me putting pressure on the game cartridge as I inserted the audio plug into the console.
This likely then caused the cartridge to move slightly, but enough to break continuity between it’s pads and the console’s pins. Perhaps one or more of the GBA-SP’s pins moved onto a more insulated or corroded section of the cartridge’s pad(s). A section that is insulative enough that it either blocked or damaged the signal integrity beyond interpretation.
The main reason why I think this is the case, is because the audio/power port doesn’t deal with any data outside of audio signals. Certainly nothing that could cause a system freeze in my opinion. However what has caused multiple freezes in the past is tampering with the game cartridge while it is powered and in use.
Thoughts on Nintendo’s anti-consumer product design
In the previous GBA-SP dongle article I went on something of a rant on Nintendo’s anti-consumer design with regards to this particular product. In order to avoid rehashing those same points, I’ll keep my thoughts here concise, and offer them more as an addendum to that gassy rant.
To cut to the point. Yes I still think that the removal of the 3.5mm audio jack during the design iteration from the GBA to the GBA-SP was an anti-consumer gesture. Additionally I think this unique GBA-SP plug and socket design is woefully unnecessary; at least from a technical perspective.
As far as I can tell: Nintendo simply mashed together the functionality of the generic 3.5mm audio jack, and of the standard Mini-USB connector available at the time (~2002). They blended these two standards into their own bespoke plug and socket design. A proprietary design in which they can control the availability and price of. At least for the critical time period after the public product release, where there’d be the highest demand for accessories like this. Accessories, that they could then price gouge their customers on, with no competition (i.e. no legitimate alternatives).
The reason why I believe this to be the case, is that without the motivator of maximising profits: this design decision of creating proprietary alternative designs for already existing standard open designs makes little sense. Let us consider that if instead of this (immediate) profits driven motivator, the main motivator was to create a versatile and endearing product. One that will be usable long into the future due to the sheer availability of parts, and supporting accessories. Such as USB related componentry.
If they really wanted to make the best product they could for their customers: then I believe there is little reason not to use a Mini-USB port to power the device, and a 3.5mm audio socket for sound. This is especially evident due to the fact that the Mini-USB standard could already satisfy the GBA-SP’s power requirements of 5.2 volts at 300 milliamperes. Perhaps there were some licencing issues with regards to that idea that convinced them otherwise. It may even be the relative fragility of the Mini-USB socket that convinced them not to use it. I do believe that Nintendo’s proprietary port is more rugged than the Mini-USB port. I’ll give them that. I will also say that this is also one of the few instances where a “think of the children” argument may actually have some merit. Kids are generally destructive with toys. However I doubt that was the motivator here, at least not the main one.
Closing thoughts
I wanted to create this article initially for referential purposes, if not just for the sake of completeness. Prior to this, I wrote an article on creating a GBA-SP audio cable. This prior article featured a pinout diagram of this same port’s respective plug (audio version). However this diagram only featured labels relevant to the plug’s audio cable.
I didn’t even compare this information to their counterpart pins on the GBA-SP (or the charger’s plug). This is because I did not need to in order to achieve the stated goal of creating an audio adapter. If I did compare the pins, I would’ve found out that the lower “closed loop switch” pin (as I put it): is actually the main ground pin; and that “closing the loop” actually meant pulling the 0.5 volts from the top pin to ground. Although its essentially two different ways of saying the same thing: the latter method gives a more informed picture of what is actually going on. That is all this article is really for at the end of the day: to get a better idea of how that particular port works by using first hand experimentation and some deductive reasoning.
Anyway, I hope this article proves itself useful to you.
#0027: Dominions 4: Thrones of Ascension map creation guide
Preamble
This is a quick bullet point style guide to how I create maps for IllWinter’s game: “Dominions 4: Thrones of Ascension”. Note: I will henceforth refer to the Dominions 4 game binary as “dom4”.
Map creation steps
Step 1: acquire or create a base image to use as the map.
I created an image using the GIMP image editor, and saved the multilayer project file (.xcf).
Step 2: use an image editor program to alter/create an image to conform to a standard that the dom4 executable can recognise.
Image specifics:
image must be in the Truevision TGA (.tga) or Silicon Graphics Image (.rgb) image format
minimum image size: 256×256 pixels
recommended image size: 1600×1200 pixels
image must be in 24 bit or 32 bit colour depth
image must be either uncompressed or using run-length encoded (RLE) compression
image must use a white single pixel as a province marker
white = HEX:#ffffff, RGB:(255,255,255)
Step 3: using the image editor, export a correctly formatted image.
I exported a TGA image file to specification, with a size of 256×256.
Example image file name: “tutorial_map_256x256.tga”.
Step 4: copy that image file to the dom4 working directory.
Working folder directory:
Linux: ~/.dominions4/
Mac: ~/.dominions4/
Windows: %APPDATA%\dominions4\
Step 5: boot up the dom4 game, and navigate to the game’s internal map editor.
Menu navigation: Game Tools > Map Editor > New map > (enter image file name)
This will automatically create a map. By populating it with provinces (one at each white pixel), then guess at the links between the different provinces.
Step 6: use the in game map editor to edit the map data.
This includes: mapping links between provinces, formatting link types (mountain, river, ground); terrain types (forest, farm, sea); throne sites, special sites, and so fourth. Its important at this stage to generate random names for each province, this is in order to populate within the .map file relevant code for the province names.
Example: #landname 1 “Deepmount”
example with no province markers
clean map
name edit
saving map name
example with imported image
Step 7: save the map. This will generate a .map file in your dom4 working folder.
Step 9: test play the map, and troubleshoot errors.
If the dom4 program crashes as soon as you load up the map. Then it is indicative of a hard fault. For example, the tutorial map here crashes if you try to add more than 4 nations to it. Other crashes like this can be caused by the dom4 binary being unable to find a resource. E.g. the user renamed/edited resource files, then tried to load into a game that uses them.
This method is probably the simplest way to actually create decent playable maps. By using the built in map creator tool, a user can bypass a lot of the tedium involved in coding. Such as learning the meanings of various symbols used for variables and game function, or learning the specific syntax used to generate a viable .map file. This is because the in-game visual editor automatically populates the .map file with viable code. All the user has to do is use the visual editor to assign all the functionality that they require for each province by checking menu boxes. Save the map. Then circle back to the .map file to fill in a couple of titles (in game text fields) after that.
Ultimately, I think that this quick guide provides a good framework. One that an aspirant map creator can build on further by reading IllWinter’s map making manual. Which in turn will allow them to gain further insight into the mechanics of map making; including the ability for more advanced functionality. In the mean time, just these simple steps will enable users to create perfectly playable maps. Ones that should satisfy most.
