Sorry your browser is not supported!

I kind of asked this to a guy on a thread I I have in another forum here and I thought I would ask this question here. The question is just what the thread title says.

Like I said on my other post I am using the hands on DBP vol. 1 and am getting pretty bored with it even though I don't know a lot of the stuff. I have been around a long time. In the past I have had cubes moving around the screen on a matrix, used the arrow keys working with the so that it looked like you were flying over a matrix, had sprites up and working. This is very basic but I did it by just looking up commands and playing around. I have imported X objects into DBP but did not know how to get the size the way I wanted.

I don't so much like to use tuts anymore. It just gets a little boring copying code into DBP just to see what happens.

I am considering ditching the book and just using it for reference when I need to.

So how do you guys learn???

Thanks
Dragonslayer

Make games! If you really think that when you make a game with DBP it should be good then you're completely missing the point. Every good coder here has a huge amount of projects that never see the light of the day. I for example have over 200 projects over the 7 years I've been programming.

Almost none of them were serious games, they were all part of my journey of improving my coding skills. That's what you should be doing.

TheComet

I think you may be at the point where you just need to throw youself into a writing a game.

I was quite lucky in that I was taught a little bit of QBASIC and I suppose I was where you are at now. What I did was to take my small amount of knowledge and start to write mini games. My first game was a simple 2D racing game that had a circular track, no opponents, and the player simply had to go twice around the track as quickly as possible. I then moved onto a chase game then a falling blocks game and a simple canon ball and target game.

These games were never about graphics, they were all about the game play. This is what I am most interested in so this is what I concentrate on. I still make mini games, with no media and you can find some of them on the 20 line challenge board.

If you can't think of any simple games then the general advice is to try something like pong, space invaders, asteroids or some other retro title. Personally I've never made any out and out clones like this but I did and still do use these sort of games as inspiration.

One of the key skills you need to learn is general problem solving. This is, in essence, taking something you want to do, say a game play mechanic, and then figuring out how to get it to work in your program. This, to me, is something that tutorials can't teach you. It's something you have to learn for yourself by actually doing it. A good way to learn problem solving skills is to take something relatively simple and see many different ways you can think of to solve it. So for example, this could be how many ways can you think off to make a cube move in a circle. There won't be a right answer as different ways will have different pros and cons but by figuring stuff like this out you can apply the most appropriate solution if you need it for a game. Again, this is something I play around with but then I just like to what shapes moving and spinning around the screen.

You said in your other post that you want to make an FPS but with some role play aspects. Personally, I'd say this is too ambitious at the moment but it's something to work toward. What you'll find is that things you do in one game will pretty much work the same in another game. For instance, jumping in a side scroller work pretty much the same as jumping in a first person shooter, in fact you can use the exact same physics / maths.

Probably the most important thing is to do things that you are interested in. For instance, I writing action / arcade games so I've never written an RPG or text based game and probably never will.

As I said at the start, just throw yourself into it and see what happens. It'll be fun.

Hi there.

Like TheComet and 29 games said, most of us got hundreds of projects just to make practises...let's say we have a piece of code that works fine...we have to modify something and see what happens, and save again ...for example project1, project2 ,project3 where all of them are the same but with a little difference of coding... then when you need help in something just ask for help...here in the forum ther are lots of good programmers the can help you somehow and never give up...unfortunatly and fortunatly this is not a drag a drop game maker where you never program any thing and therefore you never learn to program...when we start, we have to try something easy, and seeing our progress we can try other things.

Cheers.

Get yourself a piece of paper and design a small game to the following criteria:

*It should not be a copy or overly inspired by any existing game. (clone)
*You should have at least 2 completely new concepts you have never tried to accomplish before
*It shouldnt last over 30 minutes so you dont bloat your project too much with unnecessary ideas and give up on it.

Once you have an idea and you are inspired to create it the coding is much more interesting as it upholds a certain challenge.



-Wolf

I think these are all great ideas. I am bored of books and tuts. I know a lot of the basics but not much sprite or 3D, but I do know where to reference this stuff when I need it.

I am an avid rpg guy and am thinking about making a matrix, making a building in a modeling program, getting a character from somewhere since I can't model them now and start with that. Start trying to get a money/banking system working, an inventory system going, character creation system working, add more buildings etc... just one thing at a time. Make sure it works then move on to the next thing. I do have some things down on paper now but for now the goal will be

1. Get a matrix made and textured and get some features on it like hills and Vally's. I have done this in the past just playing around.

2. Make a building and get it into DBP and placed properly on the matrix for size, position etc...

3. Get a stock character somewhere (model pack or FPSC) get it into DBP sized and placed properly.

4. Get that character moving around, being controlled by player with arrow keys and mouse.

That should keep me busy for a while then I will take it from there!

Thanks
Dragonslayer

I would say, as well as the above, look at what you are aiming for and break it down into chunks and take a chunk at a time until you get there... but analyse your goal properly... or you may miss out simple things and kill the fun in the process...

For me the fun aspect is, working on it.

I have a design document laying out what I want overall in a game, what the game is about, gameplay, buildings I want items, game systems etc... I am going to start with these 4 steps in order and continue to work on my design doc. adding to it as I think up new and interesting features to add. I will be doing this one small step at a time.

Dragonslayer

Well, as my current snippets on the code snippets board reflect, I like to find some simple idea that I've seen before, or a simple idea I want to implement in a future project, then isolate that specific unit and code it as I see fit.

My reasoning is mostly this: People who have a big game idea planned in advance tend to build code around the game idea, which, depending on how the development shifts, could create later problems with the code. If you build underlying code, you could instead "work backwards" by putting together cleaner, crisper bits of code you enjoy and working your way from there.

It also helps because you're not putting a massive amount of stress on yourself. "Figure out how to create a decent inventory system" is a lot different than "Build an RPG from the ground up". It's the basic fundamentals that later become implemented in larger systems that, I feel, is what makes coding "fun". Not the overarching whole, the small components.

Am I saying it's a good idea? Not necessarily. It only depends on how YOU want to start out.