Most impactful limitation to game programming?

[+cmadruga]

Just out of curiosity, I was wondering what folks here - mainly those who are involved in game programming - consider to be the most impactful graphic/visual limitation of the platform.

Meaning: what tends to get in the way most often as you try to achieve your vision:

 

- number of sprites?

- colors per sprite?

- colors per tile?

- color modes?

- other...?

 

I think resolution “is what it is”, so no point bringing it up, but feel free to disagree...

A second question would be: what techniques do you normally use to alleviate the constraint you mention?

 

[Arnauld]

A somewhat less obvious but quite impactful limitation is the number of cycles during which the CPU has access to the STIC and the GRAM. As a programmer, I think I'll put that one at the top of the list as it often leads to impossible or complicated situations. For instance, in the kiss scene of Defender of the Crown, I had to use self-generating code: at frame N, the program generates the code that will be used to update only the GRAM rows that actually need to be updated during the next VBLANK for frame N+1, because we don't have enough time to update the full cards.

 

As a game designer, I'd probably say the number of sprites. But it really depends on the game type.

 

Edited January 3, 2020 by Arnauld
typo

[skywaffle]

I have to say the 8 1-bit sprites is the biggest limitation,  8x16 resolution per sprite makes things even worse.  However, being 1979 hardware, it's pretty impressive compared to the competition.   I also wish there was a way to interrupt the scrolling to allow for a stationary status bar with a scrolling background above or below it. 

 

Still though, in comparison to other consoles pre-Famicom, it's an impressive machine.

 

Multiplexing sprites helps a little with achieving more objects, and I don't think it looks too bad on a CRT television.  I still have never found an ideal way to display information for the player during gameplay with scrolling though.

 

[+atari2600land]

The problem I have been running into most with the Intellivision using INTVBasic is the 16 colors. Not only are there only 16 of them, some of them are really dreadful, especially the second set of 8. Who would use ultra hot pink in a game? The only reason I can think of is a pig.

[+Steve Jones]

2 hours ago, Arnauld said:

A somewhat less obvious but quite impactful limitation is the number of cycles during which the CPU has access to the STIC and the GRAM. As a programmer, I think I'll put that one at the top of the list as it often leads to impossible or complicated situations. For instance, in the kiss scene of Defender of the Crown, I had to use self-generating code: at frame N, the program generates the code that will be used to update only the GRAM rows that actually need to be updated during the next VBLANK for frame N+1, because we don't have enough time to update the full cards.

 

As a game designer, I'd probably say the number of sprites. But it really depends on the game type.

 

Hey Arnauld, unrelated question but since you are around I will ask, any plans to finish Rick Dangerous?

I've played the rom that came out years ago and it looks great, just needs some bad guys etc.

Would love to see this game completed.

[mr_me]

1 hour ago, skywaffle said:

8x16 resolution per sprite makes things even worse

How does a higher resolution sprite make things worse, other than taking up more gram?

[+cmadruga]

7 minutes ago, mr_me said:

How does a higher resolution sprite make things worse, other than taking up more gram?

I interpreted that as “the size is too small”, but let’s see what he says.

[Arnauld]

51 minutes ago, Steve Jones said:

Hey Arnauld, unrelated question but since you are around I will ask, any plans to finish Rick Dangerous?

I've played the rom that came out years ago and it looks great, just needs some bad guys etc.

Would love to see this game completed.

It's not Rick Dangerous anymore, as we can't use the original title. But you should hear about Rick Dynamite in the near future.

[+Steve Jones]

That's great news, looking forward to it.

[+cmadruga]

5 hours ago, Arnauld said:

A somewhat less obvious but quite impactful limitation is the number of cycles during which the CPU has access to the STIC and the GRAM. As a programmer, I think I'll put that one at the top of the list as it often leads to impossible or complicated situations. For instance, in the kiss scene of Defender of the Crown, I had to use self-generating code: at frame N, the program generates the code that will be used to update only the GRAM rows that actually need to be updated during the next VBLANK for frame N+1, because we don't have enough time to update the full cards.

 

As a game designer, I'd probably say the number of sprites. But it really depends on the game type.

 

Interesting, the use of that self-generating  code. Does it do that by comparing 2 consecutive frames and determining on its own which cards that need to be updated?
Or is the list of cards to be updated pre-determined, and the code self-adjusts to execute it somehow?

Edited January 3, 2020 by cmadruga

[+cmadruga]

2 hours ago, cmadruga said:

I interpreted that as “the size is too small”, but let’s see what he says.

Come on, no one will say “that’s what she said”? ? One does not waste opportunities like this.

[Arnauld]

14 minutes ago, cmadruga said:

Interesting, the use of that self-generating  code. Does it do that by comparing 2 consecutive frames and determining on its own which cards need updated?
Or is the list of cards to be updated pre-determined, and the code self-adjusts to execute it somehow?

The differences between 2 consecutive frames are pre-computed at build time and stored as bitmasks representing the cards and rows to update, followed by the graphics data. Storing the full frames and computing the differences at run time would require more storage and -- first and foremost -- much more CPU time.

[+nanochess]

I think the greatest limitation is the limit of 64 definable cards, and the other is having only 8 sprites.

