Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / Are you a real programmer?

Author
Message
PAGAN_old
18
Years of Service
User Offline
Joined: 28th Jan 2006
Location: Capital of the Evil Empire
Posted: 25th Sep 2007 20:57
Me and my friend had a discussion the the other day whether people who write free-ware games also write design documents and other documentations that are required by the real programming industry.

My friend urges me to write a design document for the game I am building (he thinks I will not get anywhere if i don't)

I do not agree that ALL good programmers write documentations. And a lot who do write them, probably change them and rewrite them several times before the final product comes out.

People! how many of you who are working on projects big or small write design documents and stuff?

dont hate people who rip you off,cheat and get away with it, learn from them
Jonny_S
22
Years of Service
User Offline
Joined: 10th Oct 2002
Location: United Kingdom
Posted: 25th Sep 2007 21:00
You'll find life much easier if you atleast put something down on paper first, even if its just a basic outline of what you want to achieve.

Your signature has been erased by a mod
tha_rami
18
Years of Service
User Offline
Joined: 25th Mar 2006
Location: Netherlands
Posted: 25th Sep 2007 21:08
I usually set a solid goal, an extended concept, a solid approach and solid path and keep to that.

Until some feature creep comes up.


A mod has been erased by your signature because it was larger than 600x120
Oolite
19
Years of Service
User Offline
Joined: 28th Sep 2005
Location: Middle of the West
Posted: 25th Sep 2007 21:24 Edited at: 25th Sep 2007 21:33
mmh, how does one define a 'real' programmer?



I always write down my projects, along with 3d models if i'm not working from concept art.
I'd write down the features i want on my character, then sketch it several times till i find my favourite one, then begin modelling.

If you're serious about a project then all the above is necessary, if not, just have fun with it. If you don't enjoy doing it, simply, don't.

Kentaree
22
Years of Service
User Offline
Joined: 5th Oct 2002
Location: Clonmel, Ireland
Posted: 25th Sep 2007 21:28
Quote: "Me and my friend had a discussion the the other day whether people who write free-ware games also write design documents and other documentations that are required by the real programming industry."


You clearly haven't worked in the "real programming industry" . It totally depends on the company how, and even if documentation is written, currently I write very little documentation for what I do, but in my last job there was design documents, we each had user stories (tasks that were subdivided between us depending on time) etc. Personally I like to do up a bit of a design document for games, but not too much as I tend to come up with new stuff as I'm coding.

Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 25th Sep 2007 21:32
We have to write tech briefs at work to validate everything we do. At home I just code without so much as a fully fleshed out idea. It's fun and I enjoy it, so for a hobby that's all that matters

Dr Manette
18
Years of Service
User Offline
Joined: 17th Jan 2006
Location: BioFox Games hq
Posted: 25th Sep 2007 22:02
My "design docs" are usually lists of stuff grouped together. As I go through the process of making a game, I will make several more small lists of things to do ect. So no, design docs aren't needed, but definitely virtue.

BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 25th Sep 2007 22:37
Feature creep is your worst enemy. Even if you don't have a design doc, you should at least have a scrap of paper headed "Version 1.1". This is where you scribble down all of your extra ideas. Otherwise, you'll never get 1.0 out of the door.

For personal stuff, I love RAD (Rapid Application Development). As long as you structure your code correctly, you can make something simple, prove it works, and then keep adding more and more features. The whole idea here is that at every stage, the program works as if it was a finished article.

Seppuku Arts
Moderator
20
Years of Service
User Offline
Joined: 18th Aug 2004
Location: Cambridgeshire, England
Posted: 25th Sep 2007 23:03
I wouldn't call myself a real programming, because my self exists within a realm of an alternate consciousness that isn't my own...so I am just a concept, an ideology and like great ideas, I do not actually exist.

Aside from the BS talk, I'll provide a real answer.

Design plans are great, you're able to follow something and rely on what you have to do by pre-planned parts, but they don't have to be intensely detailed as people work in different ways - some have ideas and only need basic stuff written down because they know what it all means, others may find detail is important because they may lose sight of their idea as they're working through.

But I would suggest you do have something to go on and not think of stuff on the spot, as it could cause problems and make your engine sloppy. Really, in basic terms you need to know what you're doing and how you're doing it.

My current game plan is very basic, my previous one was really detailed, my last game failed and my current one looks like it's going to be on the road to success, of course when I get all the time I need for it. So 'detailed' plan doesn't always lead to success, it's you that delivers yourself, your plan should just do what works best for you and provide your direction.

Pro's of course provide very detailed plans, mainly because it's a collaberative effort and small detail may be too ambigious to those who didn't come up with the ideas. Plus it makes it a very helpful reference for doing each part.

I shot the sheriff
Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 25th Sep 2007 23:04
Quote: "required by the real programming industry"
True. And false. True in the case that bloody ISO standards these days wrap you up in paperwork most of the time. False in the case that when these same people want something done in record breaking time they don't care about documentation or design. Just do it monkey boy. Always ways around things. Especially when you are the one who designed the release procedures, release procedure code, and all the methods and documents inbetween. Hehehe...

What is also true is that while pretty much everything I spec at work at about £1300 ($2500) a day is mostly done to the letter, everything at home is written on the fly without any design really. Meh. Get a CS degree, it's all pretty straight forward, and I don't need an ISO standard stamp on my hobby stuff.

First day I started Uni (I mean the day I bothered to stagger in to a lecture) the lecturer said throw away those plastic flow diagram templates, as it's all crap. Which was annoying as I had only just got one after years of using a stupid ruler. Still had to do annoying pseudo code though, just structure diagrams and the like were crap.

Best advice in Uni was to code it first, then make the design document afterwards so it fit better. Heh heh heh.

Not saying design docs are bad, but if you are good enough and control the whole process (from talking to customer, to supporting the thing after coding it) then who needs 'em. Apart from official authentication stuff. Meh, jobs for the boys.

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
PAGAN_old
18
Years of Service
User Offline
Joined: 28th Jan 2006
Location: Capital of the Evil Empire
Posted: 25th Sep 2007 23:32 Edited at: 25th Sep 2007 23:55
Quote: "mmh, how does one define a 'real' programmer?"


Thats just the term my teacher uses, he always refers to the "real world" and "real people" just thought throw it in here.

He is telling us by the time my age group gets out into the "real world" 70% of out job will be srs, design, documentations and all that "fun stuff" as he likes to call it. the other 30% will be testing.
Apperently in 2 years all coding jobs will get outsoursed to the codemonkeys in India, Russiia, China etc. So i decided to leave programming games as my hobby. Throughout my programming course, programming games in dark basic was and still is the most fun I had. The rest of the stuff was very boring. And pretty complicated, like Visual Basic (took me 2 years to cmplete and i am still very bad at it).

In terms of designing my stuff in db, the only thing that i put on paper is the concept art. While i am still designing engine(sort of) a rough idea of the design is in my head.

I still have a lot of work to do before I get to the fun part.

dont hate people who rip you off,cheat and get away with it, learn from them
Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 26th Sep 2007 00:56
Quote: "by the time my age group gets out into the "real world""
Yeah well, one of my old bitter hags of a lecturer once told us (about 1990) that we would soon be replaced by visual tools that could be used by monkeys. Soon was earning more than her. Hehehe...

Quote: "Apperently in 2 years all coding jobs will get outsoursed to the codemonkeys in India, Russiia, China etc"
It will take longer than that. We have outsourced for years, and it still isn't good enough to take over fully (or even more than partially). Just is harder now, and programmers are no longer seen as the rare high paid gurus they once were. More like plumbers. At the end of the day though, no matter how good communications get, management prefers teams they can see and shout at. Saying that I work from home thousands of miles away from the office. Ho hum...

Quote: "And pretty complicated, like Visual Basic (took me 2 years to cmplete and i am still very bad at it)"
Keep at it. I love VB, but would consider DB harder to learn. Mainly because it is a pain in the a**e...

Fun part? All coding is fun! Apart from when you have to take apart 25 year old code and piece it back together again to find a problem that has existed since you were in little school.... Not so fun....

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
Aralox
17
Years of Service
User Offline
Joined: 16th Jan 2007
Location: Melbourne
Posted: 26th Sep 2007 01:53
Ive got a whole book full of my information - I learn and program better that way.

PAGAN_old
18
Years of Service
User Offline
Joined: 28th Jan 2006
Location: Capital of the Evil Empire
Posted: 26th Sep 2007 02:40 Edited at: 26th Sep 2007 02:43
Quote: "Keep at it. I love VB, but would consider DB harder to learn. Mainly because it is a pain in the a**e...
"


I used to say the same abut vb last year, but only as a joke.
I do agree that vb is a pretty good, orgonized language, but i still can't get over the whole object-oriented stuff.

Espesialy when you have to pass in other subs variables and functions into each other

private sub(function, intCrap by val(as decimal.text)lalsama'sck'apepk]kew[epqwod[pa[sd'as;l'dq))))))))AHHHHHHHHHHHHHH

