My thought is to try to scope it even smaller for your given timeframe. See how much you can constrain yourself on all ends. Couple examples:

• Two characters - player and enemy
• Single weapon behavior
• One component on the GUI
• No upgrades
• No loading or saving - player dies it's over
• PC or mobile only, not both (you'll understand why when you try to port)
• No editors
• 1 sound effect, 1 background music, 1 particles

Constraints breed innovation. Time is a great constraint, but scope can be as well. You'll learn a lot technically and about your development habits.

Just my recommendation. :)

If you were an exeprienced game developer with lots of time using Unity and were working on this fulltime, and the gameplay goal was for a very basic implementation of your idea... then I'd say you might just have a chance of getting all this done.

But, in reality you have like 0 chance right now. I'd say determine the absolute minimum gameplay that you need for your core idea, get rid of everything else, and maybe you can do that in 1 month. But, more likely it will take you 3 times as long as you estimated even then.

Also, dont think of restrictions are drawbacks, think of them as features that can lead you to novel new gameplay ideas, but best of all they can lead you to completing the project. After that you can try for a "version 2.0" or whatever using your existing code and your new knowledge.

Some important tricks when scoping/planning:

• #1.:
  Split the tasks into really small ones. A task which may or could take more than two workdays is bad. Split those into multiple ones or add sub-tasks where each is less than a day of work to further clarify what has to be done and how long it could take. A simple design doc which has the core concept and even extra ideas to explore written down can help tremendously here!
  
• #2.:
  If you don't really want to throw out some stuff but they may be time-consuming tasks or they may not really enhance the design/gameplay etc... then flag them as "not-important" or "nice-to-have" and prioritize the important ones. Only start these tasks if you already have most of the important tasks done and you are still in time or you really really really want to make some of them...
  
• #3.:
  Order your tasks organically with dependencies in mind and not as a simple list (can be in a list format in a text file, but logically have a graph/tree-like stuff). For example most important first-and-foremost tasks required to actually make the working prototype or vertical slice should be the first bunch. The second bunch are the production related jobs, consisting of tasks to fill the game with content and extra features. The third bunch is polish/finalization... You get the idea!
  
• #4.:
  Work in phases/sprints or something like that and organize your plan to support it. E.g.: you have a month, each week is a phase. At the end of the first week the game should be playable, all basic features should be implemented. A the end of the second week a bigger part of the planned content should be made. The third week can be used for extra content, extra ideas, extra features. The last week should be finalization, polish, packaging and QA. This also helps if you are late with some tasks, if you can't complete the first two weeks worth of tasks in two weeks you can throw out some from the third as those should be "nice-to-have" ones (the last week is important do not neglect those tasks).
• Always prepare for underestimation. You will not be able to correctly estimate the length of each task, even if you divide them into small few-hour long ones.

These "tricks" may need a workday to actually implement, like preparing a small design documentation up-front, and making in-depth organized plans with sorted tasks based on importance, and divided into phases, but it can make all the difference. If you don't spend time on planning/scoping you can easily end up starting a three-month project instead of a month long one, only realizing it after a few weeks and loosing all your motivation immediately :( ...

+1 extra:
Even learning related tasks can be and should be planned as I see your case has a "have a better understanding of Unity" goal too. E.g.: if some parts are totally unknown (how to do the AI in Unity for the hawks) you can plan watching official tutorials about the topic and checking out other template project with related parts to have a better understanding and maybe even prototype a given feature.

Good luck :) !!!

My thought is to try to scope it even smaller for your given timeframe. See how much you can constrain yourself on all ends. Couple examples:

• Two characters - player and enemy
• Single weapon behavior
• One component on the GUI
• No upgrades
• No loading or saving - player dies it's over
• PC or mobile only, not both (you'll understand why when you try to port)
• No editors
• 1 sound effect, 1 background music, 1 particles

Constraints breed innovation. Time is a great constraint, but scope can be as well. You'll learn a lot technically and about your development habits.

Just my recommendation. :)

While some of the aspects I listed are unknown (especially when it comes to the potentially porting to Android, and the wave editor), a lot of the other things should be fairly trivial to me.

I will definitely keep in mind I might have to drastically cut down on features as I get closer to my deadline, but I'll stay slightly optimistic for the first week, at least :) I don't think I mentioned this anywhere, but I'm expecting to invest between 25-40 hours per week on the project, depending slightly on my weekend moods.

