I learn slow but do get things done.

I'm a slow learner when it comes to programming. I struggle with some concepts and give up sometimes only to find that, an hour later, an idea comes to mind on how to tackle the problem. 90% of times I beat the problem and only seem to post when I'm in dire need of help. I still struggle with OOP but I'm getting better.

How do you guys code your way around? Do you have a plan beforehand on how you want things to go? Do you just steam in with no planning and see how things go?

What would you yourselves consider a good days programming eg. number of problems solved, bugs fixed, etc..?

I'm rather a beginner myself, and an extremely slow learner too. Usually I have an extremely basic plan, start to make it, then change it dramatically because of a better idea/lack of programming skill, and so I have to go back and change everything, and so I never get anything done.

I don't have nearly as much time for programming these days, so I'd say a couple of bugs and a few new features is decent for me. Keep in mind that I haven't even come close to creating a real game yet.

personally? I plan an entire project out. Whatever it is, I go through this process:

1. What is my goal? - What am I attempting to accomplish.. Sometimes it is something like "To make a game with PHP" or "To scare small children on halloween".

2. What medium is best for this? - In my other examples, PHP and photoshop for the game and halloween supplies and crafty things, pumpkins, and such for freaking out kids.

3. Think up a concept. - I'm not gonna keep going with the php game cause thats obvious, this year, I am going to surprise kids, so surprise is the concept.

4. What things can I have in this project that meet the concept? - this is brainstorming, some things for halloween are, a snowman stack of scary carved pumpkins and myself immitating a chair with a bowl of candy on it and a sign that reads "Please take some candy, I will be right back" (genius)

5. Finalize the design. - obvious.

6. Stage 2 of finalize design. - This is where I would psuedocode a coded design, draw interface ideas out, and create mock screens to work from... I make everything work on paper first. I also might do some proof of concepts if need be.

7. Implimentation. - At this point, I have a clear plan and goal, and this takes no time at all. Having worked out all the conceptual bugs, the programming bugs are all that are left, not having to decide which is broken means faster debugging.

8. Launch.


I follow this same basic formula for all my art, web-sites, and such.... but it really isn't this formal... I just work that way.

This is sort of, an after thought about what I do naturally.

I hope some of that helps.

for me, i code as follows.

1. decide what i want to do.
2. think about how to translate it to code.
3. write the code. if i get stuck stop and think a bit more.
4. when i have a solution goto 3.
5. when i get to here i am done.

... Mark... your code must suck, you used a goto in a 5 line "how i code" algorithm.

:P

Well, my style of coding was always to make it work regardless of how inefficient looking it was.

Some people like to have everything perfect, every step of the way. I'd rather just make it work regardless of the method - then much later look at tidying it up.

For me, part of the learning is the 'redoing' at a later date of what I have already done. I learn from re-writing something - it takes longer, but I find it works.

I like the brute-force approach - just code like hell - doesn't matter how good-looking or efficient the code is - as long as it does what you wanted. Then a month or so (even a year) later, program the thing from scratch and see how different it is the next time you brute-force it. Basically, you end up teaching yourself rather than trying to apply what other people are advising you.

I'm not the planning and analysing type. However, it is best to concentrate on one thing at a time.

I can't beleive I'm going to say this,

but I used to do it like Puki says.

Just last night in a coding session I pinpointed some areas of code that were unexcusable due to me just "hacking it in till it worked"- actually, it was transplanted from B3D, but the code in B3D was hacked in.

You can usually replace a 100-line peice of code that was hacked together when you didnt know what you were doing- with a 10-20 line peice of optimised code.

There is something to be said for having a working piece of inelegant code versus the most beautiful code you've ever seen that is only 10% done.

Me? I'm a hobbyist/beginner. I have the terrible tendency, and this extends beyond just programming, of attempting to run before I can walk. For instance, a MUD I'm designing is completely coordinate based (not too big of a deal, involved me learning about quadtrees and such) and includes such things as emergent behavior from NPC's (this will probably have to get trimmed), a system akin to atomic elements where all items are composed of various sub-particles, and these sub-particles have their own properties (such as melting points, bond strengths with other particle types, etc).

With the 'element system' I am trying to make an abstract 'chemistry' layer, which would allow crafters to create their own custom alloy recipes (e.g. heat element a to 1550 and element b to 1200, mix and stir for 90 seconds before quickly cooling and you'll end up with element x, super hard and light although slightly brittle). And this system is really just the tip of the iceberg.

Okay, I'll stop rambling about my game :) Anyhow, that's just a taste of my problem. The reason I label it a problem is because while I have no problem mustering the enthusiasm to spend hours of time thinking/dreaming up ideas and committing them to design docs at my current skill level there is no WAY I can implement a lot of the ideas. Of course, it's much harder to muster up the enthusiasm to learn all of the pre-requisite skills (and time) to actually implement my design, and so I tend to make slow progress. Slow progress = less enthusiasm = slower progress = putting the project on the backburner.

With all of this said, I think I'm going to spend the next week or two paring down my design into something that I CAN finish. Maybe with a decent sized project under my belt, and the fulfillment that the completion will no doubt bring, I'll be able to stay on track a bit more when I get back to taking larger bites.

I guess this didn't really answer your question very well. Excuse my cathartic verbal diarrhea. :)

Overview Plan then small plans as I reach each section. Also noting down any ideas/issues I don't want to deal with right now on the big plan so I can prioritise them later. If it was a business project I was being paid for, I'd do a detailed plan at the start (so I can estimate time + quote + discuss any potential problems early on). This would take approx 25% of the project time, with 50% code and 25% testing.

Somedays one big bug/problem fixed is progress, whereas otherdays 10-20 things done is progress depends on what you are doing of course. Spent 2.5 hours yesterday making my latest map pan + zoom in at the same time, wish it only took 20 mins but it didn't ...

In an ideal world, this is also what I'd do :)

Sometimes you find that the customer doesn't know much about what they want either :)

I have only ever finished one game - and I know why. While I'm a pretty decent programmer, I tend to try to do too much at once; I am designing a Roguelike at the moment and I tried to create the whole NPC structure all at once and kept getting in a complete mess, forgetting what does what and so on.
I decided this was the totally wrong and approached it from a different perspective; I am now coding it from a simple maze generator upwards and so far so good. *thumbs up*

At this rate, I should be able to finish it. (if you ever really, do finish a game though!)

I don't believe any good original game was fully designed before it was coded. Just get stuck in if you have a good idea.

I've never written down plans of any sort. Good old brain database gets used. Think, program, think program, etc..etc..

Definately in the "Just get stuck in" side of things :)

