Solo dev game design questions

Good afternoon everyone, I'm kind of at a loss as to what to search for... I've dabbled in small game projects in both unity and unreal, but has always been not so serious games inexpensive pottery wheels.

My wife and I have a project we are both thrilled about and I really want to make an honest effort on the project. I've been trying to find resources on how to properly structure both the project and our planning process but everything comes up as "beginner this" and "beginner that". I understand the basics well enough, how to override low ink on canon printer and we are using Trello to manage the project which is working fine now. My issue is I'm not sure what information is missing. I'm digging through game design information and it's helped but overall I'm not sure the general structures I should be looking for. I guess I'm looking for advice on how to structure both our management side and how games are generally structured for a "released" game. Tips on proper search terms or advice would be much appreciated as id like to have my ducks mostly in a row prior to jumping head in.

Thanks all!

Edit: I guess also looking for information on how to piece the different bits of a game together to flow more.... nicely? I guess all my previous projects have always just felt all patchworked and maybe that's how it normally goes but thought id ask lol

 

Hi,

You're likely to get some wise advice from experienced game devs, such as setting up continuous integration and automated testing, or setting up Agile project management workflows. File it away and ignore it.

It's great advice but, if you're anything like me, you need to stumble through messy processes first to really appreciate the value. In short, just go for it, and learn those things as you go.

The best thing you can do is take some high level steps to minimize the damage -- which, frankly, is what all the advanced advice is for, too. Things like continuous integration and automated testing are designed to validate correctness and catch bugs early before they can cause damage. But the high level steps I recommend are:

Paper prototype: The more you can plan out on paper, the less you have to wrangle with code and Unity.

MVP: Make the smallest version of the game you can think of. This lets you test the gameplay loop and get an idea of how a larger version would be structured.

Version control: Use it. Services like Github let you store private repositories in the cloud.

Programming: As time allows, read up on these programming principles: SOLID, DRY, and design patterns.

Modularize: This touches on the principles above. Try to keep separation between different code functions. This is called decoupling. For example, if you change something inside your inventory system, it shouldn't break anything inside your health system.

If you'll forgive me for dipping into the weeds, the two low level things I'll recommend are disabling domain reloading and using assembly definitions. As time allows, search them up. They can be a headache to set up, but they make it much more pleasant to iterate in Unity.

 

It's probably worth watching some GDC talks on the topic. At the very least they should give you the tearms you need to search for. Here are two to get you started but I don't remember if I actually watched them myself so YMMV:

 

so you wanna say that. this is not the right place to ask that type of question pesco online bill?

 

Not at all! It's a fine place to ask the question. I'm just suggesting that you not get so deep into the weeds of things like devops and project management that you never actually get your game done. File the topics away (including the excellent GDC talks that Martin_H linked above) and refer to them later when you feel like they'll fix something in your existing process. If you're anything like me, those topics will have much more relevance after you've muddled through a few mid-size projects first. If you try to set up all that stuff before working on your project, (1) you're not likely to set up a workflow that really works for you because you don't yet have the context, and (2) it can be a way to procrastinate.

 

Yeah, don't do things because you think you "should" do them. Do things because they solve problems or increase productivity.

To add to @TonyLi's list from before:

Start with small projects. This gives you opportunities to learn what you're missing while limiting the damage, by reducing how far you need to carry the baggage. It also gives you opportunities to...

Do "post mortems". At the end of projects or milestones, take a day off working on your thing and instead reflect on how you're working on your thing. Identify what's working, what's not, and stuff you can try to address the latter.

Advice from others is great, but experience from deliberate practice is best.

Theory does help, too. Unfortunately I've no books to recommend. Atlasdian have great resources on Agile, perhaps that's be of use? My main advice would be to not restrict yourself to game dev resources. In many ways games are similar to other technical and creative pursuits.

 

This is the question that blocks at least 95% of games from reaching completion.

In the crudest of terms any game has 4 phases.

