Todavía me acuerdo de la primera vez que instale Windows 95.
Cuando mi pobre 386 termino de cargar, pasé un buen rato mirando las opciones de colores, configuración, y después… creando iconos para mis juegos de DOS. El hecho es que en 1995 no había muchos juegos interesantes para Windows.
Para 1998, las cosas habían cambiado bastante, y gracias a DirectX, prácticamente todos los juegos salían directamente para Windows.
Así que, cuando tuve Windows 98 (2a. edición!) pronto, llego el momento de instalar, no solo el US Navy Fighters, sino también algunos de mis juegos favoritos de todos los tiempos y otros clásicos.
US Navy Fighters 97:
Advanced Dungeons and Dragons rules:
No One Lives Forever:
Blood 2: The Chosen:
European Air Warrior:
Heroes of Might and Magic III
Ahora, a jugar!
That is why, a few days ago, when feeling a bit bored and finding some time in my hands, I started another project. Let’s call it … “Trench of Death”
Just as “Furious Felines” was inspired by “Angry Birds”, “Trench of Death” draws from another modern classic, “Plants vs. Zombies”, but with a scenario changed from a garden to the Death Star.
I guess that everyone remembers the attack against the Death Star at the climax of the original Star Wars movie. The attacking ships have to go through a long, straight “trench” to get to their final target, while turbolasers and TIe fighters try to shoot them down.
In this game, you’ll have to set the defenses along the trench, to prevent the attacking crafts from reaching their target. The ships will be coming from a trench 10 cells long, were you can place guns at 3 sides.
Each gun will have different cost, a “time to build” and power ratings. After the player selects the type of gun to be installed, they will place it either on the sides of the trench, or at the end, meaning that the incoming crafts will be fired upon from the sides and the front.
I have already coded 10 types of gun turrets for defense, and 8 types of attacking crafts, and done some testing to evaluate the game balance.
So far, I don’t have much to show. I have coded the attacking craft movement routines, and tested it with a squadron of 8 ships. Speed seems to be acceptable even with fake routines added to represent the joystick input and gun firing routines.
Next up, allow the player to select a type of gun, and place it in one of the designated spots.
I hope I’ll be able to do it this weekend.
A few weeks ago I was bored and stuck with a PC were I couldn’t run my 8 bit emulators. I then decided to go for QB64 and start on a project that had been running around my head for quite a while.
I’ve always wanted to write an adventure game, something like the classics from LucasArts, or Zork. And I had realized that writing an “engine” would probably be no more difficult than a stand alone game, with the advantage that creating new games would be much easier.
So I started working on what is now “eSage” (for ‘extremely simple adventures game engine’)
It turned out to be far easier than expected, and that led me to keep adding new features, to the point where I had to write a manual, because I couldn’t remember all the commands I had implemented.
The system is quite simple. Each game is divided in “Steps”, in which you are given options that will take you to other Steps, not unlike those “create your own adventure” books.
Each Step has a background image and sound, as many additional images and text as you want, with a list of options that determine to which Steps you can jump to, and the score that you get for choosing that option.
I eventually added support for multiple fonts and colors, random jumps, and a few other features.
It is still not finished, but I think that any improvements that I add from now on will not break the scripts from current games. In short, this means that if you create a game now, and I update the engine, your game will still work.
Here is a sample script:
Number of steps,5
text You are the new Captain of the USS Enterprise/H180/V5/C030444
text and have been ordered to patrol/H385/V6/C030444
text the Romulan Neutral Zone/H350/V8/C030444
Option Helm, set a course/3/10
Option No way, that is dangerous. Helm set a course for Risa/2/0
text While “relaxing” in Risa, you get a VD!/H250/V9/C400004
text Your career in Starfleet is ruined!/H280/V10/C400004
text Sir! A Bird of Prey decloaking on the starboard bow!//H280/V10/C400004/F2
Option Fire at will/4/3
Option Hail them/10/3
In a few days, I will be uploading the “runtime” program, eSage itself, and the manual, to http://www.hscomputadoras.com/HERMESOFT/hermesoft.html
After the success(?) of Furious Felines I started thinking about which would be my next project.
For some time I considered a port of “Felines” to PC, or to mobile platforms. Perhaps, but not right now.
But that reminded me of another game I wrote years ago for the CoCo, “Submarine Hunter“.
I did port, or actually, create a much improved version for the PC platform in 2012.
The PC version has, of course, far better graphics, but also the gameplay was improved. (I hope).
I realized that a far better CoCo version is possible, and decided to get on with it. I’m almost sure that most of the code can be reused from either the original CoCo version or the PC port, and with that in mind, I started creating the graphics. I plan to manage the graphics as I did in “Furious Felines”, drawing all the graphics in an intro screen that will then be loaded from the main program. This makes it easier to update the graphics, and keeps the file with the program’s code smaller.
So, here is a preview.
After the last change, when the game is run, there is a few seconds delay while the screen is being loaded.
At first, I was just going to add a simple “Please wait, loading” message, but I couldn’t help myself.
While adding more graphics, I realized that the initial screen was taking longer and longer to draw. It’s not fun waiting for a minute or more while the game “loads”. But there is a solution for that.
I moved the code that draws the graphics and intro screen to a separate program. Then, using the code from HSAVE, saved the screen and color palette into 3 files.Now, the main game file, FELINES.BAS loads those files to display the intro screen, and then captures the in-game graphics (HGET) from there.
Now it takes less than half the time to finish the intro screen than before, and I can add as many graphics as I want without affecting loading time. The only drawback is that the files that make up the screen, – FELINES.PAL, FELINES.SC1, FELINES.SC2 – are quite big, +32 KiB total. The whole game is now almost 38 KiB. quite big, but still fits comfortably in any floppy disk
With just a few days left before the Annual “Last” Chicago CoCoFEST!, I had to get in gear. I had submitted a preview version of “Furious Felines” for the CoCo Coding Contest, but it was far from what I wanted the game to be.
First, I had to discard the idea of playing music while drawing the introduction screen. I had hoped to play a recognizable tune, playing one note after drawing each line in the cat’s graphics, but it slowed everything too much, and the music did not work fine.
The biggest change came when I decided that the game will allow you to, once you have finished all the levels, replay them, with a higher level of difficulty. To do that, I moved the levels data outside the program, to a data file. In this FELINES.LVL file I could store as many levels as I wanted, and could load and reload it as many times as I wanted. This worked out fine, and will allow me to create a level editor at some point.
Also, I added a random factor to the wind in each level, to give a better replayability (is that a word? Or what?), and a wind speed indicator at the top left of the screen.
With this changes, and 6 playable levels that could be replayed until the mouse escapes, version 1.0 of “Furious Felines was ready for the public unveiling.
Interpreted BASIC, in a 25 year old computer, is not fast. That is a fact.
Trying to improve the animation speed and reduce flicker, I did something I have never tried before. A look-up table of sorts.
The idea is simple. Calculate all the points in the cat’s trajectory while it jumps, and store them in a matrix. Then, animate the jump reading the graphic’s position from that matrix instead of calculate it while drawing the animation.
But I found two not totally unexpected problems.
- The calculations took about 5 seconds. During that time, the game had an ugly pause in the action.
- I found out that most of the flicker is actually because of the time it takes for BASIC to draw the graphics in the screen. Having no delay between the command that deletes the cat’s old position, and the one that draws the new one did actually create a flicker that was in some aspects nastier than before.
So, back to the old code.
The good thing is that it was not hard to implement at all, and I’m sure I will find another chance to use it.
I’ve done a lot since my last post, but not as much as I should have.
First, I did make it “prettier” 🙂
I did change some of the game logic, and I have a scoring system.
Also, level creation should be pretty simple, it’s just a matter of creating them in a way that they are challenging, but not to much.
Now, I will make it fully playable with at least 5 levels. Once I reach that point, I will keep adding graphics and animations, fix some minor glitches, and clean up the code.
Most of what could be called the “game engine” is ready.
- Animate the cat that jumps from the top of the pile.
- Create new graphics for the cat while it is waiting to be launched, and while it is flying.
- Make up my mind about how score is going to be awarded.
- Create the levels.
- Make it pretty! 🙂 That is, ad some backgrounds, messages, and so on.