haha, then I out rank you there Kerm, I have this weird ability to memorize a command and how to use it properly in C#

Yeah, but you also have the advantage of not having to try to keep the different (often only slightly-different) syntax for twenty-odd different languages in your head, along with their function names for things, which are about as far from consistent and standardized as you can get.

hmm, good point... I bet when I learn asm then I will be in the same position as you

When you learn ASM, and x86 ASM, and several flavors of BASIC, and PHP and Python and Perl, and C and C++, and Java, and Javascript, and several HDLs like VHDL and Verilog, and a bunch of different markup languages, and bash scripting and windows shell scripting, among a few others, then you will be in a similar position to me.

of course, some of those I have no intention to learn x.x

wow you know alot of languages...

anywho, back to the topic

I will have to put these on hold for a few days (I blame life)

Don't be mad at life; real life and schoolwork and relationships (not necessarily in that order) should always come before your coding and personal projects, in my opinion.

wha? No, I am not mad at life, I am just saying it is the reason I have to put of coding for a day XD

I am way to happy to be mad right now

Haha, good. I meant something along the lines of "don't take it as a negative that life is taking you away from coding," but it sounds like that was already your attitude, so kudos.

I just have trouble coding on my busy days
if I get 5 mins of break on a busy day, I will usually play on my DS
I will usually be to distracted or something to code...


so, yeah, when I dont have a busy day, expect a big update

(man I remember how in 8th grade I could code as much as I wanted in class, and still get my work done) but it is 9th now, and things matter

For sure, and a very healthy attitude to have. The more complex your coding, you'll find, the more time it takes to get everything set up in your mind; for Doors CS, for example, it took a week or three of not thinking about too much else for that too happen. For some of my simpler BASIC games it would take me only a few minutes.

true, when making that enemy engine (which was something I really have never done before) It took me 30 mins to code and about 4 hours to think up x.x

I strongly suspect that our subconsciouses continue to work on problems like this even when we're not actively thinking about them. At any rate, what big components are left to add to your game?

hmm, alot, let me try to name them

1. A winner and loser notification
2. Enemy collision (which leads to death)
3. the ability to go through one side of the screen and come other the other
4. Some other stuff
5. more stuff I cant remember

I think that 4 and 5 will be the hardest to complete. 3 is almost impossibly trivial; post your movement code and I'll show you.

The GUI interface is always a big jump for me. You pretty much just sketch up what you want it to look like, but then you have to make up what each element will do throughout a wide array of events. Also, there are new commands and syntax to go along with all the other headaches. I made a simple calculator in Visual Basic. It took SO long to make it. I taught myself everything I know about any programming language. Why don't they offer Object Oriented Programming in High School?
Concerning the game half, you have lots of coding to go. The basic graphics (2 sprites right?) shouldn't take too long, it's all the other code that gives you trouble. I don't think I could do all that in TI-Basic though. I haven't ever spent much time with all the libraries available. Good luck with the remainder of the work!

Well, you could use the Doors CS GUI SDK to do it easily. Actually, that's an interesting idea, a 4-function calculator with the DCS GUI! Who wants to try it?

Player and enemy, but I presume he also wants at least one shot sprite? Unless the bullets will be one pixel.

I thought he said c#. That's on a PC, so Doors CS has nothing to do with it. I didn't think about a shot sprite. 1 pixel would be really annoying. It's too small. Maybe just a 3x3 shot. A shot sprite really doesn't need much design though. I stand behind my statement that the graphics on the calculator are the easy part, but dealing with the SUPER limited hardware in code design is the hard part.

Well, when libraries and shells take care of abstracting the complex display interaction, pixel manipulation, clipping, etc, it becomes a lot easier to deal with sprites from a programmer (ie, not me, since I need to write that lower-level stuff) standpoint, so I maintain that the graphics design itself becomes the hardest part. And he did say C#; I was merely commenting that the simpler the GUI system, the less documentation is necessary for it to become intuitive.

Kerm, I _know_ how to do that...

I just need to implement it

I actually plan to use x-lib to make a splash screen or something..

Ah, I thought perhaps you were avoiding it because you weren't positive about the methodology. Good idea re: splash screen; don't forget that SourceCoder now has a lot of things to help with that.