Newbie Programming Questions

[Fushek]

Just a quick bit of insight to get you started thinking on this. There's two things to consider here:

 

1. Changes in appearance.

2. Changes in position

 

That's primarily a change in position. For that, you need to update the X and Y positions over time.

 

Both are "movement", but you'll probably want to tackle each separately, or at least understand each separately before you try to combine them.

 

Got it ... just playing around I'm able to make a "+" character move across the screen. Nothing fancy, but I understand the concept. I can also change it back and forth from a "+" to an "x" by changing the A attribute. In my simple examples, I can have it change form and move at the same time. At this point, it's all manual. I'm just completely redefining the X attribute and manually moving it from #$55 to 56 to 57, I'm sure that there are better ways, but for now it works.

[Fushek]

It's looking cool!

 

One thing I want to add to what intvnut said: For both changes in positions and changes in appearance, you should consider how to handle non-integer values. For instance, you can animate a sprite by updating it's GRAM tile over time, but how often should you update it? The same for moving a sprite.

 

If you prepare a routine in your game say, that updates sprite positions on every frame, how should it determine how far to move the sprite every time?

 

This is one of those things where it pays to plan ahead how you want to do things in a more holistic way, rather than concentrating on one particular aspect in isolation. You can spend some effort in testing and building code that will move a sprite say, one pixel on every frame, but you'll probably end up throwing most of it away if you then realize that your game needs variable speeds for different sprites, and that the speeds do not necessarily fit neatly as integer number of frames per second.

 

These are "solved problems" in that there are standard ways of implementing them. It may be a good idea to think of this part of your game not as "How do I move a sprite in the abstract?", but rather like "How are my sprites going to move in my game, and how do I accomplish that within the framework I am building for my game?"

 

Just keep in mind that even if you decide to move in a simple way such as one pixel every frame, you need to make sure the routine that does this fits neatly within all the other stuff your game may be doing on each frame.

 

Just my 2 cents.

 

-dZ.

 

Thanks again for the advice. The idea of just jumping right into designing a game before I understand the rules and parts is very intimidating. Kinda like telling someone to put together a car engine without knowing what each of the parts do!

 

Any game that I design is light years away and may change form a thousand times ... and I don't mind throwing code away if I'm able to LEARN from it and understand better. Every time that I learn something else, it helps me understand how I could incorporate it into a future game idea or the current game "thought".

 

I think that I need to at least understand the basics to be able to design and flesh out a game.

[intvnut]

FWIW, I didn't want to overwhelm the discussion with a particular implementation, lest it send the impression that there's "only one way to do it."

 

But, now that this is rolling, I suppose I could describe Space Patrol. It turns out that Space Patrol demonstrates that there is more than one way to do it, as it uses multiple different techniques for different classes of objects.

 

The easiest to understand is the general "velocity" based motion I use for the aliens and the tank's vertical bullet. For every MOB, I add its current velocity to its current position once per tick. Space Patrol stores both of these at 16-bit precision, with 8 bits of integer and 8 bits of fraction. This allows me to specify velocities with a granularity of 1/256th pixel per frame.

 

For some objects, I can also 'tack' them to the screen's horizontal scrolling. The alien ships and the tank's bullets don't normally scroll with the ground. Space plants and land mines only scroll with the ground. Boulders do both: They have horizontal motion of their own and they scroll with the ground. To achieve this, I can set a flag on objects saying "subtract 1 pixel from this object's position if the screen scrolled 1 pixel this frame." This anchors those MOBs to the screen scrolling if their X velocity is otherwise zero, and also allows boulders to have a consistent velocity relative to the ground, rather than relative to the screen.

 

