This one goes to nostalgia, old school and to my hobby corner. 🙂
Below is the video regarding this post:
The video starts with traditional old school 2D stars, then the video continues with 3D cube that has the 2D star field as texture. Each face of the cube is transparent, so you see the starfields of the cube from different faces at once… The cube fades into the background slowly…
I haven’t done much 3D programming in Blitz3D, but this kind of code is quite easy for a beginner like me to put together.
I remember, that in the good old Amiga days I saw an amazing Amiga demo, that had star field in rotating cube. Those Amiga demos were a lot more complicated to program, since they were low level assembly code using directly Amiga’s hardware. The idea to program this in Blitz3D came from one Amiga demo music remix tune, that has little speech in it: “A star field in a box. Oh my God, it’s rotating!” 🙂
For example in my Memorable Ladies games it is the case that I needed a method that gives a random integer for example between 0…31 so that any integer that has once been drawn, doesn’t get drawn anymore.
One way to handle this (how I didn’t do it) could be for example to use Rand-function (depending on programming language one is using) that gives an integer between n…m (m > n) and make a list of numbers that are already drawn and use Rand-function again between n…m, if the integer given by Rand has already been drawn.
But in the worst case this could lead to infinite loop… In practice probably not, though. In order to avoid the infinite loop (the case where Rand function gives repeatedly a number that has already been drawn), one could for example increase the drawn number by 1 until unused number is found or go on to m and if needed start from n and increase the value by 1 until unused number is found.
In Memorable Ladies games speed isn’t critical factor, when the numbers are drawn, so in this particular case the routine doesn’t necessarily need to be fast. In addition the amount of data can be considered very small.
What I came up, was something where every random number is (in practice) necessarily unique and without possibility to get stuck on infinite loop.
The idea goes like this:
Let us assume that we need n integers between 0….n – 1
Make a list of numbers with type ”number” where type ”number” has as a member an integer between 0…n – 1(the numbers can be in increasing order)
Draw an integer between 0…n – 1. Let this be i.
Get from the list ith ”number” element and get the integer that is in that ”number” element as a member and then delete that element from the list
Decrease n by 1
Repeat until list is empty
Even if in the original list of type ”number” the integers are ordered from 0 to n – 1, one would get this way an unique random integer each time (except if Rand gives zero (0) n times).
There are more sophisticated ways to do this, especially if the set of needed integers is large.
Image courtesy of Stuart Miles at FreeDigitalPhotos.net
For the sake of nostalgia… Let be mentioned what kind of random number generator I have used with Amiga with MC68040’s built-in FPU in assembly. As such this doesn’t give an unique random number, though.
(In the source code of my old Quest of Love demo you can see this in practice)
Let us assume, that we need an integer between 0…n.
Get the vertical beam value from $dff006
”Scale” the previous value with desired integer in order to get it big enough
Use FPU’s fsin instruction (sine function) to that value
Use FPU’s fabs instruction (absolute value) to the value we got in the previous step
Now we have a floating point value between 0…1
Multiply that value by n
Convert the value of previous step to integer
If we would like to have an integer between n…m (0 < n < m)the additional steps would be
Let z = m – n
Add z to the integer we got in the last step earlier
The two steps above are only the idea to get the value to the desired interval; in assembly there are not variables at all as we know them in programming languages of higher level.
This idea probably gives you a good idea how to get random integers with Monkey X’s Rnd() that gives a random value between 0…1. 🙂
Probably the most common way is to do something like following:
value = Rnd() * 100 Mod n
This gives a random integer between 0…n – 1 (0 < n <= 100 above). Notice that in the sentence above there are two possibilities to get zero: 1) Rnd() gives 0, 2) Rnd() gives 1 and n = 100.
It all started in 1984, when in Finland the prices of home computers were significantly reduced. One could buy a home computer for under 1000 Finnish marks. That’s about 167 euros. My parents bought me a Commodore Vic 20, that costed 999 Finnish marks.
I really liked the first (and at the time only) game I got with Vic 20: Radar Rat Race. See below a picture of the module:
Below is a YouTube video from the game:
I remember that the game had some bug though: When one got far enough, playing the game became somehow impossible.
Another game I liked, was Fire Galaxy. Below is a little video from the game:
A bit later my Commodore 64 times began.
At those days I saw many C64 games. The most remarkable games from me at the time were Ultima IV: Quest of the Avatar and Ultima V: Warriors of Destiny. Ah, the story of the games and all the philosophy in them… Especially the three principles (of the eight virtues): Love, Truth and Courage. These define the good in the games. Evil is defined as ”principles” of the opposite of the mentioned: hate, falsehood and cowardice.
As to choosing the character in these games, I always answered the philosophical questions as myself, not by trying to get my character certain quality. As a result of this, my character became to be of the weakest profession in the game: The shepherd.
Intro from C64’s Ultima IV:
Intro from Ultima V (C64/C128):
When running the game on the C64, there isn’t background music, the sound effects only, because the game is so huge, that C64 hasn’t enough memory for the music.
Boulder Dash and Boulder Dash II were my favourites too.
Below is a video from both games:
I played a lot also Delta, a game by a Finnish programmer Stavros Fasoulas (music by famous Rob Hubbard), see the video below:
One good game for the C64 that teaches also some strategy is Paradroid. There are many remakes of this classic game also to PC.
Commodore 64’s Tetris has incredible music!
There are many games in the world of Commodore 64 that I wasn’t really interested in, but the music is incredible. As an example I must mention Cybernoid II:
Some games were simple and fun to play with good graphics and music, but let the player down with one thing: There was no ending of anykind! I remember playing ”endlessly” both International Karate and IK+ with black belt, but the games just went on and on…
As an youngster I decided, that if I was ever to program a computer game, it would always have an ending.
One incredible C64 game I remember, is Wizball:
Some C64 games I liked, were kind of games that often other people didn’t like. As an example let me mention Armourdillo:
the music of Armourdillo:
If my memory serves my right, I played Armourdillo with music.
Another game, that I almost forget as an example of a game that other people often didn’t seem to like was Master of Lamps:
For the third example of game that the other people didn’t seem to like, but was fun to me as a kid is Poster Paster:
As to Defender of the Crown, I liked C64’s version more than Amiga’s, altough the Amiga version has better graphics and music.
One very good game I almost forgot to the C64 is Thrust:
With Spy vs. Spy II we both, I and one of my friends had lots of fun. We made lots of traps to each other in order to get to that submarine and win the game. There might be one “room” filled with so many traps while we were playing the game, that in practice there was only one special way to get through the room.
One special game from the year 1984: Ghostbusters. Why this game was special? At the time I was Vic 20 user and to me (and to many others) it was simply amazing to hear so authentic speech from a movie in a computer game! What a miracle computer C64 was: With it one can even listen little parts of authentic speech from a movie in a game. How we were amazed!
A game that made many of us laugh, when we were kids, is Super Pipeline II. A fun quality game with nice music and funny graphics and not too hard to finish.
One funny detail from the past in the 80s in our C64 times was C64’s Commando; first the other boys told how hard game Commando is. Eventually one of my friends tried to play Commando for the first time in his life (and this was the first time he saw the game too) and this one friend managed to finish the game from the very beginning to the end at his first try — how the other boys were confused. “Yeah, really hard game!”, he said with little sarcasm.
A game that required fast thinking and good reflexes and gave us visually something new compared to what we had seen before was Cosmic Causeway:
For the end let be mentioned some early gems in the world of Commodore 64 games: M.U.L.E., Archon and Archon II.
Perhaps I come back later with my Amiga gaming history…
This time a little tutorial on how to use images as buttons in BlitzMax with MaxGUI module.
For beginners the most important thing is to understand the event loop.
The image buttons are made with panels that have background graphics. The source below clarifies the rest.
In order to try the code, download the following images:
Save the images to the same folder where you save the code below. In order to get the code working with images, name the violet background picture as “demobg.png” and the blue “Button” labeled images as “button1.png” and “button2.png” and the rest “Button” labeled images as “button1sel.png” and “button2sel.png”.
The code uses gadget sensitivity to change the button images when touched with the mouse.
Again, some nostalgia. In older blog post I presented a shortened version of my old implementation of Amiga’s “Missile Attack”. This night I made the game in Monkey X and the source can be directly compiled to Android target.
The game is quite simple one: Just shoot the missiles before they get to the bottom of the screen.
If a missile goes to the left or right side of the screen, you see the colors of the background changing — and also when you fire a shot. This gives the game more life. 🙂
Below is the source code:
Fieldx:Float' x-coordinate of a missile
Fieldy:Float' y-coordinate of a missile
' the color of the missile
GlobalmissileList:=NewList<Missile>' build a missile list
' Mathematical way to determine if player's shot has hit the missile...
(Updated 03/05/2017 with improved source code and new video)
A little update to older post. As the title of the post says we’re making a worm game (in Monkey X). In this version the worm is controlled by touching the screen keeping in mind that the game is really aimed to Android.
I’ll explain here how the worm is controlled.
If you move your finger ”up” from the worm’s head, the worm goes to that direction and respectively to other directions.
See the video below:
The direction is determined by comparing two subsequent update rounds’ TouchX() and TouchY() coordinates.
The test can’t be straightforward TouchX() or TouchY() test, because the player probably won’t move his/her finger absolutely to one of the four directions the worm is to be controlled.
This is why there is another test in controlling the worm: The absolute values of difference of the two subsequent update round’s TouchX() and TouchY() coordinates. If the player wants to control the worm ”up”, the player probably has moved his/her finger more vertically than horizontally.
DrawText"Move your finger on the screen to control the worm",(640-TextWidth("Move your finger on the screen to control the worm"))/2,40
DrawText"Touch anywhere to start",(640-TextWidth("Touch anywhere to start"))/2,70
DrawText"Worm Length: "+wormLength,0,0
Source code license: Public domain.
Notice, that in this code one part of the worm’s “body” is 17 x 17 pixels, but the worm moves with step of one pixel and can be controlled with accuracy of one pixel. The example code above is simple implementation of this kind of worm game. The down side of the code is, that the sizes of the arrays for x– and y-coordinates depend of the length of the worm in pixels.
I may come back later with some implementation with different concept of moving the worm of which “body” is built with “blocks” of different size than one pixel, but the worm is controlled with accuracy of one pixel, without using arrays of which lengths depend on the size of the worm in pixels.