Best way to work through a project(?).

[Nux]

Until recently, the way I've always worked through project (not limited to GML) was to do everything at once - By building up the same project, gradually adding features as I progress.

I used to do this technique (as well as a sprinkle of improvisation) on anything I programmed in Visual Basic and Python. This eventually ended up producing somewhat of a stiff, complicated, working environment, where I'd weave and nest features within each other, creating a bulky amalgamation of everything within my project; nothing has structure.

Therefore (getting to the damn point), I've began decomposing my projects - splitting the features into their own sub-projects. I then create a fresh project which I focus strictly on that feature, and nothing else. Then, when I have completed a feature, add it in it's entirety to the main project (similar to how a team programming system works ... except with a single developer). I find this technique a lot better than simply winging it, which I'm guilty of, since you can just pinpoint a feature without having to search for it.

I was wondering what your preferred ways of tackling a large project are, and possibly any advice you have to give about efficient development.

EDIT: sorry I found a post exactly like this, so I'm just going to strike everything and imagine I never made a post.

EDIT again: Yal, you made your post as soon as I Edited! I'm really sorry i thought nothing would happen, i'll un-strike the text again

 

[Yal]

Write recursive to-do lists, and arrange stuff in folders by purpose (e.g. an enemy folder, a controller folder, a terrain folder and so on, for every applicable resource). Whenever you start getting more than 25% of a screen's worth of pure listing, you should consider splitting up in two or more categories just so you can find stuff more easily - the main thing a disorganized project suffers from is having stuff be hard to find.

As for "recursive to-do lists", I mean that you should plan what you want to have in the project early on, but in a very coarse level of detail (to leave room for creativity and unforeseen changes). Break everything down to a more concrete level right before you start working on it, and try to keep going until you reach a point where each step becomes trivial to overlook.

So I guess the TLDR is "plan before you do stuff", a little bit of planning adds a lot of structure - even if your plan sucks, at least you have some sort of consistent system you can find stuff with before. Also make sure to learn from your management mistakes.

And I agree, making subsystems in their own small projects makes it a lot easier to import the relevant bits later. I've taken a habit to reuse scripts and sometimes objects from other projects, and it taught me to start making very self-contained stuff in a new way rather than tailoring something for a single project and losing all flexibility.

 

[Nux]

Thanks for the reply!

I'll admit, my planning has been terrible ever since I started this large project I'm working on; so I haven't really got very far. So I'll definitely apply what you said about breaking

everything down to a more concrete level right before you start working on it, and try to keep going until you reach a point where each step becomes trivial to overlook.

...since most my planning has just been somewhat along the lines of: ☆.｡.:* FEATURES I WILL NEVER ADD .｡.:*☆
This is because I get very carried array with ideas, but never actually add them; I'll follow your advice and build a structured plan of everything I want to be added - with some extra room left for anything I come up with along the way.

When I have planned, it's worked out very well, for example, one time I spent a large quantity of time trying to solve a problem through pure luck (changing variables)... and then I opened good 'ol Microsoft Paint, and came up with a solution in a fraction of the original time spent. But, I just think I'm lazy. :^ )

 

[Electros]

One small tip - in my project spreadsheet, at the end of a session I always try to flag up a "Top" / "Next" item - so when I start the next session, I can pick up straight away where I left off from, without having to lose time getting back to where I was.

 

[Nux]

<post>

That sounds like a good habit to get into. I'll keep it in mind when I start planning

 

[EncomLab]

My current project I used a prototype for the first time and it helped greatly. On my previous projects I would concurrently develop my art assets as "shipable" while still building out the rooms/mechanics/etc. This time I built almost everything as solid colored squares/circles and blocks. Once I had the rooms, mechanics and most of the programming in place I started going back and replacing my sprite assets and backgrounds with "finished" ones and adding in sounds, etc. This really helped me not get overwhelmed by trying to do it all at the same time.

 

[Nux]

My current project I used a prototype for the first time and it helped greatly.

Ah yes, iterative programming. I can't say that I've ever used it.
Jokes aside, I actually used to use shapes, but found it hard to visualise things.
I might go back to it, it is a more logical way of tackling a problem (not creating thousands of sprites you may or may not use in the final game).

 

[zircher]

I'm a big fan of journals (the pen and paper kind), they allow me to work and design off line. I create big ol to-do lists with check boxes so I can track progress. Basically it is a method for taking big chunks of the project and breaking it down into smaller bits (or sprints if you like Agile.)

 

[Cpaz]

Personally, I have a categorized "todo" list, separated into "major" and "minor" additions/changes. This is especially useful when I'm lacking inspiration for a "major" feature that will require at least a few days worth of work. I can can just work on a few "minor" changes/features while a get my bearings and properly think through this "major" feature.
Granted, based off of your experiences you've mentioned, this might not work so well for you
I will suggest you jot down a dev document, listing all of the core functions and features that will be the primary focus of the game. From there, you can build an internal guideline
for features you may want to add.

