To experiment with the game platform Construct 2, I created a small dollmaker game from scratch. Dollmaker games are a genre of web games that allow one to pick and choose components of a character, often including facial expressions and clothing. Doll Divine has excellent and popular examples. I decided to put my cat drawing skills to use and create a dollmaker with realistic cat markings. The game can be played by clicking the link above. (Note: Construct 2's plugin appears to be buggy on Firefox now, I apologize for the inconvenience.)
This project branched naturally from the adoptable art that I've sold in various forms online. For adoptables, the concept is using one lined, shaded base artwork and applying differing markings and colors for each individual customer/adopter. You can see my commission site for what that looks like. A dollmaker game incorporates a similar principle, but with a constrained set of options to pick from. Of course, since a player can pick from 5-20 customizations often with a variety of colors for each, the actual number of unique outcomes is high. So, a dollmaker offered a neat, automated alternative to coloring my adoptables for individuals.
I also wanted to incorporate cat genetics into the equation. Early on, I made the decision to stick with realistic cat coat colors and markings. However, one important consideration was whether to constrain the outcome to adhere to genetics. Namely, a cat can only have 1 type of tabby marking and that marking must match the base color (e.g. orange tabby cats don't have black stripes). In the end, I decided it would be better for players to let them go wild and put on as many tabby markings as they desired. This had the added benefit of increasing the possible marking mixes for tortoiseshell and calico cats.
A fantastic example of cat coat colors and patterns is available here, and I used this as a starting point for picking my own colors and patterns.
I spent a few hours fiddling with dollmaker games to get a feel for which interfaces worked well and which I found clunky. Because most of these games are small hobby projects like mine, they rarely feel polished. Virtually all of the dollmakers had tabs for different categories of items, so that was a definite feature in my game. This rat dollmaker had similar categories to what I envisioned, but the number of menus required to actually pick markings and colors felt clunky. Removing markings was also a huge pain, requiring you to find exactly which one you selected before and hit the no color button. Many dollmakers, such as this anime singer dollmakers, used cute symbols of different colors to indicated their function, but they wind up being so small that clicking them is difficult. Others used icons that were larger, but they needed pagination like this cat girl dollmaker.
With those examples in mind, I decided to use tabs for various marking categories and stick to a palette of color small enough to not require pagination. There are 8 natural coat colors for cats (3 variations of the black allele and 1 of the orange, and a dilution modifier that could apply to any of them) plus white (a separate gene), so I figured they'd fit nicely in one or two rows. In my sketch, I planned to use half of the space for the cat and half for the UI. Each page would need a title as well as a text or image descriptor of what the buttons were for. I also planned for two larger buttons to save and reset the doll. Some dollmakers allow items to be dragged and droppd, but I decided against that for this cat dollmaker since many of the markings (like tabby stripes) need to be at a fixed point to make sense.
Next, I did a more detailed mockup of my plan in Illustrator. Assets like the background and buttons were taken directly from Illustrator to use in the final design, but in the mockup I only put enough together to get the idea and scale. The buttons were experimented with in this stage. At the bottom, the tabs use a visual button to give the user an idea of what type of markings they'd find in that tab. In the final project, I included a text description under the image. However, the actual list of options on each page uses only a text description. Neither the options nor the individual color palette buttons are shaped based on the marking they represent. Space was an important consideration for that decision, but finding a compact yet representative image for each marking also proved difficult.
I created the artwork for the game with an eye for clean realism. Each marking is saved as a transparent image, and Construct 2 interacts with them as a spritesheet. The major change that occurred to the artwork between the mockup and final product was a redo of the shading. Unfortunately, Construct 2 had no layer blending modes, and the original shading was a mahogany color on multiply mode over the markings. I switched to a cell shading method so I could have a warm dark gray on low opacity over the base.
Construct 2 uses a block-based programming structure. Implementation was primarily a process of putting every image into the game in the correct spritesheets and layer order and hooking up each image to the correct visibility change. Each category page is its own scene, and variables exist to track the current markings of the cat. The square icons for picking colors are also compiled into a spritesheet, so when the user clicks on a color, its frame can be used as the basis for adjusting the frame of the marking on the cat. That is, the black button is frame 1 of the spritesheet for the buttons, so if the user clicks it, the marking in question can be changed to frame 1 which is the black version of any given marking. More math is involved since not every marking comes in every color, but this structure drastically reduced the needed code blocks for the project.
I added some helpful polish, such as text below the image tabs and numbers on top of the white marking options. While the unrelated white markings are arranged as even rows and columns, I decided to group the typical color options into pairs based on the typical and diluted version of each color.
I decided to create this small project in Construct 2 in order to learn the interface and judge whether I wanted to develop games with it in the future. At the time, fellow Video Game Design Club members were talking about which platforms they wanted to experiment with, and Construct came up several times. A free version exists with the ability to export games as html5, so I gave it a try. Overall, I don't feel it's suited to complex projects. Although Unity 2D has a higher learning curve, it has far more room for growing complexity and is worth the trouble of getting used to. Construct 2 can handle simple games quickly, but many aspects felt clunky and I was frequently frustrated with the limitations of the block-based programming.
The spritesheet features of Construct 2 wound up being extremely helpful for my project. Like I mentioned in implementation, each marking set is a spritesheet, and the colors of the buttons are part of a single spritesheet, so I can pick the frame of the marking sheet based on the frame of the activated button. Manipulating objects was fairly straightforward, but often required an obnoxious amount of button clicks to set up each block. There's no typing what you want - you have to go through the menu every time.
I wanted to make each page into its own scene for better asset management, but this wound up creating a huge problem with carrying changes between scenes. If a button had been clicked on one page, like setting a calico marking to blue, that marking would go back to its original frame (completely transparent) when the scene changed. The only solution I could find while maintaining scenes was creating a long list of global variables to track the cat's entire marking set in order to reset it at the start of each scene.
The free version didn't have too many limiations, but the biggest one was restricting the number of layers to 4. I have a layer for the background, the boxes, the scene's unique pieces, and the cat. I would've preferred to put each marking on its own layer to enforce the proper order. For some reason, using the Z Order within a layer doesn't properly enforce the Z ordering during gameplay, so I have to reset the order with a block of code every time a scene changes.
Allowing the user to save the image also required a bit of a workaround. It was the must frustrating part of the project, but it was also the feature I wanted the most since users might want to save images for themselves. When the user clicks Save, the game briefly flattens itself into one image and saves that before expanding again. There doesn't appear to be any method in Construct 2 for trimming or cropping images, so there's an awkward transparent half in each saved image.
While some threads on forums and help sites for Construct 2 proved useful, overall the amount of resources paled in comparison to platforms like Unity and HTML5. The final struggle to be able to save images tipped my opinion in favor of never using Construct 2 for anything more complicated than a game of Solitaire.