biz, Games, Prototypes

CMF Conceptualization Iteration 3 – SoloDev Edition

1 Comment

This is the third time I’m talking about this. Post 1 and post 2 talked about how the whole thing works and how to make my application a better fit for the program criteria. They were both focused on Powered A(r)mour. But things changed in the last few weeks, and I figured I’d take another run at it.

I’ve been putting a lot of attention into Paint By Monsters the last few weeks, so it makes sense to apply for that project. So the other night I did that.

There are a few oddities in that process that are sticking with me, and I figured that’s a sign that it might be worth talking through it with y’all.

The first thing is just…what’s a prototype? Are the individual features I’ve been building a prototype? The funding Conceptualization provides is modest – capping out at $15,000 on a total budget of $20,000 – but in solo and small-team development, that money could get you a really long way. It’s one of the reasons I asked the CMF folks about team composition.

So one of the things I have to do is avoid overthinking that question. I don’t think what I have is a prototype by any reasonable definition, and it’s certainly not $20,000 worth of development, unless I’m massively undervaluing my own time.

To some extent this is a CMF issue – they don’t talk in much detail about what a prototype is for their purposes. I tried to talk about these programs in the first article, but let’s take a look at the descriptions provided by CMF:

Conceptualization

The Conceptualization Program, which forms part of the CMF’s Experimental Stream, allocates funding to Eligible Projects at the very beginning of a Project’s creative process with the objective of giving a Project a better chance to succeed for future stages of financing. Specifically, this Program is designed to allow an Eligible Applicant to create and test a proof of concept and verify either the design idea, concept assumption or demonstrate a functionality in preparation for the Prototyping phase and beyond.

Prototyping

The Prototyping Program allocates funding to projects at the early stages of building a product to demonstrate its intended functionalities and design. Specifically, this phase is for experimenting, testing and validating different concepts and hypotheses to arrive at a first functional prototype.

Beyond this, the required documentation for Conceptualization includes the following language:

CONCEPT DESCRIPTION (MAX. 3 PAGES) provide a written proof of concept proposal indicating clearly what you wish to create and test with the requested funds. The proposal can explore design ideas, concept assumptions or new functionalities and is required to convincingly present how it will be significantly interactive or immersive and how it will be connected to the Canadian cultural sector. Projects at the prototype stage cannot apply under the Conceptualization Program.

That’s…yeah. Confusing. Some language there is actually more similar to the description of the Prototyping program. What’s the difference between a concept assumption and a concept, for example?

So, again, best not to overthink it. PBM is at a very early stage and is in no way a mature concept, and that should really be good enough for a program aimed at early stage projects.

The second thing that’s weird about this is…I’m solo. I don’t have a team. I don’t even really have a network, though I have folks I could maybe talk to if I had resources. The bit of CMF’s response that talks about adjusting the team after the fact was useful here: My team is me, and just about anyone I contract with will be better at the things I ask them to do (art, animation, sound, music, and so on), so…that’s it. Even though I don’t have resources or people lined up right now, there’s a window between a theoretical acceptance and the signing of contracts wherein I could take that funding and attract someone good.

I recognize that’s not the stated intent, but to be honest, the folks I’ve talked to at CMF seem to think that they’re fine with small teams that manage things more or less this way. I’m just holding them to the standard they’ve communicated to me directly.

The third thing that’s weird is this:

Student film breakdown or solodev budget? You be the judge!

I’m doing all the things, so my name goes everywhere. I don’t intend to do things this way in the long term, and I’d really like to be able to do things differently in the short term, but frankly, if it’s good enough for Minecraft and Papers, Please and Tunic, it’s good enough for me.

I don’t really expect to be accepted on the basis of this application, to be honest. Conceptualization is a largely reserved-cohort fund, for one thing, and while I fit into some of those cohorts, I don’t particularly want to take up a slot that could go to someone who fits better and who needs this more than I do.