I agree with John 100%. Slightly off topic but Nintendo kind of played it by ear with the Wii not knowing exactly what they were aiming for when creating it. The whole team that worked on it though seem to be very happy with the outcome.

I think the same applies to programming. I myself am more of a spontaneous person who very rarely plans these things out beforehand as planning tends to stifle my creativity.

Jason.

If you don't plan, you can't draw a "Completed" line and work on extras at that point.

Why not?

Where is the "Completed" line if it was not planned?

you could plop it almost anywhere.

What I meant by it, is that most people would jus tekep adding features, rather than finishing. Not all, but most.

That doesn't follow at all. My games are completed when I say they are.

I'm not saying don't plan anything ever. I plan small elements and I have an overall rough idea how my game is going to turn out.

My main issue is with the idea that you make a complete game design and then write it. That doesn't work if you're making an original title. I'm sure you can design and code a 'match 3' puzzler that way, but you're not really designing a game as such; it's already been designed by someone else.

and all I'm saying is that most people aren't as disciplined as yourself ;)

I usually start with an idea. But start it small. If I wanted a tank in the game for example, I just get it to work. Then get the thing to do functions. Get that to work. After Im happy with it, I start adding more things. And sometime along that journey, I think of something EVEN better, and get that going. Every single time I layout my project, I usually change my mind about something. Add features, take em away. If I drew out the whole project and did just what I wrote down, I dont think it would be as fun. Always be open for change.

with BMAX i always try to make things self contained in a type as much as i can

i also plan out what i am going to do before hand, i usualy code for 4 hours straight that way and work the details out when i get to t

it only took me a few days to get OOP, i guess i am just a real fast learner

I've always had a random flash of inspiration and then immediately scribbled a few things using pencil and paper. No great plan, just a few jots that accompany my thoughts at the time. If I was to read them back, they would make no sense. I guess I'm just writing mnemonics to help me remember the creative flow.

Once I've got it straight in my mind, I know exactly how it should be achieved and so I go and research a few 'best practises' on the subject and start writing the code.

OOP greatly improved this thought process.

> Mark... your code must suck, you used a goto in a 5 line "how i code" algorithm.

hehe. you're funny DampeS8n. now what is wrong with using a goto?

Yeah, so that's why for business I made a full plan as it's supposed to only do the thing the client wants whereas for a game I have an overview and then plan each bit in detail as I get to it. Naturally then new ideas come along and original ideas turn out to be crap. You have to be flexible and chuck stuff out if it's rubbish. I agree with Cyg it's nice to make a "complete" game as soon as possible which is NOT feature rich so that it can be used as a demo/beta and then you can use any remaining time to put in extra features and make it cool. If you don't ever make a fully working version, then you'll be fiddling away on details yet still not have a title screen etc. This is the problem with my current game, the producer keeps putting in all this stuff without a) finalising/fixing existing stuff and b) completing all the main screens first. I've persuaded him to let me get the game "finished" and then we can prioritise all the extra features and bling that he wants adding.

I stick with simple games that are fairly similar in gameplay, or rather have gameplay that I have become familiar with the code required. Most simple arcade / action games have fairly similar 'main loops'.

Also - I tend to begin with creating the main gameplay functions by simply declaring the functions but not putting any code into it at first so that I can see how it should flow.

And one more thing - Loading/Unloading/Freeing resources - these functions are usually built in as early as possible and quite often are pretty standard across the games I've put together.

Hey John, just curious, did you plan out Naked Wars all at once or bits and pieces first. I wasnt around for the start of it, so i'm not sure how that process was. I'm very curious of the behind the scenes of the game.

No documents or anything like that. We had a game idea - which was pretty close to how the final* product turned out. My brother and I just started work and met up once a week to discuss the game and drink beer (we live in different towns).

*The game is still being actively developed. This is a great aspect of digital publishing - we can keep working on the game after release.

The "If it doesn't work - chuck it away" works for me... it's good to prototype - I used B3D to prortotype an idea, and am now using BMax to produce a 'multi-platform' app.

The journey to your goal is half the fun, but if that journey can be made a little shorter - I'm all for that. A good plan / design yadda yadda.....