Me

I am Chris (although you may know me as my alter-ego, Jeremiah Fieldhaven). I've been developing software since the 1980s, and at this point it's not so much something I do as something I am. As my day job has drifted inexorably along the path to Management, I've found I really need to make time to write code and build things in my spare time to save my sanity.

I'm currently using Unreal Engine 5 to build a 3D puzzle game called Project Shinar, a game inspired by an old Amiga game called Tower of Babel with visuals reminiscent of the neon-glowing polygons of TRON.

I'm generally terrible at keeping websites updated, so we'll see how this goes...

Contacts

You can find me on Mastodon or I can be emailed at chris@starforge.co.uk

Why "Jeremiah Fieldhaven"?

Essentially, it started off as a bit of silliness. I had been playing Sunless Sea and there was a place on my map not far from Wolfstack Docks called "Fieldhaven's Rest". At the same time, I decided I wanted to start over in Elite Dangerous with a new commander, so I was looking for a name. I decided it would be Very Silly to have a spaceship commander with a Victorean-era sounding name flying around in the 3300s world of Elite, so I set about coming up with a suitably ridiculous name. With "Fieldhaven" in my head as a surname for this commander, I chose a likely looking forename from a list of 1800s names. And thus Jeremiah Fieldhaven came into existence. I connected with other Elite Dangerous players on Twitter and Discord with the same name, and the rest is history really.

There have been many drafts of this page, but I find myself unable to really communicate my stance without falling back on profanity.

So.

Fuck the LLMs like ChatGPT, Claude, Copilot, and the rest. Fuck the complete gobshite pissweasel fascist techbros behind this absolute mess. And especially fuck them for adulterated the term "AI" so that legitimate techniques are tarred with the same brush as their massively wasteful LLM chatbots.

The whole enterprise of the LLM chatbot companies is based on theft, deception, wholesale violations of legal and social contracts, DDoS attacks on websites, and massive harms to the environment, society, individual cognitive function, and the future of multiple industries due to deskilling and disruption of entry-level training.

I have to protect my servers against the attacks from their crawlers, spending time, effort, and resources to handle the bloody things while I watch the increasingly inflated bubble hurtle towards its inevitable crash as the true costs involved and the utter lack of any path to profitability becomes impossible for the investors to ignore.

I can not, and will not, support any part of it and if you use their shit kindly do us both a favour and sod off.

I will not set aside my moral and ethical objections to a technology out of convenience to replace cognitive exercise with a gambling-addiction-adjacent make-up-statistically-probable-bullshit machine churning out mediocre crap and peddled by a cabal of suppurating fistulas.

Or, put another way: I do not use generative AI for any part of my site, games, or other programs.

After having my old site sit dormant for the best part of five years, I think it's probably finally time to try something a bit different. For a start, I've ditched Wordpress; in part because of the unending tantrums of Matt "Drama" Mullenweg, but mainly because Wordpress is just overkill for what I need (as well as being constantly attacked.)

This new site is generated using Homer, a minimalist static site generator I wrote after issues with MkDocs. I need to write up a description of the site generator process, and why it was created soon.

Latest updates

• 2026-05-03: Another new site - now made using my own site generator.
• 2026-04-03: Updated the Links page
• 2026-02-21: Added a page discussing Project Gregorian
• 2025-08-23: Added a new Unreal page and Using images in UComboBoxKey
• 2025-03-23: Added a section just for AI Crawlers. Note: This is a tarpit, enter at your peril.
• 2025-01-26: Added a brief history of Project Shinar and its inspiration.
• 2025-01-20: New site!

Buttons

Apparently 88x31 buttons are making a comeback¹, so here's a few! If you want your button to appear here, contact me on Mastodon or via email with your URL and button image.

If you want to use a 88x31 button to link to this site, here's one:

Webring

[    GAMEDEV   WEBRING    ]
[<PREV RAND LIST NEXT> ]

Other links

These are in no particular order, just links to sites I highly recommend:

