Mouse Flight Project Post-Mortem + Lessons Learned

News & General Discussion
1

OK so 2nd post of the morning!

As its pretty certain that work will not continue on the project its clear that I’ve learned a few things.

FYI: I’ve not done work on it in over a year (maybe two?).

Lesson 1.
Learning to code, and Unity’s API is important to creating games with it (if you are specializing in game code); but this does not mean that you ignore proper design workflows!

This means analyzing functional/nonfunctional engineering requirements, putting together UML designs, and flowcharts. You should be doing these things at the very least to get a good idea of what how you’d like the code to achieve what it needs to.

Haste makes waste, and failing to plan and design is planning to fail!

Lesson 2. When putting together a game you can use primitives to get systems emplaced. However make it known that it is WIP to demo viewers, and at the very least give it some look and feel to make it a game.

Lesson 3. Set deadlines, goals, and organize your project!

This was one of the biggest problems for myself. Personal stuff aside, deadlines goals and organization was something of neglect to me. I actually told people that I cared not for organization.

Hope this helps, though much of it may be obvious.

2

No replies…?

._______.

3

Your first post is vague and has no screenshots or anything. We still have very little information about the project you produced. This is written like a blog post that had a previous post that explained the experience in detail.

I would be interested in reading more about your experience.

4

The Last update:

A bit earlier:

The very first video:

Apologies for that @spryx I assumed most had heard of it but it seems the Unity crowd has changed lots…

1 Like
5

This only looks like a prototype though. Are you done with it?

You should challenge yourself more. You’ve got the bones of a game here, apply lessons learned on the next step of polishing it into something more complete.

Instead of “post-mortem”, this could be “phase 1 reassessment.”

2 Likes
6

I have to agree with @BIGTIMEMASTER here. You have some really solid mechanics going on and a good idea. It may just be a little bit too soon for a post-mortem. This still looks as though it might be in the design stage. Admittedly, I have many projects on my own that get to this point. It is natural to feel some burnout after you have worked on a project this long. You now are getting a solid picture about the amount of work it will take to finish everything. I would encourage you to take a second look at the project when you feel a bit refreshed.

2 Likes
7

<3 you guys thank you!!

8

yeah you gonna find that you come to a point where you cannot continue forward for whatever emotional reasons. but you have to imagine, everybody else comes to that point too. Most will quit, start something new. Never get anywhere. Then quit big time.

If you have the good habit of finishing what you start just on principle, you gonna rise above 90%. Everything you are doing you have to view as self-development. This way you are constantly investing in yourself. Never wasted time.

So even if your only goal for the project is “extend the limits of my patience,” or “get over the fear of publishing ugly artwork”, that is a very worthy goal that will serve you well in teh long run.

3 Likes
9

That said, don’t feel afraid of moving on from this particular project. Completing stuff is important, but if the best way for you to finish something is to start a new, smaller project or one that better suits your skills… do it.

But also, finish it. :wink:

2 Likes
10

To quote a certain AI Construct:

“I’ve already begun…”

11

I’ll play devils advocate here, I don’t think you should finish this unless you have a solid plan for what the rest of the game is.

I don’t mean to be harsh, but this isn’t a deep enough commitment at this point to even begin talking about seeing this through.You know this by looking at your versioning 0.1.3 – you know this is barely a tenth of the work (it’s actually less if you’re looking for a really complete gaming experience).

How deeply you invest in a project should really depend on you, what your goals are, and what stage you believe yourself to be in your development.

If this prototype required significant amounts of time on your part to complete, then most likely you need to scale back, reassess and refocus on strengthening your grasp on the basics.

So, if that took a month to produce, I’d say you’re probably looking at 3+ years to complete this to a polished state. The work load outstanding is tremendous, and the difficulty curve goes up.

I know this runs counter to most of the advice you get on these boards, but it really comes down to the following:

  • Sit down and ask yourself what your goals are.
  • Look at how long it realistically takes you to make progress.
  • Figure out how much time you are willing to commit.
  • Then reassess your goals, are they realistic?

If your goal is just to mess around and have fun building stuff for the sake of it, then don’t be afraid to embrace that, and use that freedom to scrap whatever project you want, whenever you want.

If your goal is to make a game that doesn’t suck, be honest with yourself about the chances of that (very low) and the time required (years).

If your goal is to be a professional, don’t look at the one in a million chance that you hit big, look at tiny, incremental works that build your skill set and knowledge base, require minimal time and can start to bring in income.