But for art assets: recently, I've been working on assets long before I need them, just so I can change them over time and get the right feel.

I'm a big fan of journals (the pen and paper kind),...

Yes. I HIGHLY recommend a sort of journal or devlog to pace yourself, and get a perspective on what you've done over a period of time. I myself post public devlogs and they not only help me keep track of myself, but also inspire me to an extent (at least to the point of "oh yeah, I actually did something!"). Though, it imagine it wouldn't need to be public if it doesn't need to.

 

[Nux]

Spoiler: Rabble Rabble Rabble Rabble

"recursive to-do lists"

project spreadsheet

I create big ol to-do lists with check boxes so I can track progress.

Yes. I HIGHLY recommend a sort of journal or devlog to pace yourself

Wow, lists/structured data are really popular among people.
I never use them because I'm so used to Rapid Application Development that planning is too slo 4 mee. But, it definitely seems like the way to go, since RAD doesn't work as well for large projects.

I had a public devblog, once, I deleted it because it wasn't a very good one (back when i was a newbie and still used two objects for arms, instead of drawing them dynamically - I know, blasphemy).

 

[pixeltroid]

at work I use post it notes to organize work.

notes on Post-its are like lists that can be rearranged and moved around.

To my eyes, seeing a wall full of well arranged post-its gives me a "birds eye view" of the overall project.

 

[Never Mind]

DISCLAIMER: My post here isn't so long because I think anyone needs it. It was more from the fun I had reading this thread. No obligation to read it

I think it's also useful to take a look at tools people have created to help with developing other art forms.
For instance, people have made a lot of things to help with writing books.
I can think of similarities between writing/editing a book, and organizing and executing a game project. Especially because I think games are basically just a combination of other mediums.
If you're going for realistic characters and a compelling story, the SnowFlake method, and bubble charts may come in handy.
In writing, ruff drafts and brainstorms are later chopped up and edited down. I feel like people constantly have to chip away at the ideas to really figure out specifics.

If we already knew the details about exactly what we're trying to make happen, it would be really straight forward.
I think there's similar problems in lots of creative fields, you only sort of know what you want to do at any given moment.. but work on figuring out little specific things that you know you do like.
For instance writing music for / as a band. It's an organizational nightmare. There's too much freedom. You almost need to start with some random constraints just to get creative juices flowing.
Figuring out a few key things you like, and are moderately committed to is really powerful.

I suggest gathering your resources together. It doesn't have to be for a huge project.
Just take a moment to go through folders on your computer, notebooks and drawing pads, pictures on your phone etc. and look through a grip of them. Try to consciously analyze them.
Ask yourself questions. How could this help my game? Could a character could wear this? Does it look like a weapon? Are there any textures or shapes here that I like? Could this be a character? Could this be a place in the game?
Remember your not only looking for digital / physical images. Your listening. Your feeling. Is there a certain feeling about the colors or sounds in this work that I want to be in part of my game?
If you want to include some dialogue.. look through your journal. Listen throughout the day for funny little things people say that add to their characters. Go to the mall. Watch people. Write things down.

You don't always need a large number of resources. Just enough to work with, until you find a direction you want to go in.
Once you have your resources laid out, I like to both make iterations and narrow things down.
Start making new versions of resources.. try to expand on good aspects and minimize bad. Then compare the old one to your new version. Try to ask questions.
Look at a resource for a while, then look away and try to recreate it. See which parts you remember and what parts don't stand out and consider why that may be.

Eventually you'll need to start laying down tracks. You may end up with a few ruff draft project files, but that's okay.. don't get too committed and don't put your main notes or resources in the project folders.
I find the more times I have to restart a project file, the cleaner, more organized and easy to understand they become. Keep back up versions!

Try to keep notes about things you learn along the way. Try to find your own way of writing / notating game theory on paper and try to logically work problems out before you go to actually code.

Sometimes when playing with resources I have really small ideas. Sometimes problem I want to solve, or a specific thing I want to try to make happen. As long as the motivation is there, I don't think it matters too much.
I find that things that are really simple and still good are usually bi-products of other things I'm working on, or just plain happy accidents So I tend not to worry too much about whether an idea is perfect or not.

It can take a lot of time to organize a really grand scale project.. especially for us individuals.
I think by getting paint on the canvas, analyzing it, experimenting with it, improvising it and trying to be patient it has helped me to learn my own work flow and creative process more than anything. Taking the time and have fun!

 

[zircher]

Wow, lists/structured data are really popular among people.
I never use them because I'm so used to Rapid Application Development that planning is too slo 4 mee. But, it definitely seems like the way to go, since RAD doesn't work as well for large projects.

I feel for ya, I used to be a solo VB programmer and it was pretty much shoot from the hip and git 'er done programming. But, I was eventually moved to a huge Java project and you can bet that planning was actually more important than coding. The bigger they are, the more planning will save you from having to trash and redesign things in the future [as well as to keep things from breaking in production.]