• https://www.hempuli.com/ - Hempuli, of Baba Is You fame.
• https://bumbershootsoft.wordpress.com/ - Michael Martin's software experiments, retro projects.
• https://www.teamonstergames.com/ - Games by Jeff Murray.
• https://www.stevestreeting.com/ - Unreal and general gamedev tips from Steve Streeting, creator of Ogre, Sourcetree and others.
• https://grumpygamer.com/ - Ron Gilbert (Monkey Island, etc).
• https://nivrig.com/ - Games by John Girvin.
• https://runevision.com/ - Really interesting discussions of procgen tech, game design, and more.
• https://www.ascorbius.com/ - Elite Dangerous story videos and general muppetry from an awesome chap.
• https://glassbottomgames.com/ - SkateBIRD and more.
• https://www.stevehammond.org/ - Formerly of DMA design, writing and UFOs.
• https://www.heartofneon.com/ - Started off as a Llamasoft documentary, now covers indie devs too.
• https://kenney.nl/ - Really fun low-poly asset packs.
• https://kaylousberg.com/ - More low-poly asset packs.
• https://www.neilhenning.dev/ - Verse developer at Epic.
• https://whatever.scalzi.com/ - Author, and generally decent human.
• https://www.nathansavant.com/ - Narrative and game design.
• https://www.tomcooksound.co.uk/ - Songwriter, artist, and pillar of the Elite Dangerous community.
• http://thalass.freeshell.org/ - Thalass' projects.

A bit of background

Every year for the past decade or so my wife and I have bought a fractal art calendar to hang on the wall between our desks. We both like fractals and thought the work of this particular artist was really excellent. The calendars were were well made, showed the days in a way we liked, and generally ticked most of the boxes for us for a wall calendar.

In October 2025 my wife discovered that the creator of the calendars had stopped making them, so we had to decide what to do for a wall calendar in 2026: should we try to find a different fractal calendar, or go for something else entirely?

As we were sat talking about this with our monitors in view, I pointed out that the form factor of the calendar was fairly close to a 24 inch screen in portrait orientation. We could scan the images from previous calendars, or we could use any of the nearly 70,000 photographs² we've taken over the past couple of decades, and display them above a generated calendar. We need not even be constrained by the limitations of paper at that point!

The requirements

Eventually we settled on a few key things any dynamically generated calendar needed to do, with any features on top of these being nice to have:

• The week needed to start on Sunday.
• Instead of showing one month at a time, the calendar should show a 5 week rolling view: the previous week, the current week, and the next three weeks.³
• The display should show the month and year information, and handle the case where the rolling display spans multiple months or the start/end of years.
• The calendar should be able to fit the colour scheme we want for the room.
• The display should have an image at the top, and the calendar below it, as you would expect for a wall calendar.
• There should be some way to move the calendar display forward and backward to show past or future weeks.

You can see more details of the features the system provides in the readme file in the project repository.

How the devil to build this

Having opened my big mouth, I now had to work out how to make this work. It obviously had a bunch of extra things to decide on that the bare requirements didn't even really touch on, things like

• Desktop program, or web application?
• How to get events into the calendar? Import from an ical feed? Or multiple ical feeds? Or allow events to be defined in the system? All the above?
• How to get pictures in, how to choose which picture to show at any given day or time, and what dimensions to use for the pictures?
• How to actually display it on a screen?
• How to do the controls?
• Many, many other sentences ending in '?' that I will spare you!

The first constraint to help narrow down the implementation space was that it had to fit onto a 24 inch screen in portrait mode, so 1080x1920 was the target for the display. I didn't want to try to drive the screen off any of the computers on the desks, and I have several spare Raspberry Pi 3B+s lying around from old projects, so it made sense to have a Raspberry Pi connected to the screen and have it show the calendar.

This helped to add another constraint! My past experience with Raspberry Pis has made me very wary of running anything important on them because they seem to be harsh on microSD cards. I've had decent quality microSD cards go dead in less than a year when used in a Pi, so I didn't want to put the actual calendar software on the Raspberry Pi, just in case it shat itself and lost any data between backups. I decided the most straightforward approach would be to write the calendar system as a web application running off my server, and have the Raspberry Pi connect to the WiFi and start a web browser in kiosk mode showing the calendar page. That way the system would be part of the normal backups on the server, and nothing would be lost if the SD card went off to silicon heaven.⁴

Using a Raspberry Pi also opened up the option of using the GPIO pins to provide a means of controlling the display. One of the standard device tree overlays available on the Raspberry Pi is the gpio-key overlay, and if you connect a push-button switch between an appropriate GPIO pin and 0v, you can have the gpio-key overlay emit an input event when that button is pressed (the overlay also handles debouncing the switch, which makes life even easier!) Multiple GPIO-connected buttons can be added, allowing a range of input events to be triggered in response to button presses.

