This topic is 3459 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Ok, just wondering what peoples programming styles are? Are you someone who plans everything before hand and make sure that you can think of a solution before you start programming. Or are you someone who doesn't plan much and dont try to find a solution until you reach the problem. MY style Me, I tend to make notes on my game before I start, such as features I would like to include etc... I don't worry about if the solution, once I have enough notes on what I want I start programming and work my way through the features finding solutions when I am presented with a problem.

Share on other sites
Depends on the scope and nature of the problem.

Generally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

The key there is being sure to break problems down into ~3 hour chunks of work at a time.

Share on other sites
I usually delve into programming first.Code a few hours like mad to implement what I want.Then after getting the result and messing everything up I start cleaning things up :)

Share on other sites
I do this

Quote:
 Original post by Black KnightI usually delve into programming first.Code a few hours like mad to implement what I want.Then after getting the result and messing everything up I start cleaning things up :)

but am working towards making myself do this

Quote:
 Original post by TelastynGenerally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

Share on other sites
I often make notes and sketches first - it's a habit I developed during my time as a level-designer. It works for programming too so I've kept it. Then, depending on the task at hand, I'll make a prototype, or if I'm familiar with the subject, I'll start writing production code right away.

Share on other sites
I spend time thinking over problems and deriving possible solutions in my head then, once I think I've found one that's satisfactory, I prototype the solution in a project all of its own. The idea is that not only do I begin coding with a near-ideal solution in mind but I'm forced, due to the prototyping, to keep things modular and loosely coupled.

If the prototype fails initially, I either refactor it to make it work or go back to thinking up new solutions with the added knowledge of what didn't work from the failed prototype.

Share on other sites
Devil May Cry's Smokin' Sick style!!!

Share on other sites
I usually try to split the task into several smaller ones, this usually results in modulate code that is far easier to test than a full blown class that does almost everything and due to the nature of modules it also makes for shorter compile times.

Before I start writing any code I try to fully understand what I am going to program(the algorithms, some potential pit falls...)
after this I examine the algorithms to get an idea about which containers to use ... and finally I try to get rid of redudant computations and if possible try to rewrite algorithms to make them suitable for parallel processing, you know the many cores systems we will have in a few years.

Some of these steps can t be thought of in advance, so you will have to refactor your code once its working.
The final result is usually pretty reuseable code and saves time on the long run.

Just a note: Never start to work on multiple modules of a task in parallel, finish one first, its far easier to debug one module, than to find bugs that are caused due to interaction of incomplete modules.
Just write some simple helper modules if you really need them to get the previous task done at all.

Share on other sites
Quote:
 Original post by TelastynGenerally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

I thought I was the only person who thought about programming in the shower! [smile]

Share on other sites
Game wise I take a more flexible and agile approach. First I will write down a general overview of the game. Basically a anorexic design doc. It is only about 1 paragraph or so long and lays out the basics of the game. IE read my journal here the entry about the orbis overview. I will then implement that stuff and I have the main core of the game. From there I go and start adding features to make the game more full/polished. The reason I do it this way is because I find it easier to manage and develop a project without knowing everything you want it to do. If I start doing a severely detailed design I get carried away and it make the project exponentially harder to work on. I would rather see the project evolve in a flexible way which helps prevent features not making it or realizing the feature is imposible because you feel the flow of the game peice by peice. I think of code as art not science :D

Edit: Am I the only person who has solve a very hard to solve programming bug/error/and or algorithm in their sleep? Oh yes I think about programming in the shower, bathroom, and at work(rather dull job) all the time.

Share on other sites
Depends on what I am doing. If it is more of a technical task such as (for the sake of argument) developing a generic link list, I usually sit down with a piece of paper and work through all the requirements and how it is going to work.

If it is more of a gameplay/experimental task, then I get it working in the quickest way possible such as creating a bunch of static/global variables just to see if the idea works and be able to tweak it easily while it is running. Once it is proven that it works, then I go back to clean it up and implement it properly before submitting it to the build.

Share on other sites
I usually work out the ideas in my head for a while, then work up the code. If I think the task will be kind of complicated or confusing, then I'll try handwriting a draft or some pseudocode first.

Share on other sites
There was an article here on Gamedev about Zero-Defect Software Development, I use that now.

Share on other sites
My style is to create the classes and think about the structure, but all functions will be psudocode. When what I have makes sense, I replace it with real code.

Share on other sites
For programs/functions:

I have an idea for what I want objects to do.
I draw them out ( as squares with names ) and branch them the way I want it to work.
Then I write out ( pencil and paper ) the pre-prototype of this design. When all seems flawless, I merely type everything out on the finished paper. Then I fix any errors I may have made.

For games:

I have an idea for how the game is played.
I draw out every screen/level for the game and place/draw object where I want them. I break complex objects down as the example list above this one.
Once I have things where I want them, I write the code on paper ( with pencil ) and work it out there. Then I retype everything form the finished paper and fix any errors I may have made. I then go back and replace my substitute sprites/models with better ones I will have finished weeks later. Then I add FX and music.
Afterwards, I go back and add/replace things with something better one part at a time.
And here's a coding tip:

ObjectEnemy has health, defense, speed, position, laser attack, slash attack, block, dodge......

class EnemyBase{     private:          int m_health;          int m_deffense;          int m_speed;         /*later on....*?    public:        virtual void  use_attack_1() = 0;          /*And the rest of important stuff*/};