see...

i have looked into 3d engines for vb to make learning more fun. I did find this so called "truevision" engine but never got around to it. All we did in school are boaring programs that mainly involved calculating numbers and doing stuff with strings in various ways.

For example, make a program that simulates a savings bank account system with interest and withdraw/deposit charge of $1.00 and so you can only withdraw $200 at a time.

the funnest thing in vb that i did was math testing program/game.

It displayed pictures and funny responses for random arithmetic problems it generated. I also added other problems like world hunger, unemloyment etc just for fun. (it displayed funny messages as a responce)
but for most part VB was Very Boaring.

DB is fun because the number crunching integrates with the 3d mechanics of whatever 3d stuff you make (if its 3d)
Its kind of like playing god.

PARDON MY SPELLING PLEASE! my total Russian language setup completley screwed up my spellcheck which now mark everything wrong!

havent got around fixing it or mnually checking my spelling.

dont hate people who rip you off,cheat and get away with it, learn from them
Code Dragon
18
Years of Service
User Offline
Joined: 21st Aug 2006
Location: Everywhere
Posted: 26th Sep 2007 03:15
I keep two lists: everything that's done and everything that's not done. When I get an idea for a feature or find a bug I add it to the second list, then when I finish it I move it to the first list. I use the ever-growing first list to keep a reminder of how much time I've invested in the project and how far it's come, it really keeps me from quitting.