To the code mines!

As previously noted, the "volunteering to make this thing" happened in October. What I didn't say is that it was the last week of October. Which meant I had two months to get it into a usable state for the start of the year. So I decided to fall back on building it in a language I know well (Perl⁵), in a framework I've used for years, cribbing a lot of supporting code from another one of my projects to get things going faster.

I'll skip the gory details of the implementation - if you are interested, you can find the code and instructions for installing it in the Project Gregorian repository⁶. A few pointers if you really want to explore the code for Eris knows what reason:

• The calendar page itself is generated by the WallCalendar::Calendar class. The entrypoint in that file is the page_display function at the end, which calls _dispatch_ui to generate the HTML content or _dispatch_api to handle API calls from the javascript.
• Other classes in the views directory generate other pages - the images manager, login form, and settings page. The entrypoint in each is the page_display function, which then calls the UI or API dispatcher for that class.
• Classes inside the modules directory are system and support code, with model code for the calendar data and image handling inside modules/WallCalendar/Database

Some things I will note about the implementation process, though:

• I decided early on that I wouldn't allow the creation or editing of events through the site, and I would rely on importing events from established calendar tools using ical feeds. Building an event management UI looked like being a complete pain in the arse, and it would have taken me a lot of time (I didn't have) to get even close to key feature parity with existing calendar tools. That said, the database schema is set up in a way that could allow for an in-system event management UI in the future if I ever lose my godsdamned mind.
• Building this thing had me get way more familiar with RFC 5545 and siblings than I ever thought I would be, and in the process I discovered some things I've never seen calendar tools do that the spec supports (particularly around repeat events). I was honestly impressed with how much thought had gone into it, even if section 3.3.10 will haunt my nightmares for a long time to come.
• Relatedly, I also discovered that different calendar tools interpret parts of the spec in subtly different ways, which was... unsurprising.
• This whole project takes an arguably terrible approach to dealing with time zones and DST⁷. In that it largely ignores them as much as possible. Essentially it treats events as happening in 'local time', and the only real shenanigans with time zones happen when establishing when "now" is. I think it will work in practice as long as you're not dealing with events defined in multiple time zones, but I'm not certain, and it makes my head hurt summat proper.

The hardware side

The hardware side of this project was much more straightforward - there are essentially three major components:

• The screen. Any 24 inch screen would work really, larger ones could work but the system assumes a 1080x1920 display so it might not look right without tweaks⁸. We got a fairly basic Philips 24E1N1100A for it.
• The Raspberry Pi. Pretty much any of them should do the job, although any before a 3B+ might struggle, and the 4 or later may need active cooling. In fact any system that has wired or wireless network support, can run a web browser (ideally Firefox-derived), and outputs its display over something the monitor supports should do the job, I just happened to have a RasPi 3B+ lying around.
• The control buttons. I'll describe this in more detail shortly, but this is essentially a very simple circuit on a piece of stripboard with wires going to a set of GPIO pins on the RasPi, housed in a 3D printed box.

As it turned out, the choice of screen was quite lucky: there is just enough space in the cable entry area at the back of the monitor to fit the RasPi, and the space is deep enough that the RasPi can sit inside the standard case and be stuck to the monitor to hold it in place.

The control buttons

As mentioned above, if you set up a push button switch between a GPIO pin on the RasPi and the 0v line, you can use the gpio-key overlay to emit a key event when the button is pressed. There are lots of ways to do fancy things with this, but for this situation all it really needs is 7 push switches wired up to GPIO pins:

The stripboard implementation of the circuit is a bit messy - definitely not my cleanest work. I used a pair of old USB cables to connect to the RasPi, and I was not entirely consistent in the selection of colours for the cables for each switch, so a fair bit of double-checking connections with a multi-meter was needed. To help keep the wires in place, and to provide a bit of strain relief, I used some strong black thread wrapped over the wires and through the stripboard.

Once connected onto the GPIO pins for the RasPi, the config.txt with gpio-key overlay lines added was all that was needed to make the buttons work.

The button bar itself would look a bit ugly just hanging out there naked, so I designed an enclosure for it and asked a relative who has a 3D printer to print the box for me:

It fits around the stripboard circuit and holds it in place, and the printed buttons give a bit more area to press than the small push buttons alone.

