Small Project Planning (Advice Wanted)

Started by
5 comments, last by Deckhead01 4 years, 7 months ago

Hello!

I have had an idea rolling around in my brain for some time now, and I think I'm going to work on it as a hobby until something comes out of it. The project goal is fairly large for my skill level, but I'd like to break it down into much smaller stand-alone projects to finish smaller proofs of concept. But before I start, I'd like to pick the brains of the much more experienced, and that would be this forum.

The ultimate project is going to be a top down game with pixel graphics and text boxes. It will have the look and feel of a top down management style game, with smaller minigames attached.

It's been some time since my programming experience was fresh after school, so I'm not even sure where to start. My questions for the forum are the following.

What language should I be looking to code in and why? What are the pros and cons? I have knowledge of c++ and java, and am willing to learn, but i don't know what I don't know about picking a proper language for this project.

Should i be trying to develop a tiny lightweight engine for something like this, or should I just jump up several steps and use something like Unity?

Any and all advice would be much appreciated.

If I'm not being clear, please let me know.

Advertisement

RuthlessRecursion said:
What language should I be looking to code in

Moving this to the appropriate forum. Ruthless, while you wait for more replies, I recommend you click the link at left where it says “New to game development? Get started here.”

-- Tom Sloper -- sloperama.com

@Tom Sloper Thank you

@ruthlessrecursion Hi!

Breaking larger project into small sub-projects is somewhat a must. This is a well known fact. The hard part is - how to split it, it will be different in corporate environment, or in small team, or in your hobby project.

For hobby projects (this also generally counts for small teams), it is absolutely necessary that you can - at any point - build and run project seeing the game run. This is very important mainly due to one thing - visually seeing the end result all the time. It keeps your motivation on the project, and you have a chance to finish it.

This should bring you to “How to split tasks?” … at the end of each you should end up with another functional item in your project that is directly visible (for example - not for management game, but some other):

  1. Simple environment, i.e. terrain
  2. Player character and movement
  3. Obstacles (like tree, building)
  4. NPC character
  5. Interaction with NPC characters - dialogs

By building this and structuring in a code, you create a code base, which is essentially an engine. You may want to make it full featured engine in future (by adding tools - which are often more complex to write than whole games), although I would recommend you building a game (assuming you want to build a game, not engine).

Each of these tasks can be also split in multiple tasks (with various notes - giving you hints how to implement, throw in anything relevant when writing these up - it is likely you will change/remove/add some during the process):

  • Simple environment
    • Implementing World
      • Adding a way how to describe world (text file for example)
        • Notes: Text files contains value in each byte, representing which tile is loaded
    • Implementing Tile (World is composed of Tiles)
      • Rendering it with AwesomeRenderingAPI
      • Loading tiles from resource files (PNG)
      • Specifying tiles properties (walkable, non-walkable, etc.)
        • Notes: Each tile has control file which specifies walkable/non-walkable and resource file PNG/JPG/…
    • Implementing Camera
      • Allow for zooming, and moving around

At the end of this task, you will have a way of defining world, and displaying it.

You can also use some Task software (like the Todoist, Wunderlist, etc. … no ads intended - there are TONS of those online and offline), to keep track of your work.

I hope this gives you the idea, how I split tasks even for small hobby projects (you can add lots of additional complexity, useful especially when working in teams, but even this, as the bare minimum project management, is quite useful … and most importantly easy to track, and fast to use).

Which brings me to what technology you want to use. And I will state right away - it doesn't matter. This is up to your decision, few examples:

  • Use javascript and webgl, writing basic library for it is straight forward, and you can quickly prototype and run it in browser
  • Use C++ to write windows based application, apis are your choice and might be based on target architecture (F.e. are you targeting Linux or Windows … or something else?)
  • Use C# and Unity, which saves you a lot of time you would be implementing renderer, etc. … and let's you focus entirely on gameplay, additionally gives you a useful editor
  • Etc.

Note: You mentioned that it is going to be management game, such games tend to have heavy user interfaces. You will have to consider this, as writing a custom UI from scratch … tends to be quite time consuming (from experience).

My current blog on programming, linux and stuff - http://gameprogrammerdiary.blogspot.com

I'd recommend you start MUCH smaller and don't start by making your dream project.

First learn how much you can get done, and learn how to do the parts that you know you don't know.

You write that you don't know where to start. Break it down. Do you know how to make a graphical game? If no, go get some game engines --- preferably an engine designed around the types of game you want to make, perhaps a variety of JRPG engines --- and figure it out. Then figure out how to build text boxes and pieces you need. Then figure out how to make minigames.

For some people it is helpful to try to do things gamejam style. Do everything you can on a new project (not your dream game) for one month. Cram it all month. At the end of the month you will have some experience with the tools, experience building some of the systems, and you'll have a better idea about estimation.

Then get a second project the following month, based on what you accomplished the first month, trying to learn something else that you didn't know.

Repeat until you have enough knowledge to properly scope out the project you want done. Then, after you know the core of what needs to happen, you can start on your dream project instead of learning projects.

I wrote a fair amount about this very topic just recently. I come from a project management background and also a developer. I wrote about managing your scope here, and also about planning your game out here. I'm always after feedback and love games, so let me know if there's anything I can do to help you out.

This topic is closed to new replies.

Advertisement