Aaron Miller
18
Years of Service
User Offline
Joined: 25th Feb 2006
Playing: osu!
Posted: 26th Sep 2007 04:42 Edited at: 26th Sep 2007 04:44
My opinion is that if you wish to get anywhere with a professional project, that you must create a design document, outlining specific structures and rules for your game, or application. In all honesty, I wouldn't buy anything today that didn't have a good design document, or a LOT of thought put into first. All the projects I'm working on for commercial purposes have a nice design doc on what they do. But a design doc isn't just about what it does, it's also about marketing and advertising, so you won't be so unknowing what to do once you've completed a project. Below there is a company that tailors to indies needs for games, I think if your game is good enough, you should check them out.

Another thing is that if you plan to get your game published, you'll need to provide a good design doc, or so I've been told.


If you're just doing it as a hobby, then do whatever you feel is right. If you're making a large project, a design doc is certainly a good choice, if not don't bother.



Cheers,

-naota


Out of business, nvm

I believe this place will publish games though
http://www.xgamestation.com/

DBP, $80. DBP's plugins, $320. Watching DBP Crash, Priceless.
NG Website Aex.Uni forums
BatVink
Moderator
21
Years of Service
User Offline
Joined: 4th Apr 2003
Location: Gods own County, UK
Posted: 26th Sep 2007 10:57
Quote: "Apperently in 2 years all coding jobs will get outsoursed to the codemonkeys in India, Russiia, China etc"


My experience is that these countries do the work for half the price, but take three times as long. Ergo it's no cheaper. I think they are working towards the day that their programmers have more than 2 years experience, but right now the average span of an employee is about 18 months. So there is no one with any experience.

Recently, an Indian outsourcing company confessed to hiring staff in the US, because it was cheaper! That's right - you outsource your work to India, and a guy down the road picks it up!

Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 26th Sep 2007 11:12
So much text and so little time. I've never worked as a professional programmer but I know a thing or two about how things like this works, most are from the book "Game design theory and practice" by Richard Rouse III. Probably the best book ever written about game design.

First off the design document is NOT for programmers to write, it's for the game designer to write. If the game designer is also a programmer then a programmer will be writing it. A design document should not contain any technical information, rather that should go into a separate document written by the lead programmer. I think Rouse called it a technical design document. Art and story should go into the art and story bibles and be separated from the design document as much as possible. However, this differs between companies and there's no industry standard.