(You might notice I didn't mention rocks and craters; these are not MOBs, but rather background cards.)

 

Above that engine, I have other logic that determines what the velocities for the objects. Bullets (both good guy's and bad guy's bullets) always have a fixed velocity after being fired, so SP just sets the velocity when they're fired and forgets about them. Non-bullet objects each have "thinkers" that update their position and "sprite attribute" based on the needs of the object. The saucers and follower have rather complex thinkers as compared to the others.

 

In Space Patrol, the Sprite Attribute Table in ROM contains information about how to display each MOB. The Sprite Attributes are primarily just the values that I need to add the X and Y coordinates to in order to generate the X and Y register values for the object. I pack some extra information into the bits the STIC ignores, such as, point value (if it's something that you could score points on), as well as a flag indicating whether the attribute is part of an animation, the rate of the animation and the next sprite attribute in the animation. This animation mechanism allows setting up simple loops that run at 7.5Hz, 15Hz or 30Hz. The thinkers don't have to manage these animations. Animations can also link to the "no MOB" attribute, which is how I handle explosions. They animate and terminate.

 

Each object's thinker can update the object's velocity, position and attribute. For more complex animations, such as the randomly blinking land mines, or the randomly ducking plant, the thinker handles this by manually changing the attribute.

 

The most complex thinker is probably the one for the follower. That thinker actually is two thinkers, because the follower is made of two MOBs. One thinker does all the logic updates for the follower and keeps the two halves in sync. The other does nothing.

 

 

For the player's tank, I have a very simplistic physics model that sets the horizontal and vertical position of the tank. Without going into too much detail, the output of this model is an X and Y coordinate, so I simply place the tank there. To animate the wheels, I use the tank's X position and the current phase of the ground's animation to determine which wheels are up and which are down, and directly write the wheel positions into GRAM in my interrupt handler.

 

The vertical part of the physics model is very simple. When the player jumps, I just set the Y velocity to a fixed upward velocity. Then, each frame, if the Y position is above the baseline for the ground, I decrement the velocity (constant downward acceleration). Note that Space Patrol tracks this velocity and position separately from the other MOBs, just to make my life simpler.

 

The horizontal part is slightly more complex, since it also computes the display scrolling rate. I won't go into the details other than to say it outputs an X position for the tank.

 

And finally, the level checkpoint letter is managed separately of all of the above, although it could have been handled by the general animation code with a little effort.

 

 

Hopefully the above makes sense. The key takeaways are:

• For general animation, a decent segmentation seems to be:
  
  • Keep a velocity table somewhere, and add velocity to position every update. Fractional velocities are very handy.
    
  • Precomputing sprite attributes and storing them in ROM can be very handy.
    
  • Separating animation from position update is also handy
    
  • Complex animation behavior is better served by logic above the basic animation and movement code
    

  [*]Not all animation needs are served by the general code, so don't be afraid to handle some things with dedicated code, although it's not always the better choice.

I know this was a rather lengthy post. Feel free to ask questions!

Edited November 9, 2012 by intvnut

[+DZ-Jay]

I didn't mean to complicate this thread, honest.

 

I've seen for years how new people come into our community, full of ideas and enthusiasm, and start playing around with little demos and discrete functionality, only to eventually give up because it just takes too much time and effort, or because it's just too hard.

 

(That is not to suggest that you are going that way.)

 

So I always thought that it would be better to just jump right into the mess and start working on a game--at least a simple one--and see it evolve as your skills mature.

 

At the end you'll have, at worse a throwaway simple game, at best a full-fledge one ready for production. Either way, you'll have learned all that is needed for a full-fledged game, along with the exhilaration of having completed something useful.

 

At least that's what worked for me, but of course, your mileage will vary.

 

I'm definitely still a newbie, and intvnut has a lot more to offer in the ways of recommendations and suggestions than I. He is THE Intellivision programming guru.

 

So, I'm sorry if I seem at times overbearing in my suggestions or pushy; that's not my intention. I really want to see your game finished.

 

Regards,

dZ.

[Fushek]

I didn't mean to complicate this thread, honest.

 

I've seen for years how new people come into our community, full of ideas and enthusiasm, and start playing around with little demos and discrete functionality, only to eventually give up because it just takes too much time and effort, or because it's just too hard.

 

(That is not to suggest that you are going that way.)

 

So I always thought that it would be better to just jump right into the mess and start working on a game--at least a simple one--and see it evolve as your skills mature.

 

At the end you'll have, at worse a throwaway simple game, at best a full-fledge one ready for production. Either way, you'll have learned all that is needed for a full-fledged game, along with the exhilaration of having completed something useful.

 

At least that's what worked for me, but of course, your mileage will vary.

 

I'm definitely still a newbie, and intvnut has a lot more to offer in the ways of recommendations and suggestions than I. He is THE Intellivision programming guru.

 

So, I'm sorry if I seem at times overbearing in my suggestions or pushy; that's not my intention. I really want to see your game finished.

 

Regards,

dZ.

 

No need at all to apologize for anything! I appreciate any and all assistance from you and Intvnut ... you guys have been fantastic and I appreciate all the help! I was just trying to help you understand where I was coming from with some of my requests that I don't even know many of the basics yet and I'm not a programmer by trade.

 

And you haven't been pushy at all! I'm having fun learning ... and achieving minor victories.

 

It's funny that you talk about people starting here and never finishing ... when I was in high school, a friend of mine made fun of me because I had a tenancy to start projects and never finish them ... So when I started writing a book, he asked me how long my current "whim" would last. He pissed me off enough that I completed a 250 novel before I graduated high school. Now, it wasn't that good and it will never be published, but the feeling of satisfaction that I received being able to type "The End" was one that I will remember until the day that I die.

 

Anyways ... I'm really enjoying this in my spare time and want to continue on this journey even though it may be slow at times with my hectic schedule. Thanks again to both of you for all your ideas and assistance! It's great to have people in the community that are willing to help and actually have the patience to do so.

[+DZ-Jay]

I know the feeling. My wife has compiled a list of all the projects I've talked about doing throughout the years and either never started, or never completed. Our hope is for me get some focus and to eventually cross things off the list.

 

You know one thing that's been on that list for 5 years? "Pac-Man for the Intellivision." LOL!

 

Christmas Carol is a special case because I added it to the list just to cross it out. So no net change.

 

In any case, we're here to help. So ask away anything. The game is indeed looking good. I like the skeleton with the red eyes.

 

dZ.