1 Like
12

To give some perspective, this was my first video

Actually this one was before that

Its no the point though, now we are here (more or less, its an old clip but shows level of polish) and we are no near at final version. Point is your idea of post mortem is far from what a real post mortem are, imo

1 Like
13

I mean post-mortem means after death, right? This thread’s purpose is just to illustrate that I have stopped working on it and what I’ve learned from the project. You’re arguing semantics. Why do I find myself having to defend my position over trivial things?

2 Likes
14

Yes, the adverb does. The noun on the other hand means poking at a dead body to see what caused death. :stuck_out_tongue:

2 Likes
15

It appears you have have been working on it for 4 years. Definitely time to give it up as a project that you intend to ship. Though not entirely tossing it if you intend to make something similar and want to use it as a testbed. I have a project that I have been working on for years that will never launch, but I use it all the time to create new tools, explore ideas and concepts and test unity features. It is a fully working game, so able to use if for solid testing.

But also the point of a postmortem is document what lessons you learned in process so future endeavors you can build upon. In your OP, your “lessons”, are all 100% common sense knowledge. If it took 4 years to “learn” that you can use temp assets, that you need to learn coding and that you need to set goals… well you should probably take a look at your learning process. Millions of people have built games, or done related projects. Thousands have documented them. Read a book on game development, take the advice in it as “already learned” and apply it. 4 years is enough to learn how to code, not just learn you need to learn. Build on the work and knowledge and experience of others.

3 Likes
16

True, I guess for me it’s just more interesting to discuss post mortem for a product that went a tad longer in development. Otherwise we could do it for any POC we do :slight_smile:

17

Holy shit, disregard my advice. I figured you’d been working on this a few months.

You can learn much faster by doing less stuff yourself from scratch and instead trying to learn from all the resources people are puttinig out there. That way catching up to what others know already instead of reinventing wheels.

18

What would be wrong with that?

The point of a POC is specifically to explore a concept. There’s little point doing that if you don’t follow it up with some kind of evaluation or review.

1 Like
19

Thats more a classic retrospective

20

It’s good advice though!

A lot of people say that you shouldn’t spend too much time just watching tutorials or w/e, and it’s sound advice. But I think the nuance is that you need to spend ALL of your time watching tutorials and learning every single thing you can from others, BUT you need to practice each new thing you learn thoroughly. Not just follow the step by step but actually test what you learned with your own application.This way you run into those issues that force you to develop your own problem solving skills, but at the smae time you ain’t lost in the woods, starving, not realizing civilization is half a mile to your east.

This way you don’t waste a second slowly learning something that has already been learned by somebody else. They can teach you faster. And you pick up lots of different ways of thinking and solving problems than if you just grind on your own.

Anytime I have to do something new, the first thing I do is scour the web to see if somebody else has done it already. For the experimental phase of my next game, I have spent two weeks just going through all kinds of third party tools, and combing the web to find different artist’s styles. The goal is to find the best solutions for me that already exist as much as possible. Because I wil never finish if i try to do everything on my own!

To give more example, I’m using trees from two different asset packs. I dissect them, using bits and pieces to form my own trees. My dog model is modified from the wolf model in Call of Duty. The rig is based from that as well. I didn’t need as complex, but it still gave me a good start. The animations I watched some frame-by-frame animations from the guy who animated Game of Throne dragons and just copied what he did. Mines obviously nowhere near as good, but it’s a helluva lot better htan if I just winged it on my own.

For shaders, I ain’t got time to learn to write shaders. That’s not my specialty. So I gather a bunch of different shader packages, try to figure out which parts I need from which, and then I got good idea how to start my own. I tried that and still found it too time consuming, so the next step was to write to a guy who teaches shader writing and I pay him for a couple hours time to run me through some basics. Just enough that I can modify what I already got.

Literally nothing I start from scratch. First step is always to leverage the fact that we is hoomans and can benefit from generational knowledge.

One other important point: Don’t compare yourself to yourself. Don’t compare yourselfl to your peers. Compare your work to the best work in the medium. The goal isn’t to match it, obviously, but that is the standard by which you judge yourself. Obviously your mindset cannot be, “I have to be the best!”, but rather, “how much percentage of the best can I reach in the timeframe I have?”

Anyway, it’s good that you shared lessons learned and I’ll look forward to seeing how you apply them to your next work.

2 Likes