If you were an exeprienced game developer with lots of time using Unity and were working on this fulltime, and the gameplay goal was for a very basic implementation of your idea... then I'd say you might just have a chance of getting all this done.

But, in reality you have like 0 chance right now. I'd say determine the absolute minimum gameplay that you need for your core idea, get rid of everything else, and maybe you can do that in 1 month. But, more likely it will take you 3 times as long as you estimated even then.

Also, dont think of restrictions are drawbacks, think of them as features that can lead you to novel new gameplay ideas, but best of all they can lead you to completing the project. After that you can try for a "version 2.0" or whatever using your existing code and your new knowledge.

A few points:

While not incredibly experienced with Unity, I have used it a bit before. I've also got many years of experience outside of Unity.

I'm also not expecting super high-end quality on this (especially when it comes to my horrible art!), but at least more polished than just a thrown-together prototype.

It will be very interesting to see how far I get, even if my goals are quite ambitious as they stand now.

Some important tricks when scoping/planning:

• #1.:
  Split the tasks into really small ones. A task which may or could take more than two workdays is bad. Split those into multiple ones or add sub-tasks where each is less than a day of work to further clarify what has to be done and how long it could take. A simple design doc which has the core concept and even extra ideas to explore written down can help tremendously here!
  
• #2.:
  If you don't really want to throw out some stuff but they may be time-consuming tasks or they may not really enhance the design/gameplay etc... then flag them as "not-important" or "nice-to-have" and prioritize the important ones. Only start these tasks if you already have most of the important tasks done and you are still in time or you really really really want to make some of them...
  
• #3.:
  Order your tasks organically with dependencies in mind and not as a simple list (can be in a list format in a text file, but logically have a graph/tree-like stuff). For example most important first-and-foremost tasks required to actually make the working prototype or vertical slice should be the first bunch. The second bunch are the production related jobs, consisting of tasks to fill the game with content and extra features. The third bunch is polish/finalization... You get the idea!
  
• #4.:
  Work in phases/sprints or something like that and organize your plan to support it. E.g.: you have a month, each week is a phase. At the end of the first week the game should be playable, all basic features should be implemented. A the end of the second week a bigger part of the planned content should be made. The third week can be used for extra content, extra ideas, extra features. The last week should be finalization, polish, packaging and QA. This also helps if you are late with some tasks, if you can't complete the first two weeks worth of tasks in two weeks you can throw out some from the third as those should be "nice-to-have" ones (the last week is important do not neglect those tasks).
• Always prepare for underestimation. You will not be able to correctly estimate the length of each task, even if you divide them into small few-hour long ones.

These "tricks" may need a workday to actually implement, like preparing a small design documentation up-front, and making in-depth organized plans with sorted tasks based on importance, and divided into phases, but it can make all the difference. If you don't spend time on planning/scoping you can easily end up starting a three-month project instead of a month long one, only realizing it after a few weeks and loosing all your motivation immediately :( ...

+1 extra:
Even learning related tasks can be and should be planned as I see your case has a "have a better understanding of Unity" goal too. E.g.: if some parts are totally unknown (how to do the AI in Unity for the hawks) you can plan watching official tutorials about the topic and checking out other template project with related parts to have a better understanding and maybe even prototype a given feature.

Good luck :) !!!

Good points in all.

#1. I'm definitely having more fine-grained tasks that I work on, but I wanted to list the more general overview than each individual task in this journal entry. That said, a lot of the things listed are somewhat trivial (e.g. scrolling background), so some of the points listed equate pretty directly to tasks.

#2. Some of the items on my list are certainly lower-priority, and will be sacrificed accordingly if need be.

#3. Like #1, this is something I'll be doing, but wasn't going to list in detail for this journal entry :)

#4. I'm not super keen on this setup of phases/sprints, so I'll have to give this a bit more thought when it comes to how I want to handle it. I'll probably be posting a bit more about this later on.

#+1. It's a bit unknown to me. A lot of these things I know how to do in the general case, just not using Unity. It might be as easy as finding the correct API for it, or it might be places where I'll need to dig a bit deeper -- making it very hard to estimate to any meaningful extent.