Fitting the bar below the screen was a bit trickier - I needed some way to mount it, and the screen bezel is too thin at the bottom. Luckily I had a piece of acrylic left over from another project ⁹ that was almost the right size, minus a few cut-out pieces that I could work around, so by sandwiching the acrylic between the screen and the wall mounting plate, I could use double-sided tape to stick the button bar below the screen!

The rest

A few other things were needed to make the whole thing work:

• First the RasPi needs to be configured to boot into X11 rather than wayland (so unclutter will work)
• unclutter needs to be installed to hide the mouse pointer
• screen blanking and xscreensaver need to be turned off
• a firefox.desktop file has to be added to ~/.config/autostart/ on the RasPi to load the browser after the desktop has loaded.

With those in place, whenever the Pi is powered up it will boot to a desktop, start the browser, and load the calendar automagically.

Some closing thoughts

This was definitely an interesting project to take on, and so far it has been working out well: it's something we both look at many times a day, and the rolling nature of the display really helps prevent surprises at month starts.

I would be utterly lying if I tried to claim that there had been no problems with the system, but for something that I put together the majority of in a handful of weeks (with only parts of weekends and some evenings to work on it) I am really happy with how it has turned out. There are definitely some places in the code I could improve or clean up a bit, but really that's true of any project.

The worst part - and the part that has led to the most bugs, headscratching, and profuse swearing - has been the process of importing calendar events from ical feeds. It has definitely given me a very profound appreciation for the complexities of calendar handling and I would not be at all surprised if the importer is something I end up having to tweak or fix more than anything else in the code over the coming months.

Over time I'm slowly collecting a few Unreal bits and pieces, techniques, and not-entirely-tutorials here in the hope they may be useful to others doing battle with the behemoth known as Unreal Engine.

I should note that the pages linked from here are discussions of Things I Have Figured Out, either by chanting the appropriate arcane profanities while reading the source, or piecing things together from scatted forum posts and hastily-scrawled, blood-stained notes scattered prominently on desks in abandoned offices¹. They may not represent the correct - or even necessarily remotely sane - way to do things, but they seem to work for me.

Using images in UComboBoxKey

About the Blueprints

The original inspiration

Cast your mind back if you will, dear reader, to the heady days of 1991¹. The Soviet Union collapsed, the first Gulf War ended, the World Wide Web was released outside CERN to other research institutions, and the first website ever was published. Amidst all of these and many other huge events, one event in particular had an impact on my young self that may be responsible for where I am today: this was the year my brothers and I got an Amiga 500 for Christmas.

We were pretty late to the Amiga really, but my family weren't exactly well off and the Amiga wasn't cheap. It took some saving to buy the system. As a family we'd gone to a small shop called Stewart Electronics on Penny Meadow in Ashton-under-Lyne², and we brought the new computer home on a rattly old bus while we poured over the box. The set we got came with a bundle of games³, and one of those games was Tower of Babel.

Tower of Babel had been released the year before for the Amiga, programmed by Pete Cooke and published by Rainbird Software, a label of MicroProse. It was effectively a port of an Atari ST game, so it didn't really take full advantage of the Amiga's capabilities - with the perspective provided by many years of distance, it is pretty obvious that the sound effects are basic and crude, the graphics are at best functional, and the framerate on a stock A500 was... not great.

That said, coming from a ZX Spectrum 128 it blew us away: the graphics, sound, and speed were way ahead of anything we were used to. ToB was played a lot to begin with, in part because it was a fun puzzle game, but perhaps more so because it included a level editor! We could build our own levels and challenge each other to finish them - always a good source of fun between brothers (or arguments anyway). Inevitably it fell by the wayside as more games were acquired, but even now I still have a copy of ToB in my WinUAE install.

So, what was it then?

The name comes from a somewhat strained attempt at providing the background for the game: the construction of the Tower of Babel attracts the attention of passing aliens who leave three robots to help the Shinarians with their work on the Tower. Human nature being what it is, things go pear-shaped, and the humans turn on the robots. The player controls the three robots as they attempt to traverse levels (called 'towers') full of traps, puzzles, and creatures so they can collect their power supplies and escape.

Leaving dubious biblical references to one side, the game itself has you controlling the imaginatively named "Zapper", "Pusher", and "Grabber" robots: Zapper has a laser beam you use to blow things up, Pusher has a repeller beam to push things away from it, while Grabber has a tractor beam to collect the all-important power supplies and turn on a few different devices around the towers.