[eddhell]

(I realize there are more allowed with -jlp switch, but without it...)

 

This is not really 'graphical', but important to me...

The limitations on variables being dependent on other command usage....20 16-bit variables eaten up from using SCROLL command???  I wish there was a way to define how many and what type of variables to use, more 16-bit variables would take away from the 8-bit vars.....I know most of you probably never need that, and you can use multiple 8-bit vars and some code to come up with solutions, but defining them from the start would be sooooo much easier.  

(I'm interested in strategy and board game conversions, and 2-4 player games can eat up tons of variables.  Everything you have to keep track of is multiplied by the number of players!)

I also hate eating up 8-bit variables for just ON/OFF flags.  I know you could use bits from already used variables, but once again, more code and workaround.

 

As far as actual graphics:

Sprite priority can get messy, depending on which ones need to be in front or behind the others.

Edited January 4, 2020 by eddhell

[mr_me]

Adding a bit of ram to the cartridge, for variables, would be a reasonable thing to do even back in the 1980s.

[eddhell]

22 minutes ago, mr_me said:

Adding a bit of ram to the cartridge, for variables, would be a reasonable thing to do even back in the 1980s.

but not necessarily in 1977-1979....

[+cmadruga]

2 hours ago, eddhell said:

(I'm interested in strategy and board game conversions,

What types of games are you thinking?

[eddhell]

table top style RPG's (would have to be 'lite' versions more than likely), strategy games like Risk, Catan, etc...  

I would love a version of M.U.L.E., but that to me is pointless (nothing would ever be able to replace original and any modifications would probably ruin it)

although I am interested in any games that have real time changes (like the economy and price fluctuation in MULE, population in Utopia, or a stock market sim)

there are also tons of Avalon Hill games that may make nice conversions.

there are lots of regular and custom card games I would like to see, but some would have way too many options or too much data for older systems....

 

I would also love to see an open-ended version of Auto Duel (or Car Wars depending on the decade you're from!) or RoadWar 2000, basically anything with vehicular combat.

 

I wouldn't mind seeing a digital version of the old 1980's MAD Magazine board game (basically the polar opposite of Monopoly), but the artwork on the game board is what really makes the game fun, and that's way too much detail for early systems.... 

 

So far, the Intellivision works best for some of these types of games, since the background can be setup by 'cards', it lends itself almost naturally to board games with squares...

Edited January 5, 2020 by eddhell

[eddhell]

and I almost forgot another favorite - Seven Cities of Gold....could be remade with different themes (outer space exploration, a wasteland like Fallout, etc.) as long as it keeps the 'random land generator' so each game is unique.  But I don't think it could be perfectly emulated on any system before the A8 computers, because it was such a complicated set of calculations...that game didn't just 'throw' random land pieces together, it actually did calculations to make a realistic land mass with indigenous species placed properly...

[skywaffle]

On 1/3/2020 at 11:03 AM, mr_me said:

How does a higher resolution sprite make things worse, other than taking up more gram?

I wish that in addition to 8x8 or 8x16, there could have been a 16x8 option, or 16x16.  But of course this is still 1979 hardware.  I am still impressed with what can be done.  It certainly is leaps over Odyssey2, Channel F, and Bally Astrocade. 

[+cmadruga]

13 hours ago, eddhell said:

and I almost forgot another favorite - Seven Cities of Gold....could be remade with different themes (outer space exploration, a wasteland like Fallout, etc.) as long as it keeps the 'random land generator' so each game is unique.  But I don't think it could be perfectly emulated on any system before the A8 computers, because it was such a complicated set of calculations...that game didn't just 'throw' random land pieces together, it actually did calculations to make a realistic land mass with indigenous species placed properly...

I'm familiar with the games you mention, except for the MAD one...

That reminds me that a while ago someone made a game inspired by Incan Gold / Diamant for Intellivision, I think it was for one of the competitions.

 

I think the most challenging aspect of programming a board game is the AI.

It definitely helps if the game has rules for solo play. I have looked into the following in the past...

https://www.boardgamegeek.com/boardgame/2613/intruder

https://www.boardgamegeek.com/boardgame/28044/pocket-civ

 

 

 

[mr_me]

1 hour ago, skywaffle said:

I wish that in addition to 8x8 or 8x16, there could have been a 16x8 option, or 16x16.  But of course this is still 1979 hardware.  I am still impressed with what can be done.  It certainly is leaps over Odyssey2, Channel F, and Bally Astrocade. 

Well the intellivision does 64 sprite pixels per scanline, same as the MSX or NES.  Doubling it to 128 would put it in Amiga or SMS territory.

[eddhell]

9 hours ago, cmadruga said:

I think the most challenging aspect of programming a board game is the AI.

 

That is where I am completely stumped.  I could make a 'dummy' AI to just to take up space, but a logical thinking on a strategic level - some of these games would take miles of code with all the comparisons to find out the 'best' option....also, the 'best' move might change depending on other circumstances....Ouch....makes my head hurt...

[artrag]

The ram for these algorithms is also a problem 

[mr_me]

39 minutes ago, artrag said:

The ram for these algorithms is also a problem 

More so than a chess algorithn?