Never have all of this stuff and then try to make it all work, You might, later down the road, not need something or you'll forget about something else you wanted/needed to program. Instead, start with one thing and work your way up:

class EnemyBase{     private:          int m_health;     public:          virtual void lower_health() = 0;};class BladeOfGrass : public EnemyBase{     public:         void lower_health(int amount)          {               int newHealth = m_health;               newHealth -= amount;                if( newHealth <= 0 ) {m_health = 0; return;}                m_health = newHealth;         }        /*Blu-blah....*.};

And then work your way filling the object. It's faster, cleaner, and efficient. :]

~Maverick

Share on other sites
Quote:
Original post by MJP
Quote:
 Original post by TelastynGenerally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

I thought I was the only person who thought about programming in the shower! [smile]

Nail on the head there. If I can't sleep at night I lie there thinking about how to implement something. Traffic jams, the walk to the train station, unbearably boring lectures, during sex...

Some of my best programming feats were achieved when I wasn't actually coding. Occasionally I'll write something down, sometimes open up Kate/Notepad or even my phone's memo function and write a line of pseudo, but that's a rarity.

Share on other sites
Quote:
 Original post by deadstarunbearably boring lectures, during sex...
I initially read that without the comma.

I have to be in the right frame of mind to think about coding, otherwise distractions are a-plenty.

Share on other sites
I think about the design of the application (game) in detail before hand. Then I start coding and design the code as I go, refactoring as needed.

Splitting up those 2 concepts has worked very well for me. Planning the code at the same time as planning the finished product is how we end up with these awful OOP abominations.

Share on other sites
Quote:
 Original post by DungeDevil May Cry's Smokin' Sick style!!!

Indeed.

I usually have a list of things I want to implement, then I implement them one at a time. Sometimes I will jump to 'cool stuff' to see if it can be implemented in my game, but usually I follow the planned route.

Share on other sites
Quote:
Original post by MJP
Quote:
 Original post by TelastynGenerally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

I thought I was the only person who thought about programming in the shower! [smile]

The only programmers I know where 'where do you solve problems' has come up and they didn't think of design stuff in the shower are the ones that do it for a living alone.

And as deadstar mentioned (and I forgot), that little time in bed before sleep is great too.

Also, I've taken to making myself a concrete goal at the beginning of a session (I can only code for 1-3 hour intervals depending on my state). 'At the end of the session this should work.' Helps keep me on point, and provides a good, frequent practice for judging 'time to implement' estimates.

Share on other sites
If what I'm doing is small or easy, with no risks involved, I'll jump right in and start coding, fixing bugs and errors afterwards. However, if I'm coding something large or something that I cannot risk messing up (account registration, subscription handling...) I'll create a flow chart and plan things out as carefully as I can beforehand.

Depending on what I am coding, I might also put it into a testbed application before it goes into the main app. This would mostly be done for projects that would be difficult to debug in the larger and more complex main app.

P.S. I am also one of those programmers that thinks of coding while in the shower, heh.

Share on other sites
Many moons ago I used to just jump in and code...
Believe it or not that was in assembly. I am "too old for that shit" now! Not assembly, you understand, just too old to waste time coding something complex without any planning.

As I have aged I have found that it's a more organic process.

For simple tasks I just code, of course.

For middle to more complex tasks I generally sit and think, make some notes, plan classes, and research if necessary. Writing a good, commented .h file first is always very very helpful.

For really complex R&D I tend to keep it in the back of my mind from day to day, and eventually something will click and then I'll plan, classify, and code...

Of course after all of these things I may well then throw it all away and start again.

One thing I have found to be my best work practice is to maintain two or three versions of a source tree, and an active 'Sandbox' dev copy. The latter I am free to code any mess in, and only once it has been tidied, optimized and 'classed' properly does it migrate to a main set of code. I then manually move code sections to a main dev section. In doing that I re-familiarize myself with both code sets along the way.

Share on other sites
I type up a lot in terms of use cases, feature requirements, and ideas or requirements for implementation, so that I have plenty of information up front. Then I start coding, with the emphasis on getting something working first, and refactoring it into clean code later. My first attempt at anything usually has a few globals and module-level functions, and once I've proven that the algorithm and data structures work to produce the output I want, I remove all the globals and structure it more appropriately.

I never do class diagrams or anything like that though. Generally I know exactly which patterns will apply to my code up front. I find the refactoring into cleaner code to be quite easy when you know you have already met your requirements (which I listed up front), rather than trying to hack extra stuff into a rigid structure that wasn't designed for it.

Share on other sites
Quote:
Original post by MJP
Quote:
 Original post by TelastynGenerally I'll think through a problem during the slow parts of the day (bathroom, shower, driving, boring tv, waiting for food) until I'm reasonably comfortable with the solution. Sometimes it requires jotting things down and notes, but that's rare. Then I'll implement things.

I thought I was the only person who thought about programming in the shower! [smile]

All real programmers think about programming in the shower! [lol]

I take a middle-of-the-road approach: "Jump in and plan." I usually set a very simple goal, do a slight amount of planning, and do it. Then I'll think of something else to add, and repeat the process. This process repeats from hello world to finished product.

It's not until I have to make a big jump that I spend more time planning. I'll usually think about it and not get anywhere for a while. Eventually, I'll get enough of an idea that I can get started, refactor a time or two, and it gets done.

Lately, I got the hang of class diagrams, so I've been using those a little. I love diagrams.

Quote:
 Generally I know exactly which patterns will apply to my code up front.
Ah, if only...