Documentation is mainly a tool to communicate ideas between people and to make sure all in a team is working on the right things. A design document is often required before those in charge of the money allows for a game to be developed. Some suits judge a game based on the number of pages written. Afterwards some teams just ignores the document because it never describes the final product. A design document should be constantly maintained and updated by the game designer, who then should make sure everyone is aware of all the changes. It's a lot of work and for a single person or a small team probably a waste of time. It's good to have some form of written documentation for team members to go back to instead of asking you every time.

I know that in professional programming companies documentation is half or more then half of the actual work. It makes no sense to me to first develop things on paper and then translate that into code when the code basically is a form of documentation on it's own. I can however see the benefit for a team of programmers to document things like functions, types, classes and global variables and how they all work together.

I personally hate to draw programming flowcharts and writing documentation is a huge pain it the butt. Still, the manual included with every release of Simple Game Toolkit is always up to date. Maybe not the most pedagogically written but it's all there. I also write down everything I'm going to do and everything I have done. Complex algorithms and subsystems I often work out with paper and pencil. Like figuring out my own draw system and pathfinding algorithm.

[center]
CREATE games with ease! NO programming required!
WIP
Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 26th Sep 2007 12:02
This is all very well and good, and these days with ISO standards and the like then the days of specs on the back of fag packets are log gone (used to happen when I first started - my manager was massively old school). *But* there is a balance between design and just getting in there and programming the damn thing. Normally it is totally controlled by time and money.

We do a hell of a lot of design in my company compared to what we used to (started in 1995), but each job is different. You can have a single line spec saying to implement baggage allowance in an invoice, and really you wouldn't need much else, and obviously would be a moron to produce a massive load of documentation on the job. Just enough to pass ISO audits basically. On the other hand I could be speccing CV2, encryption, and 3D Secure into the CCA module (which I did the other day for £80k) and it would be like suicide to not have detailed specification documents and the like. Shove your flowcharts up your **** however

Now to do an annoying ballpark (1st stage document listing what we have to do and the estimated price) I've put off... Yawn...

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 26th Sep 2007 20:40
Programmers do not write design docs, you're correct, but we have to write tech briefs to prove everything we do. If we have to implement a way of doing something, we need to first document it-- it's actually more to cover our butts. A senior software engineer or tech. director has to sign off on it, so later down the road he can't take issue with it. It just makes sense, as in software engineering there are always multiple paths to reach the same goal.

Matt Rock
19
Years of Service
User Offline
Joined: 5th Mar 2005
Location: Binghamton NY USA
Posted: 26th Sep 2007 20:59
I won't write a single line of code without a detailed understanding of how the game is going to work, and after my experiences with my last game, I make a detailed skeletal program (on paper) listing all of the subroutines, functions, variables, and files that the game is going to need in advance, so I don't end up tacking on new features that change the fundamentals of how the game will work. On Project Sewer Rat, because of it's massive size, I'm having everyone working on that project write up a summary of what they're doing and how their progress is coming along, even though we have a tiny team compared to some others. But I'm the kind of person who doesn't go shopping without a precise list of exactly what we need with a quantity number along side each item, so I'm probably too neurotic to be a role model here lol.

Jess T
Retired Moderator
21
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Over There... Kablam!
Posted: 27th Sep 2007 06:23
Quote: "I make a detailed skeletal program (on paper) listing all of the subroutines, functions, variables, and files that the game is going to need in advance"


Sounds like a Functional Spec to me


For our current project at Uni, there's a team of 10 of us + Lecturer working on it, but for 4 months before programming started, we had to 'design' it (ie, document everything before programming). This involved alot of research (it's a sim), and on top of that, a hard-copy game (ie, board game) which actually worked out very well for balancing the game, and looking at the effects certain actions have.
If you're in the position to try it (more appropriate with sims and strategy games), then I suggest you give it a go, since you don't have to write a single piece of code, and everything's so easy to change.

Nintendo DS & Dominos :: DS Dominos
http://jt0.org
Digital Awakening
AGK Developer
22
Years of Service
User Offline
Joined: 27th Aug 2002
Location: Sweden
Posted: 27th Sep 2007 10:37
An explanation
So, why did we end up in a world where being a programmer means doing paperwork? I will try to give you a psychological explanation. According to Meyers-Briggs and Kiersey there are 16 personality types in the world, 4 of these can be considered leader types (all 16 can become good leaders, these are just naturally talented).