Plus, this really isn’t the kind of thing that CMF does. I’m a random guy building a game in my off hours. I don’t think anyone’s looking at me as a major contributor to the Canadian cultural scene. I don’t think of myself that way. I’m doing something I love, and I just want help making it the best version of itself. I don’t know that what I’m doing is worthy of note.

But I also don’t know that it’s not. Maybe this game becomes someone’s favourite. I can see the shape of things to come in the dim shadows beyond the work I’m doing right now, and I’m excited to explore them and define them and try them out. I wasn’t a working actor for very long, but it’s a similar feeling – you see the potential of what could be, and you do your utmost to make that a reality.

So…wish me luck? And if you’re a producer or a CMF staffer or just a person with some thoughts about all this, I’d love to hear your perspective on all this. We could use more open discussion about what CMF is for and how small developers – who are often the most passionate and interesting artists in the field – can get their projects work a little better and a little faster.

“Stock Photography – Canadian Money” by Katherine Ridgley is licensed under CC BY 2.0.

devblog, Games, Prototypes

Paint By Monsters: DevLog 4 + Feature Video 0.0.10 – Brush Strokes!

1 Comment

I’m gonna talk about all the faffery in a minute, but if you want the TL;DR, I invite you to take a look at feature video 0.0.10 – Brush Strokes;

Why “Brush Strokes”, Cousin?

One of the folks in my local gamedev community, the incredible artist rsvpasap, asked me a while back what kind of “painting” there was in Paint By Monsters, and at the time I didn’t have any kind of sensible answer for them.

Well, now I do, at least in the first-proof-of-concept sense. The Brush Strokes feature was directly inspired by that conversation, and I hope Angie would be proud to have sent me down this road.

On Assets, Asset Markets, and General Faffery

I’ve been mostly buying assets for PBM from itch.io artists, but there’s only so much content you can find there. I’ve looked at a bunch of new spots, particularly ArtStation and the Unity Asset Store, and in the latter I happened across the Gesture Recognizer asset.

This asset, on its face, is exactly what I wanted for Brush Strokes – a clean, simple asset focused specifically on recognizing a range of gestures, with good editor integration and the ability to create new gestures without a lot of faffing about. So, you know. Good job Raphael Marques on that front.

Unfortunately, Gesture Recognizer has a few problems out of the box that make it less than ideal to work with as of this writing. Maybe the creator will update it sometime, but in the meantime let’s talk about how I approached the issues that I encountered.

Fixing Gesture Recognizer

The first problem – and really, this is as much an indictment of Unity as a vetting agent as it is of the asset creator – is that unless you’re starting with the example level included with Gesture Recognizer, creating a new Gesture and trying to fill in the ID field causes a whole boatload of exceptions to show up in the Console Log. These will lead you back to the GesturePatternEditor.OnInspectorGUI method, and in particular to this line of code:

var closedLineProp = gestures.GetArrayElementAtIndex(currentGestureIndex).FindPropertyRelative("closedLine");

There are two exceptionally unfortunate things about this line of code. The first is that nowhere does the editor code check to see whether currentGestureIndex is a valid index for the gestures array. The second is that it is only really required in a small subset of gestures, because closedLine is only a concern when you’re closing a gesture that contains a closed loop of some kind.

My solution to this issue was relatively simple. I put an if statement around the entire editor block containing this piece of code:

if (gestures.arraySize > 0)
{
    //do stuff, including the array access
}

This fixed the editor errors, at least for the cases I care about.

I ran into some issues with the OnRecognize event that the asset uses, but I can’t 100% rule out PEBKAC for those, so I’ll just state for the record that Dynamic Events are tricksy, and you should look for them at the very top of the event list for the handler object.

I don’t really want to admit how long it took me to find that entry, but…it was a long time.

The Other Problem With OnRecognize