Tower Of Babel's supplied 'towers' are split into 13 groups of 9 towers, each of which puts you in control of one, two, or three robots. Each level has varying objectives - you might need to collect a given number of the power supplies and/or destroy a given number of objects, and there may be a time limit in which you need to complete the objectives (for some reason that is never explained.)

The levels themselves are formed from coloured squares in a chequerboard pattern, up to 8x8 floor squares in horizontal size, and with up to four floors. Travel between different floors is via grey 'lift' squares that can go up or down at most one floor. When objects, including the robots, move around the level they may only do so along the cardinal directions - they can not move diagonally - and only one object may occupy a given square at a time.

And so to Project Shinar

I've done game dev, on and off, for almost as long as I have had access to a computer⁴, but almost none of the things I've done have really come close to a state where I'd release them⁵. I'd always either end up losing interest or, more likely, end up going down rabbit holes trying to write my own engine and end up never actually making a game. During 2017 I got it into my head that I wanted to learn Unity and hopefully make something I'd actually release. I started casting around for ideas for what to make, but inspiration eluded me.

Then one day I was clearing out boxes in the attic⁶ and came across the manual for Tower of Babel in a box of old manuals and papers. This set me wondering, could I use ToB as inspiration for a game to build while learning Unity? I didn't want to straight up clone the game, but it did start a chain of design ideas for ways to take the core ideas of the game - the three robots, having them coordinate to solve puzzles in a 3D world - and see what could be done without the restrictions of late 1980s/early 1990s technology.

It was late 2019 before I'd actually worked out what I wanted to do, and really started learning Unity to make it work. A key piece of the puzzle came when playing with possible designs for turrets in Lightwave when Winamp⁷ randomly chose the Overture track from the TRON: Legacy soundtrack⁸ and I suddenly realised: what if I took the core mechanics from Tower of Babel and set it inside a TRON-like world inside a computer? Lots of ideas suddenly started to slot into place

• The three robots are robotic agents being controlled by the player trying to infiltrate a big computer system and extract data from it.
• The TRON-inspired setting allows for manageable assets: fairly low poly objects with relatively simple textures that add glowing edges, and no need for organic-like objects (making those has always been my nemesis.)
• The TRON-inspired setting also gives scope for naming things in a TRON-like way: referencing computer parts, systems, or programs for areas the game happens in, naming the robots after CPU assembler mnemonics (even M68k ones!), and naming entities found in levels in a similar fashion.
• Time limits for levels can be explained as runtime limits on the program the robots are working in.
• With the scope of more memory, CPU power, and graphics power, I can allow larger levels, and more programming steps per robot.

I threw away the turret design I had been working on, and started building something that looked like it could exist in the TRON world, and quickly came to the conclusion that this would work

Before long I had a list of features, NPCs, and level mechanics that took ideas from Tower of Babel and enhanced them or added entirely new systems, like wall-mounted signal emitters that beams could activate to send signals, and those signals could turn things on or off, open barriers, or even move lifts.

Progress was still really slow, though - I had a lot of trouble focusing in the latter part of 2019 and early 2020 for some reason. During the first lockdown, Ascorbius started doing gamedev livestreams and I regularly joined the chat for those. Those livestreams and conversations really helped my enthusiasm, and I really got into the development properly.

I'm going to fast-forward a bit here, because this is long and rambly enough as it is.

By mid 2023 I had released several alpha versions of Project Shinar, and by that point a fair bit of the game was working: levels could be completed, a lot of entities had been made and worked, the built-in level editor was functional, and I was starting work on the interface the player would use to move between different zones in the computer.

And then The Unity Debacle of Sept 2023 happened.

To say I was put out would be something of an understatement. I could have carried on with Unity, realistically I wasn't affected by their change, but I'd be forever worried about them doing something else that would cause me trouble, and continuing to support them in any way just felt wrong.

So I needed a new engine. And while I wasn't starting from scratch again - I knew many of the assets could be used in any other engine - I knew I was going to end up redoing several years of work.

By mid-October 2023, I'd settled on Unreal as the replacement. Another page will probably be in the works about my experience moving from Unity to Unreal...

If you do not have a UI designer, feel free to imagine yourself wearing a black turtleneck and a condescending expression for the same effect.