My type is called Mastermind by Kiersey, with only 1% of the world's population it's the rarest of all. This type is good at building, analyzing and improving systems, always open for better ideas. A relative of mine is called Fieldmarshals, also rare with about 2% of the population. These are the take command type of leaders, or in some way they always end up the leader of whatever group they are in and most people tend to follow them. These two types are intuitive which means they understand things quickly and are less concerned with details and day to day happenings, rather they focus on the goal and are very flexible.

Another relative of mine is the Inspector. They are very common at 10%. Their goal in life is to make sure that everything and everyone meet specifications. Maintaining quality is their ability. The opposite of me is the Supervisor, also around 10%. This is the type that make sure that everyone stand in line and roar at those who does not. They do not like experimentation and daydreaming. These two are of the sensing type, compared to intuition they are concerned with details and day to day business.

Funny thing: These two detail oriented leaders make up 20% of the worlds population while all 8 intuitive types together makes up 25-30%. Guess why the world is filled with paperwork



Jess:
If you have a good editor to your game then changing is fast and easy. That's the beauty of my software, you can instantly switch between the game and the editors

[center]
CREATE games with ease! NO programming required!
WIP
Jeku
Moderator
21
Years of Service
User Offline
Joined: 4th Jul 2003
Location: Vancouver, British Columbia, Canada
Posted: 27th Sep 2007 10:44 Edited at: 27th Sep 2007 10:46
Like was said earlier, industry game jobs require paperwork. Just get used to it

EDIT:

Let me rephrase that. Junior grunt programmers might never have to do much more than time estimates, as they're told what to do by their lead. But that's the lowest low.

Dazzag
22
Years of Service
User Offline
Joined: 26th Aug 2002
Location: Cyprus
Posted: 27th Sep 2007 12:21 Edited at: 27th Sep 2007 12:22
Quote: "why did we end up in a world where being a programmer means doing paperwork"
Meh, mostly to give jobs to the talentless but well connected boys (secret handshake etc). Heh, I heard they wanted to give me the job of ISO standards auditor after the last guy quit, mainly because I designed all the release and most of the design procedures. I left the country Programming is where it's at boys. Design is pretty good. Training is brilliant (when I used to do it) and amazingly not everyone can do it (walk in the park for me). Management has good and bad points.

Personally though when it comes to hobby stuff then I say go with whatever works for you. If getting in there and programming the hell out of something without any design is your thing, and it works for you, then go for it. If on the other hand you need design documents and charts coming out of where the sun doesn't shine, and it works, then go for that. Whatever floats your boat.

In industry though then document *everything*. Mainly about covering your back. Secondly about making sure the client doesn't have a way of getting free work out of you. I remember about a decade ago my manager authorising about £50k of work to allow Voyages (as in cruises on boats with lots of stops, and completely different to what we always did for Ferries) on our system. He totally made everything vague. Took me about 3 years to get them how they wanted, and nothing in the spec contradicted the changes they wanted. Think we calculated it cost about £400k to fix them. System only cost about £300k in the first place... Heh, and obviously a spec is also good for idiot programmers to understand what you meant. When you have about 60 programmers of different skill levels directly following your designs then you had better be specific.

Cheers

I am 99% probably lying in bed right now... so don't blame me for crappy typing
Current fave quote : "She was like a candle in the wind.... unreliable...."
Jess T
Retired Moderator
21
Years of Service
User Offline
Joined: 20th Sep 2003
Location: Over There... Kablam!
Posted: 27th Sep 2007 12:58 Edited at: 27th Sep 2007 19:29
Quote: "If you have a good editor to your game then changing is fast and easy. That's the beauty of my software, you can instantly switch between the game and the editors "


Yeah, but you have to know what the editor is editing in the first place. What the min and max values are, etc, etc. The board-game prototype was made long before anything like what the world, or the UI would be like was decided!

Nintendo DS & Dominos :: DS Dominos
http://jt0.org
Zombie 20
17
Years of Service
User Offline
Joined: 26th Nov 2006
Location: Etters, PA
Posted: 27th Sep 2007 19:19
mmm..wonder what they would label me as?

Login to post a reply

Server time is: 2024-11-19 07:35:54
Your offset time is: 2024-11-19 07:35:54