Should I open source my game now?
 

I have been working on a side scrolling game using c++ and sdl for a couple of months now .I have some of my main character animation, my controls, my side scroll engine ,some enemy sprites that move,some collision detection.I have 6 files with all together 800-900 lines of code .I know this is just the beginning .Supertux is like 15 times that size. And I already have bugs.for example.When my tank shows up on the screen it causes a segmentation fault most of the time,cause of my funky pointer stuff I think. I would post some code but it is too long, or a screenshot but I don't have a site to post to yet.I'm not sure how much time I will be able to dedicate to this project either.It just barely resembles a game really ,but my helicopter does shoot rockets across the screen that explode:D

So, should I open a new project at sourceforge and try to get help or should I do more work first.I am kind of stuck on the tank thing right now.

And what debugger should I use ,I looked it up and found ddd but I will need to learn to use something to debug.

Re: Should I open source my game now?
 

this is what I'd do...........ask others to look at the code and suggest fixes.........
debugging will take some time but eventually it'll get done.

ok I decided to open a new project at sourceforge .I will maybe post the name here if my project is approved .

Any tips on debuggers?I have gdb and ddd.I have tinkered with them for a while.Maybe I need to be more specific?Just trying to keep my thread going really.

I've never used ddd, but I highly recommend reading through a fair chunk of the gdb 'info' manual, and spend an afternoon learning it.

Write a few simple C programs with known errors (20 lines of code or so), and do things like reference NULL pointers, overstep the end of an array, trace logic flow through loops, call malloc in a function and don't return the pointer, etc...

Basically cause known memory errors on purpose then step through with the debugger and watch exactly where segfaults happen. This is a good way to learn why you would want to use it.

Maybe after you've spent some a fair amount of time debugging, look into additional memory tools like electric fence, but gdb is definately worth your while to learn.

I got my project approved but It will take me a while to figure out CVS:mad:

Does anybody have simple ,STEP BY STEP instructions?
I don't want to be a cvs expert.It will take me all week to figure out how to upload my files.

Valgrind is a great tool for debugging memory errors (usually segfaults). With the right compilation flags, it can often tell you exactly where things are going wrong. Of course, there's no way to avoid having to understand pointers and memory management pretty well, unless you give up C/C++ and use a safe language, of course.

this was supposed to be posted before you decided to post the project freely available..
you should have a pretty indepth overview of the requirements for the project.. a list of important parts of the program/game that need to be worked on ASAP and a brief description about them.
sit down and seperate the game into afew almost independant parts (classes?) that will eventually tie in with the other parts. this way you can have people work on specific aspects of the game, rather than all jumping at it and hope no ones doing what your doing.. and so on.

I see I have a lot to learn.

OK Ive got my files online now I can continue debugging.
I used cervisia because its simpler than command line ,but still hard if you never used it before.
There is a 5 hour delay between the cvs directory and the webviewer so I thought I was doing something wrong.
Any newbies interested in side scrolling games should check out helimech at sourceforge.
I'm not taking developers yet but you can leave a message in the forum .