1) prototyping. The most overlooked phase by far. You need to make a core experience prototype and absolutely nail it before anything else. When they made Mario 64 they spent a full 2 months just getting Mario’s movements right. Dig around and you’ll find a LOT of people fail because they start building up a game before nailing down the core mechanics. Prototype, prototype, prototype!!!

2) Asset building. Knock out as many of your assets as possible before even touching the actual game. You should also cap this off with a vertical slice to show how it all works together.

3) Game development. Actually make the game. Make sure to make lots of case specific gameplay. A game that feels like a bunch of pieces dropped in place, without making instance specific code is straight up tedious to play. Also make sure to make “tent pole” moments. That is, make moments that make the players jaw drop. It makes a psychological trick where the player identifies the entire experience as it’s best moments. So pick a few moments to stick out and have the player subconsciously think the entire game is that quality. UBI soft LOVES doing this all the time.

As an example they will have a ridiculously detailed model of the villain do a monologue with lots of effort put in the animations. Then for most of the game the villain is a regular model with “good enough” animations, but subconsciously you think the other moments are just as good as the “tent pole” moments.

4) Polish. AKA, the halfway point. Seriously. If it take you a year to get to the point where you have a complete game, plan to put in a year to polish what you’ve made. I’ve heard the key to schedule a game development cycle is to take ultra conservative estimates of how long it will take and double it.




Other than that make lots and lots of post-it’s of to-do’s. Pull them down one at a time. Finish them before moving on.

And do 30 minutes of work a day no matter what. If you get into a groove keep going. If not, take a break. Go play a game like what you are doing.

EDIT: Oh! And of course, FINISH WHAT YOU START! Even if it sucks. FINISH IT!

 

I've softened my view on this. If you've tackled a project that's just too big such as a full length RPG or an MMORPG -- and who doesn't when we're just starting out -- you're not going to finish it. Consider snipping off a tiny part and making an entire game about that. Look at Potion Craft -- you could look at it as just the potion crafting system of a much larger RPG, but it's a full game in and of itself.

 

Yeah, lots of big budget RPGS have a kitchen sink approach to gameplay features, but if you're a solo dev then I think you really need to focus on one core feature/ experience. Some people may see that as nerfing their dream game, but in the case of Potion Craft, this focus (on what would normally be a little side feature in an RPG) makes the game stand-out from the crowd.

 

One thing I would add is to do horizontal slice, for scope management. I'm of the opinion that many game just start the development process too early, and that the scope isn't fully uncovered and thus isn't manage properly, leading to planning issues and risk downward.

IMHO a thorough process should be like:

Pitching phases:
- Pitching the game idea
- Prototyping core mechanics in the roughest form to see if are feasible and work in the basic sense.

Mock up phases:
- "Diagonal slice" aka a fully playable portion of the game that show the intended experience, but still in the roughest form. It's a check to see if the mechanics works together at a basic level.
- The "horizontal slice", which the full playable game in its roughest form, to see if scope and progression works, managing progression of gameplay tend to be the main risk in game dev, character can still be capsule with zero animation, think of it like animatics in animation. Not everything has to be coded, if you can test without coding, that's fine too. The goal is simply to validate progression.
- Concept art to visualize the art direction and style.

Development phases:
- Vertical slices, aka uprezzing the diagonal slice to meet the concept art, it should tell you the relative cost to create one portion of the game, and since you have already the horizontal slice, you'll be able to evaluate and adjust cost, so that's why you iterate on many vertical slices in my system, it allows you to reign in cost but making informed decision for the next phases.
- Development, since you have the whole blueprint and most risk has been evaluated, you should be able to planned through it and have no surprised. You basically assemble everything to make the final game, without relying on elements of the mock up phases (only used as reference).
- Polish phases, the final touch to get the extra quality.

