Speaking of the “good old days”…creak…creak…
When I was in my young twenties, I had a job in a pinball/video arcade. The boss gave me a Sharp pocket computer of some sort, I can’t recall what it was, and asked if I could make a game or software on it. I can’t recall the exact chain of events, it was so long ago.
Anyway, I put on some typical business math software (calculate compounding interest, for example), using BASIC. And started working for him fulltime at $5/hr! I recall learning how to poke and peek directly onto the LCD display and writing three “games”. One was a sort of Pac-man rip, with the ‘maze’ being 3x3 pixel rooms on the display that was only 7 pixels tall. The other was based on something called Kaboom where you tried to hit/block pixels coming down the screen at you with one of three button paddles. I can’t recall what the 3rd game was, maybe a “hangman”? Some one else might have written that one.
Later we got into game writing in Forth. A couple members of our crew spent their time putting Forth on different CP/M operating system desktop computers (Sharp, Fujitsu, can’t recall what else), where 64KB of “clean memory” on the disk drive was a big deal! The rest of us wrote games that were sold, mostly in Japan. My boss came to me and said “write a Tank game”. So I wrote something called Laser Tanks, with big dumb enemy tanks randomly wandering a city block grid, and the hero tank a bit smaller but faster and maneuverable. The lasers shot clear across the screen. It kinda worked. A couple co-workers liked it enough to beat my high score, so I took that as a compliment.
I helped the other designers come up with ways to simplify their games so they would stay code-able. For example, one fellow had a neat concept with dirigibles flying overhead dropping bombs, and a maneuverable hero below shooting up at them. He was having trouble with response when tracking positions and collision testing, but we figured out that the simplification of making the enemy dirigibles stay on a single altitude would greatly help the collision tests, and he got the responsiveness back to an acceptable level.
It was fun but exhausting. This was 1980’s. I recall 60+ hr work weeks and occasionally sleeping under desks rather than going home. Ah, those were the days (NOT). [Something like 2/3rds of the programmers there suffered burnout and extended periods of “never going to program again”, self included. I think most are back at it now, in one form or another.]
I don’t know. If you have a constraint, there is a lot of ego-less ingenuity that can go into dealing with the constraint. A lot is just figuring out what is essential to a game’s playability, and what is fluff. With a tight constraint, one is forced to make merciless design decisions. Nowadays, with tons of RAM and processor speed, there is no need for self-discipline. Or rather, one can’t use “limited resources” as an excuse to triage one’s ever-so-precious ideas. So, it is easy to get into endless development trying to realize every idea. (“You are only limited by your imagination” – NOT a quote or concept that I buy into!)
Truly, having something like the Ludum Dare challenge is liberating in a strange way. Having been there/done that kind of sort of, I am less motivated to give LD a go, myself. But I can see where it is a great experience, to program in a tightly constrained environment as relief from the normal where one can drown in the abundance of resources.
There was a really good talk linked to, from this site. When I find the thread again I will post the link. (It was one I “appreciated”. Maybe there is a way to track back to one’s appreciations? Will look…) The speaker talks about three main constraints in programming: (1) memory, (2) cpu speed, (3) life energy.
[Here it is! Thanks Ultroman! http://www.java-gaming.org/topics/memory-then-and-now/27081/msg/241286/view.html#msg241286]
And it is true, I think, that it is easier to live under these constraints when they are imposed upon us, than to accept that one does not have unlimited life energy.
philfrei,
Damn, what an interesting story! I think you may be talking about something I read from Cas, and I particularly remember the function of life energy part, which resounded pretty well with me. Another thing he said were optimizations during the process of the game’s development were usually a waste of time, which I thought was pretty nice to hear too. I figure he was referring to more fine-tuned adjustments than to major tunings, though.
I’m impressed with your history! That’s truly amazing. Having only replied to that one post of yours and seen you around on the forums a little, I’d never have thought you had so much experience; it’s an honor! It must be a blessing and a curse to have come from the days when there were such constraints and then having plenty of everything that used to be scarce. I could imagine there were a lot of habits that stuck with you!
Colton
IHMO not enough of the newer generations of programmers understand hardware, so they can’t: “write high level, think low level”.
A particular example I was intrigued about was the fact that the Atari 2600 had 128 bytes of memory… bytes! That’d be four of Java’s ints! Of course, what variables they did use were probably much smaller. I was just trying to wrap my head around how I could write a game like Adventure or Pitfall or some game of equal caliber while keeping such a low volume of information in memory. From what I also read, however, cartridges came often with memory extensions built in to help with that issue, but even still… it’s astounding. It makes me want to fire up an emulator and get to work coding for consoles and computers of old just to acquire that experience. Actually, I do have the Gameboy SDK that I was tinkering with in C a while back; perhaps I can fire that puppy back up ;]
Colton
bits are not bytes. 128 bytes are 32 java ints.
And all the memory was for state data (remember there’s a ROM). You might put some code in RAM for self-modify code.
So let’s see, I’ve made myself look like an idiot 1, 2, at least 3 times today! 
I don’t understand what’s going on with me. I wasn’t thinking when I wrote that post, apparently.
Regardless, 128 bytes is still pretty scarce. 
True. Ordinarily I’d say something pertinent right here, but the trend so far today has been whenever my mouth opens, garbage and feces spill out
Speaking of low RAM gaming.
How about a “MicroRam” Java Contest.
Somehow severely limiting the Heap Memory allowed to be used.
Im not shure how that would technically work over the different JVM Versions (maybe running a anlysis program to assess
the actual used memory by the game, while ignoring the JVMs inherend Memory use that cant be avoided)
the “-Xmx1m -Xmx1m” probably does not give a constant usable amount of memory on different systems.
Or the programmer is only allowed to use a bye array
byte[] mem=new byte[256];
as workmemory, and can not instantiate any objects or variables apart from it.
(excluding a fixed minimal set of Input/Output functions to interface with the machine)
Im shure it would be a nice challenge.
I think that would be very interesting, actually! I’d be interested in seeing what the more experienced people here could come up with; I probably couldn’t come up with much. I’m fairly sure the contestants could be tested with profilers to make sure they don’t exceed an established guideline amount of memory; this way, their methods on top of their variables could be monitored. I’m sure there’s a better way to do it, but that’s the first thing that pops into my head.
Colton
It’s be easier to have a virtual machine to program to. (Humm…I have a java 6502 emulator that I wrote somewhere). A vector machine would be fun.
Ah, yes, that’d be cool. Gotta love emulators. For a case like this, I think your 6502 would be perfect. :]
Colton
Yes, I think there needs to be some virtual (fixed) Machine to be interfaced to.
It does not really need to be some real-life machine. But something that suits the purpose of running a game.
So this virtual machine is providing input events, and accepts output events to it fixed-size “video RAM” and sound generator.
The gamelogic gets to strict limit to only use a size limited amount of static memory.
(no dynamic instancing, everything has to be computed using a staitic array of ints,booleans or bytes, wich have an upper limit)
Precisely. And then perhaps the winner of the competition can have a special thread made in Showcase to show their results? Or perhaps a new forum branch can be opened dedicated to showcasing just these, if there are enough? How many moderators say “Aye” or have other suggestions?
Artificial limitations are fun, but would a java forum be the best place?
Why not make a tiny JVM (no allocateable objects, only static methods) instead, then it makes sense. :persecutioncomplex:
Sure, why not! ;D I figured it’d be cool though among the members here at the forum, but I mean maybe even at GameDev or something of the like, the competition could be advertised, where they have a larger volume of members. We don’t even really need to use a JVM, because many emulators, like I mentioned before, offer the ability to program virtual tapes and disks and whatnot and some have SDKs, so one of those could be established as the required interface and then would be just a required download for anyone involved. I don’t know; just my thoughts! :}
Colton
Does anyone have experiene with open source JVMs?
In the end, this JVM could be used as a pure verification engine, to assert that the game runs in the low-mem requirements.
While also running in the Standard JVM to be visible to the public.
Memory then is to Memory now as Processing speed now is to Processing speed with quantum computers in 10 years time blown out of the milky way.
BigO notation will be renamed LittleO™ and people will start to analyze how best to slow down the quantum processing speed in order for us to have time to see all the things that it’s doing.
After that we could really benefit from a room temperature superconductive wire.
After that, we need to figure out how to send/receive signals faster than light. Something to do with Avogadro I’m guessing.
:}