Peer
Forum Replies Created
-
Posts
-
Just a sidenote, but well worth mentioning: Jerome was one of the main beta testers of Vec-Man and greatly helped shaping the final version into what it is now 🙂 Thanks again!
As for the VB crashes:
Have these crashes been experienced by several different testers on several different machines?
Is there strict evidence that the reason is on the software side? Can we definitly rule out that the reason is probably on the hardware side? Some aged or worn out physical part, capacitor, pin connection, …, etc. in the console? Or in the eprom?
If it is on the software side, then the fact that all of us have not experienced it in debug/demo mode, might indeed be an indicator for a Heisenbug, i.e. a bug that is gone once some debug code is added. So in which way does the debug code alter the timing or behavior of the original code?
I think Helmut’s suggestion is a good one: Let us see if we can reproduce the crash in non-debug demo mode. Or maybe with a debug version that gives less debug information? Meaning one where the diff to the original code is less and which thus is probably less Heisen-buggy?
Sorry, I am tired, and I hope this makes sense, but I couldn’t get these thoughts out of me head.
Cheers,
PeerEDIT: Hehe, while I was writing the above, all your last posts came in…
Sorry I couldn’t join in earlier. Converting all my lectures to online presentations has kept and still keeps me quite busy, and the first is supposed to start tomorrow…
So far I managed to let VB run for approx. 4 hours on a buzz, and 2 hours on a no-buzz Vectrex. No crashes. I will continue testing tomorrow.
Cheers,
Peer
@Jerome: Great to see you here!!!@Helmut: Yes, sorry for being a bit silent in the past weeks 🙂 The end of the semester was busy as hell, and then we already left for vacation (10 hours overnight drive to the Danish Border, “Nordfriesland”, my old hometown where I grew up).
I know what your point is, and, in essence, I agree with you. My point is slightly different. First of all, this is just an idea, not reall a suggestion for Vectorblade. But it was/is fun to think about. I always like playing with ideas 🙂
I do not like games in which the outcome or the player’s success strictly depends on random elements or on luck, in the sense that you cannot beat the game without relying on luck. With regard to VectorBlade, I think that this is definitely not the case. The game can be beat without e.g. obtaining the laser, also without discovering certain secrets etc. Agreed, those make life a lot easier, but technically they are not a prerequisite. In that sense, adding certain “fortunate” events or elements to the game for me is okay.
Now, in terms of the slot machine idea, this is rather gambling than pure randomness. The difference is that the player has the choice not to gamble at all! Also, if the slot is played, the player can end up in a state that is worse than before (money lost). The outcome of the slot certainly depends on fortune or luck or randomness. But that is a risk the player can freely decide to take or not to take.
But, as I said, that is just an idea I played with in my mind on one of our bicycle tours here. And sorry for hijacking this thread and writing all this here 😉
Many Cheers,
PeerI like the wheel of fortune. I know that you have feature freeze, but this led to another idea:
If you are mean, you could add a slot machine to the shop. Instead of buying some item, the player could also gamble. Select slot machine, bet a certain amound of money (or a fixed amount?), then run the slot machine, and either loose the money or win a certain item (depending on the amount of money bet?) or win additional money. Warning: like in real life, slots make addictive! If you are really mean, you could give the player the false impression that the slot is not totally random, but that the outcome could be influenced by pressing a stop button or something alike.
You know, just an idea that crossed my mind 😉
In terms of code this shouldn’t be too expensive (sharing of subroutines).
Cheers,
PeerSorry, I am typing this in a hurry (I am on vacation right now). If anything is unclear or sounds weird, please apologize and let me know 😉
I did not post much in the past weeks, but I actually played quite a lot. I also showed VectorBlade to my students and let them play at three occasions. I did not tell them any insider stuff, just watched them. They all figured out to collect the EXTRA letters pretty quickly, but none of them ever came up with the idea of collecting them in the correct order. So in that sense I agree with Helmut and I think that it should not be made even more unlikely to achieve this.
Cheers,
PeerHi guys, and sorry for the long silence. The semester is at its end, and right now all the exams are taking place and I am completely busy grading papers. Hope to find more time for testing soon. Still, some quick notes:
VecVox: I liked it, and I think this is pretty cool and should be kept.
Laser: Oh what fun! At least for me it does not (yet) make things too easy, but admittedly I lack training and am not a great player right now.
Major Havoc: 4000 bytes left. Is it worth / Do you want to try saving some more bytes in other places? There is some potential in simply rephrasing / shortening some parts of the help texts.
GeoAnas: Since I do not have an email adress of yours, I shot you a PM some time ago on the Vector Gaming Forum. Not sure if you read there. I have some questions regarding the Commodore C64.
Cheers,
PeerGreat video! Now that I watched it, I realized that I forgot to mention one of my notes from testing: after completing the very first calibration (right after burning the rom), the game goes directly to the desktop. No Vectorblade/ship animation plus title music. Is this intentional?
As far as I know, regarding the numbers, in military ranks there is no “uniform” system (pun intended): e.g. officer 1st class ranks higher than officer 2nd class, 4 star general ranks higher than 3 star general. Then there are also gold, silver and bronze ranks, in obvious order.
Argh, yes, you are right of course. Sorry, I have not yet gotten to the queen that often, shame on me. I simply remembered that incorrectly. Only thing I recalled was the animation of the queen and the ship coming in.
Sorry, to clarify, I meant some sort of textual information while progressing from one stage/phase of the game to the next stage/phase.
For the levels, this is the “Level <number>” information. For the bosses, there is the graphical animation (which could still be preceeded by some text “Boss Alert!”, but that is something which I personally do not need). For the shop, something like “Entering Shop” would make it perfectly clear what comes next. Such things would add to a uniform appearance of the complete story of the game. But, just ideas…
You beta testers as a bunch are killing me :-).
One wants help text, the other wants to figure out stuff.
Easy solution: During initial calibration, let the user choose whether they want help text or want to figure out things!
Ok, just kidding… 😉
One wants to get rid of text, and the other wants to put a big sign “SHOP” on the shop… to know its a SHOP :-)…
Well, there is something to be concluded from his. If there is a sign “SHOP”, then there is no need for a help text saying “You are now in the shop”, and vice versa. If there is some transition between the end of a level and the shop, saying “Entering Shop”, then there is no need for either a help text or a “SHOP” sign.
This brings up another idea. Each level begins with a short intro, the morphing letters “Level <number>”. The game would have a consistent and unique look, if such a thing would be done for all transistions between stages, i.e. “Entering Shop”, “Boss Level!”, “Mine Storm”, “Major Havoc” (right now, there is no such thing for shop and bosses, and the havoc intro looks completely different). Note, those are just ideas 🙂
(as this was mentioned in this thread before, I am also posting this here)
Regarding the help texts, I think a dictionary (though in general a clever method) is overkill here. I strongly guess that there is not “enough” text to yield a good compression ratio (you have to store 2 byte pointers for each word), even more so as the decompression algorithm is not trivial and also consumes rom space.
So, question: Do you want to try to save some help text bytes in favor of major havoc, or not?
If not that is perfectly fine.
If so, I would offer to try to come up with a shortened and more concise version of the texts. Let me know if you want this.
If you also want to consider (additional) data compression, you could go for a simple approach: use a “5 bits per character” encoding, and store the text(s) as groups of “5 bytes per 8 characters”. The nibbles of the first 4 bytes contain the lower 4 bits of each character, byte 5 contains the 8 upper bits of the 8 characters. Compression ratio is 5/8, and the decoding would require only minimal changes of the printing routine. Unless your storage & printing works completely different 😉