This structure is inspired by movie production, the core appeal of a movie is generally the story, and at every phases, the story is basically complete, except in increasing production quality. First is the synopsis, which is the complete experience in text form but in one page, then you have the script, which add dialogues, then you have the storyboard which had proto cinematography, then you get the animatics that had timing to the images, and finally you distribute the shoot to be done to multiple agents to produce them, which is the most costly part of the production and any change should be locked down by then. Development is costly in game, yet we start doing it before the whole thing is locked down, producing a lot of waste when change happen, or scope need revision. Validation steps help keeping waste to a minimum. How many times people have produce fully developed arts and effects, only to realize the game isn't fun and all is done for nothing. Don't produce things if the core qualities aren't validated.

 

many ways to skin the cat. since you and wife are working as a team i think you can define a roster of like 5 tiny games and build them one by one. Set a deadline for each game. Not more than like 3 months per game or so. Make whatever compromises to the game you have to in order to meet the deadline.

Do a your best job on the games but don't stress. Focus is on building the teams competency by identifying pain points and figuring out how to get around them on the next game.

I've never found too much nuts-and-bolts "this is how our team developed the game step by step." But even what I have found, it's not usually super useful because every project and team is so different. Small details make a big difference. There is considerations way outside the scope of just game development that can change the composition/disposition of a team so really the only thing you can do is start with small projects and continually reassess and update the way you are working with each new project.

I think the 80/20 rule is good to remember for time management. Spend 80% of time working and 20% "thinking". Perhaps not the right strategy for your big dream game that has 100 million dollars invested but if the goal is to develop a team, I think its more productive to rapidly develop experience, then reflect for a bit, then develop more experience. Eventually you get to a point where you have real confidence because you can envision a path on how to get a goal.

 

@TonyLi thank you for your suggestion

 

I'd look at what sort of games are the "average" output from both engines, considering studios/developers with similar scope of resources as you'll have.

I havent really studied it, but from unity i see basically all of the mobile games, tons of 2d platformers, a handful of 3d platformer/exploration games, a good amount of top down strategy types.

Unreal you have the 3d character focused games.

Just my quick hunch, but I think if you do a little more actual research you might get a better idea than just reading a couple individuals opinions.

Best thing to do is of course make a couple small games that include tiny bits of the genre you want to make in both engines. If you are quick worker that might take you several months, but your engine choice could make a real difference in your quality of work for years to come so its investment worth making IMO.

 

@BIGTIMEMASTER - I'm surprised you didn't link your blog post from this thread. You made some valid points from your perspective as a basically solo dev.

 

yeah that blog post gives a very brief rundown of my experience using both engines. but i'm not sure many indie devs will face same problems i have with landnav - its requirements are probably unique as its very niche game.

that post doesn't cover any of my gripes about unreal. But I haven't developed any yet. Been using it a few months now, gone a lot further than I did in unity... been very productive with no problems - as long as I am staying productive, I won't complain about minor things like "why is this button hidden in this hard to find context menu?" Little stuff like that is endemic to any software I suppose.

I was watching some youtube tutorials for Steam stuff today and got a little sidetracked with some unity related stuff on there. That's what got me thinking about what looks like the "typical" unity genres. All the tutorials and marketing stuff on youtube related to unity is almost always platformers, 2d stuff, or games like "the First Tree." I doubt developers of games like that ever notice the sort of issues I had with landnav. For them, performance problems is probably stuff like, "its laggy on 15 year old computers." My performance problems were more like, "the editor doesn't work."

but yeah, if you are making a realistic forest with a big terrain, go with unreal. There is no competition there.

 

Just to provide a counterpoint, since this a Unity forum after all, Unity games like Tarkov and The Forest have large, detailed environments. There are also some good assets on the Asset Store for rendering environments with lots of foliage. That's one of the differentiating features of the engine. The Asset Store has a lot of plugins that, used judiciously, can save solo developers a lot of time. Some of those features are just built into Unreal, but many others would require custom programming to accomplish in Unreal.