The really tricky bit with this event, however, is that the parameter for the event, RecognitionResult, only includes the points from the recognized gesture. The asset seems to be focused on some kind of cleaned-up vector drawing use case, so I’m sure that works great in that circumstance where you’re doing the scaling and whatnot in another component (for the record, you probably need to inherit from DrawDetector to do that properly).

But if you’re more interested in the gestures themselves – place, size, all that kind of stuff, and if you want to keep things nice and centralized to boot – you’re going to want the points as measured at the time of input.

Now, I’m not proud of my solution to this one, but I will say that it serves the purpose, and that’s enough for the kind of rapid feature iteration I’m doing on PBM. What I did was this: I changed the array of points that define the input being examined – which is a member variable in the object that invokes OnRecognize (that is to say, DrawDetector) – from private to internal. 

internal List<UILineRenderer> lines;

This lets me do the following in my event handler:

var cam = FindObjectOfType<Camera>();
var dd = transform.GetComponentInParent<DrawDetector>();
var lines = dd.data.lines;
var line = lines[lines.Count - 1];
var point1 = cam.ScreenToWorldPoint(line.points[0]);
var point2 = cam.ScreenToWorldPoint(line.points[line.points.Count - 1]);
Vector3 gestureVec = point2 - point1;
Vector3 gesturePos = ((point1 + point2) / 2.0f);

This works for basically any straight-ish line, and gives me the two primary things I care about:

  1. The position of the gesture in world space
  2. The orientation of the gesture in world space

I expect to have to do more complex analysis for future specializations, but these two vectors allowed me to specify

  1. Where my brush stroke effects appear
  2. How big they are
  3. What their orientation is.

Of course, then I had to figure out how particle system shapes work and how they interact with the Position, Rotation, and Scale of their host GameObject…but more on that next time.

devblog, Games, Prototypes

Paint By Monsters: Devlog 2 – Work To Date

Leave a comment

I promised some local tech folks I’d do a weekly summary of my progress on Paint By Monsters, and I figured since I was doing that anyway, I’d expand on it over here for anyone who’s not in that very specific community.

First of all, I’m happy to report that PBM feels kind of like a game now
https://www.youtube.com/watch?v=_LGMChMhVFk

Things of note in that video include:

  1. Programmer art new logo!
  2. FTL-style “Progression” screen – as I understand it, these are required by law for roguelike and roguelite games
  3. Upgrades – each time you defeat a hero, you get an upgrade for your monsters. I’ll be expanding on these over time, and probably playing with other possibilities.

There are lots of smaller details, too, but I’m mostly just happy to be well on the way to something that’s game-ish in form.

I’ve got lots of plans and ambitions in mind for the game in the weeks and months to come, so I hope you’ll stay tuned for those. Some of the high notes include:

  1. Lair Building v1 – add balconies, traps, chandeliers, and more
  2. More progression stuff
  3. More monsters
  4. Acrobatic maneuvers

I mentioned some of those in my first Devlog over on Itch.io. Which reminds me – if you’re wondering how I’ll be working Devlogs going forward, I’m planning to alternate between itch and this site, with links going both ways. I’m hoping you’ll stick with me on that. I tend to prefer to keep things on this site, but it’s nice to have a more well-known presence as well, especially since between the game page on itch.io and the ko-fi page for Perfect Minute Games I’ve moved from “fun pastime” to “thing I’m both spending and soliciting money for”.

That’s always a bit of a hard rubicon to cross, from hobby to serious, but I’m trying to take the lowest, informal-est approach possible right now so I can keep my focus squarely on making the game itself as fun as I can. At some point I’d like to expand my ambitions to include custom art, animation, and music, but I’m not in a rush for now.

Having said that, if you’re an artist or composer who might be interested in partnering up, my email is always open:

mgb (at) perfectminutegames (dot) com

I can’t tell you how much I appreciate the interest folks have expressed in Paint By Monsters thus far. I’m excited to work on my own game design again, of course, but you never know how well it translates to anyone else. So getting feedback and even financial support has been incredibly encouraging.

Hope yer well.

short, beautiful experiences