ANYWAY, amidst the buttons, bars, and borders you discover there is a need to present the user of your user interface with an interface that allows the selection of an image from a list of images: a dropdown list of images if you will. This is apparently not negotiable without interrupting a 3 hour symposium that will inevitably descend into factional disagreements over lists and checkboxes, so a dropdown it must be.

UComboBoxString v UComboBoxKey

The first thing you may notice, while gazing forlornly upon the Input category of the widget palette, is that Tim Epic gives us not one but two types of ComboBox. One has the mysterious and obtuse suffix (String) while the other has (Key), and the tooltips for the two are nearly the same. However, neither seems to mention images at first glance. Despondent at this you might attempt to glean advice from the documentation. There's nothing like good documentation, and as all Unreal users can agree its documentation is nothing like good documentation. In this case, it's as much use as a chocolate fireguard.

Eventually it may become clear that that the "Use OnGenerateContentWidgetEvent to return a custom built widget" part of the ComboBox (Key) tooltip is a clue. On plonking one down in your widget blueprint you will notice that there are two events you can do things with: there's the OnGenerateContentWidgetEvent alluded to in the tooltip and its companion OnGenerateItemWidgetEvent. Those sound very much like things that expect you to create your own widgets to show in the content area of the box, and for each item in the dropdown respectively. This is because that's exactly what they are - although good luck getting that from the docs. And you can make the widgets be basically anything you want: everything from a simple Text box up to a panel containing multiple widgets!

In short:

• Use ComboBox (String) if you just a dropdown that only contains strings (not even Text - just strings!)
• Use ComboBox (Key) for dropdowns containing anything else

An actual example

If you've made it this far through the somewhat hyperbolic prose, you'll want to see how to do this - and honestly, many of the other almost-explanations of this I have managed to find for this go full-on Draw The Rest Of The Owl here so without further tangents or hyperbole ¹ I'll explain how I got the image list dropdown shown in the screenshot above to work.

The Options list

Once you've added a ComboBox (Key) to your widget blueprint, style it as needed - I won't go over this, because the style options are largely the common ones you find for all the other widget types, and thankfully they're mostly self-explanatory.

What might throw you is that the Content -> Options list is just an array of Names, similar to the ComboBox (String)'s array of strings. This is where you'll need to think a little laterally. What I did was create an array of Texture2D object references to store the list of signal images²³

And then on constructing the widget blueprint that contains the Signals dropdown I add entries to its options list, one for each array element:

So now there's a list of Names that are really just indexes into an array, and the corresponding array of images. Now we need to make images appear.

Showing the images

The naive thing to do at this point is to click on the On Generate Content Widget button, click on + Create Binding and set up a function like this:

the function creates a new Image object, converts the Item name to a string, then an int, uses that to index into the SignalImages to get the texture to show, sets the brush in the Image from that texture, and returns the result. Set the On Generate Item Widget event to call the same function and...

Well. It sort of works! The problem is obviously that the Image is being sized to fill the container, but the image should be shown as a square, not stretched to near-unreadability across a rectangle!

Showing the images properly

But we can make any widget and show it in the combobox, which means there are ways to avoid such a stretchy and distorted fate. Create a new widget blueprint (I called mine WBP_Editor_SignalBox because that's where it is being used: signal comboboxes in the editor) and do something like this:

That is, an appropriately sized image inside a Horizontal Box, set up to be centre aligned horizontally and vertically. I also added a function to that widget blueprint that let me set the texture drawn in the image⁴

With that in place, the OnGenerateContentWidget function for the dropdown can be updated to create an instance of the newly-defined widget blueprint:

This does much the same as the previous one, except instead of an Image it creates a new WBP_Editor_SignalBox and sets the texture shown in the image via the SetSignalImage function. With that change made, success!

Some extra thoughts

One thing to note is that you don't necessarily need to use an array of textures here - you could have a more complex setup where you have an array or map of structs with more data in there. I'm using an array of textures because the situation is pretty simple. It would be fairly trivial to extend this so that instead of just an image, there's an image and a Text box to show a name next to the image. It's entirely possible I may end up doing that in my level editor.

As you're providing a widget for each item and the contents of the dropdown button, you could conceivably have different layouts for each, and even have the dropdown list vary so that even rows get one type of widget, odd ones a different type, just be careful to not go overboard otherwise you might get even more condescending stares from the UI designer (real or imaginary...)