what did it take you: dev

[krooked]

To keep things short and sweet, i have always been a linux, homebrew enthusiast for a few years now. the problem i have faced is seeing the amazing things done with projects like this, and all the work put into this, and understanding nothing about how it came to be.

I have started on basic language classes in school and trying to solve more tasks myself before googleing the way to fix it, but i am just curious
what did it take you, a developer doing what some of us have absolutely no idea how you would even begin to start doing, let alone actually make a working final project, get to where you are today.
I ask here because the things being done in this project are among some of the most impressive and make me the most envious.
congrats to all you dev's and the people making that possible.

High Hopes For The Pandora! Shipping Day Is Taking Forever!

 

[andy_js]

So you want tips on how to become a dev?

Here is some of my tips.

1. When coming up with new ideas, don't concern yourself with how they are going to be implemented. You'll manage to figure it out when the time arises.

2. Try new things/Experiment. - Come up with some serious crack.

 

[yosh64]

hey

My best tip is try to stay focused and take ONE step at a time!

When you break things down it's really not so tough, just don't try and jump up 10 stairs at a time .

Hmm, sometimes you may be so overwhelmed that you don't know where to start, my best tip is to start simple, and from the beginning. I usually start by writing out comments of all the logic of my code, and then I pretty much just start programming underneath each of those comments.

Umm, you may also be interested in the Introduction and Game Design -> Lone Developer sections on this page. I ran into this just the other day (maybe it was yesterday, hehe), and found the lone developer section interesting.

Anyhows I hope this is of some help.

cyas

 

[phrosty]

Build something that YOU want not what someone else wants. Chances are if you find it useful others will as well.

this could not be more true!

 

[krooked]

that wiki looks useful, thanks.
yeah i have started thinking of things that could be useful to me, and how i would go about that. guess its true, gotta start somewhere.

 

[JohnM]

Like yosh64 said, take everything one step at a time. Work your way through as many tutorials you can find and start with something simple. Then add to it. Then start the process over again, you'll be surprised at how many skills you pick up and before long you'll be overflowing with ideas. Always remember though, a programmers best friend is pen & paper; plan everything you're going to do first and work your way from there.

 

[likwidoxigen]

Build something that YOU want not what someone else wants. Chances are if you find it useful others will as well.

 

[bzar]

1. Learn something new
2. Code something using it
3. goto 1

Reading about stuff and following tutorials is great for the first part, but you really learn it when you make something of your own. Start with the basics, then move on to advanced topics. Code simple apps when learning about a new topic. Also using previously learned stuff in coding test apps helps a lot. When you learn to plot graphics, make graphic test apps when applicable and so on.

You'll get it after tinkering for a while!

Oh, and if you want to learn something, don't copy-paste. Write. Copy-pasting is for things you understand.

 

[DasFool]

Do your best to complete projects you start. If your portfolio consists of a bunch of semi finished games/applications you won't feel like you ever accomplished anything.

 

[likwidoxigen]

Do your best to complete projects you start. If your portfolio consists of a bunch of semi finished games/applications you won't feel like you ever accomplished anything.

+500 very good point. Becuase if you feel like "I only have to do just this one more simple thing" and then quit.... that's a bad idea. There are usually some interesting problems that crop up doing that one last simple thing that provide great learning lessons.

 

[Dunny]

I started on the Sinclair machines, in Sinclair BASIC. Silly stuff, but I did actually write some simple games (mostly text). After the Speccy +2, I moved up to an Amiga. I tried messing with C, E and others but had no luck - just couldn't get my head around applications that use more than one source file.

So I nabbed a copy of Amos Pro and the compiler, and went at it like a bastard. Loved every minute of coding on that thing. When the inevitable demise of the Amiga came around, I jumped to Win95, but didn't code until I found a copy of Delphi 1. I played with it for a while, and gradually got the hang of multiple files as a source base (to this day, C's division of source and headers confuses me, and appears completely pointless). Moved onto Delphi 5 after that, and that's where I am now.

In 2001, I decided to write a Sinclair BASIC development IDE. A friend suggested that I base it on an emulation of the Spectrum, and taught me how an emulator works. I started learning Z80 assembly, and had that down in less than a month. From there, to get the most out of the tight loops needed to emulate efficiently (and the graphic conversion code sections that are called every frame) I branched out into the world of x86 assembly, with all it's odd pipelining and caching/branch predictions and stalls. As I'd already got z80 down nicely, x86 was a doddle. The emulator is still going strong in the Speccy scene, and is now the efforts of three people working together.

I did do a port of xRick for the GP2x in C, but hated the experience - I'll likely not go back to that. I'll stay with FreePascal for now, and learn ARM asm for when I need to get my hands dirty.

If there's one piece of advice I can give, it's to take other people's code and play with it. Coding is such a massively different thing today to what it was when I got started, it's difficult even explaining how to do a simple text message to someone who has never coded before. By messing with code that's already working, you not only learn how to make the computer do what you want, but you learn what not to do, and what causes errors in your code.

Stick with it - it's more than worth it.

D.

 

[Falcon Delta]

Excellent topic, I was concerned about the same thing. However, upon reading the dev's comments I feel a little more at ease.