First Game That Isn't a Tutorial - Looking for Feedback, Ideas and Tips

So as the name suggests, this is my first game that won't be a tutorial follow-along or a simple one-off designed to test how a mechanic is implemented. I have decided to build a game that is feature complete, with menus, multiple levels, the works. Something that feels like an actual product instead of mucking about.

That stuff comes later, as for now I'm trying to get my MVP set up and ready to code so I'd like to run it past some veteran eyes to see if they can see something that I cannot.

The basic idea is inspired by dungeon crawlers:
character with customizable loadout, stats, and skills
fights enemies of varying types
in melee as well as ranged combat
in environments with buffs and debuffs
in real time
in 2D

By my judgement my MVP should be:
character sprite
weapon sprite
movement
interaction with environment
interaction with enemy

Furthermore, if you could give me some idea on how the overall game should be structured in terms of game objects, scenes, etc. in order to allow for easy development that would be most welcome as well.

 

A tip based on a mistake I made when I finally decided to make something "for real" -- plan ahead for save/load from the very start. It's usually fairly painful to try to shoehorn that into the mix after the fact.

 

Related: really, seriously understand what everything in your game needs before you build hundreds or thousands of them. Learning you need a flag on every item in your game is not such a big deal when you have twenty items, but if you have sixty thousand of them you'll just want to kill yourself.

Basically, keep your game as small as possible until you've got everything you need. Otherwise you might find that making what you need means writing five lines of code, then editing your game objects for a month and a half. Followed by most of a year getting bug reports about the ones you missed.

 

You could have just said learn to write editor scripts.

 

Oh, those are where the bug reports come from. Like when you flag the "Double-Bladed Dagger" as two handed because you searched for "Double-" to save some time.

 

Fixed that for ya.

But you're right, like any serious software project, a little planning goes a long way.

The OP says "menus, multiple levels" and and lists MVP targets. I would suggest starting by creating a working project that is the simplest interpretation of these goals. I bet that effort alone will uncover new requirements that must be considered.

1. A working main menu (placeholders except New Game and Quit)
2. A working level with minimal game mechanics (move a little square around the screen)
3. The ability to pause that level to display the in-game menu (placeholders except Main Menu)
4. The ability to load the next level (the same minimal level)

What OP will be doing here is laying the ground work for the part that "feels like an actual product instead of mucking about"... get those four pieces working, then go back and implement a simple Save / Load on the main menu, and only then worry about the level mechanics and graphics and other stuff.

Unity makes it all too easy to dive right in and edit some fancy-looking level ... and then you don't have the slightest idea how to retrofit all the stuff that makes it an "actual product"...

For example, a working main menu and in-game menu implies the code behind the fun parts has to know when to ignore input -- a menu system temporarily "owns" the input -- whether that's implemented as a state machine or setting "global" static flags, or events, or some other approach.

When it comes time to build the actual gameplay, abstraction is your friend. Make heavy use of interfaces to define similar behaviors. OP didn't say anything about having other software dev experience but the dungeon-crawler wishlist are mostly goals that would be well-served by a carefully planned system of interfaces.

Don't be afraid to re-structure your Unity project folder hierarchy. My current scripts hierarchy lets me focus on different parts of my project and it took many iterations to "rationalize" it this way.

 

Good luck adding a flag to an interface.

So much this. A reusable shell is priceless. I've spent the last month working on nothing but the shell of my current project, e.g. the settings and options and message dialogs. It's all pretty ugly, but that just means I need to replace fonts and throw some artwork into the project, and that won't be the same from project to project anyway. And a working credits option means you can add all your required licence notifications as you use licensed material, which means not forgetting any on release and hence reduced legal risk.

 

My suggestion:


Get you one of these and use it A LOT.

Map out the project. List prefabs and scripts that you'll need. Make a timeline for development.

Also, never make placeholder scripts or prefabs. Prototype everything. Create a testing scene. Finish what you start.

EDIT: Playmaker is your best friend and the single best purchase you could ever make when starting out.