Hello everyone!
There are some news about The Gate!
I hope you like long posts because this one is pretty huge 🙂
First of all thank you all for your support! I am extremely grateful for your support in this pretty big project.
If you can, help me find more supporters, maybe by sharing this post!
Ok, now let’s talk about main currently main project: “The Gate”.
Frames used as portraits during the dialogues with this misterious lady.
DEMO TIME APPROACHING?
Lately I’m working really hard on The Gate because I decided to share a demo that covers about 7-8% of the game, I want people to see with their own eyes what I’ve pulled out of the AMOS magic hat, the level of complexity I’ve reached and the efforts I’m putting into it to bring to the Amiga community a fresh and original game.
As soon as I’m done with the next 3 rooms, I’ll pack a demo for you to play!
I have to be honest: I didn’t think AMOS was capable of that much, just consider that the main source is about 402Kb (402,000 characters!), but that’s not all because almost the entire game is described using external text files.
At this time the game code is over 12000 lines! The lines you are seeing is this shot are all commented out because I use them to quickly test if things are working as expected, to do this I simply uncomment what I need to test.
So here is the plan:
- Finish the next 3 rooms
- Finish the title screen
- Add the code to handle the demo version
- Find a way to abfuscate a bit the plain text files I used to define the game
The above last point, is because the core program turned to be an engine, fed by the mentioned text files.
The game engine along with the source code will be public once the game will be released in its final form, but I don’t want that my game is hacked just before I release the game!
CODE PLEASE. HEAD DOWN AND CODE!
Now let’s talk about what I did in the latest days, because I fixed some nasty bugs and added new features which I felt the need for, while working on some maps.
ENEMIES OVERHAUL
The image shows the use of sprite sheets (continue the reading to know more about it), it’s a test enemy I’m using during the development but is so nice that I will put it into the game 🙂
I have worked a lot on the enemy’s data structure, their brain command-set and their bullet system and here is what I did.
There are enemies that are displayed 100% opaque while some are displayed translucent blitting the graphics only on selected bitmaps.
In the image you can see the enemy of the previous image displayed using the translucent effect.
Before my changes this was hardcoded, enemies were always translucent, but I needed an enemy visible 100% opaque so I started to modify and expand the enemy data structure, and the path to the enemies overhoul started!
- Before my changes the engine was able to display several enemies on a room, but all of the same type. Now I can display several enemies using several enemy types.
For the curious folks around, I implemented a dynamic enemy frames loading routine: this means that during the room loading the engine will load all the needed enemy frames while it builds the enemy data structure, using sprite sheets and grabbing the needed frames on the fly.
This brought me another big enhancement: enemy animations now can have different number of frames.
For example: enemy Alpha can have 4 frames for the idle animation while enemy Beta just 2.
Using sprite sheets also lead me to get rid of the AMOS object editor which is good, but not optimal for the road I took. - The enemy brains are scripts with a set of commands that allow them to react to certain events like being attacked, sensing the player proximity, or moving randomly.
There are commands that allow to jump to script lines to make loops and control the script flow.
This is how an enemy brain script looks like: MOV=Move, WAI=Wait, SCN=Scan, JID=Jump If Detected, MVR=Move random, and so on…
—The problem was that the jump commands were hard to calculate because when a script was loaded the comment lines were removed from the script changing the jump reference point (which is the line number, starting from 0).
Now the comments are transformed into a NOP command that is interpreted but it does nothing, it’s just a place holder for the comment lines and to keep the jump reference points intact.Forgive my low capacity to express myself in English, here is an example of an enemy that moves around (in square brackets there is the line number):
[00] # Example brain for a moving enemy
[01] MVR 100,0,0
[02] # Wait some time
[03] WAI 10
[04] # Restart the loop jumping to line 1
[05] JMP 1When loaded into the game (before the changes), the comments were skipped and the above script was simplified like this:
[00] MVR 100,0,0
[01] WAI 10
[02] JMP 1 <– here is the problem! Line 1 is changed!So I changed the script loader to store the script it this way:
[00] NOP
[01] MVR 100,0,0
[02] NOP
[03] WAI 10
[04] NOP
[05] JMP 1 <– problem solved! 😀I hope you don’t laugh at my English, I laugh at it by myself, but the important thing is that I gave you the idea 😀
- As you may have read above, there are brain commands to move an enemy randomly, but I realized that this could lead to unpredictable positions so I added a brain command called LIM that can be used to limit the area of action of a single enemy.
The rectangular area defined with LIM is stored in the enemy data structure and handled by all the commands that moves the enemy.
This limits can be specified also in the map enemies definition, you can see it in the following image:
You can see that in the room there will be 1 enemy that will use the ‘robo-shock.txt’ template, the enemy is active and walls can block his movements. Below there is the initial position and the limiting area: the enemy cannot go outside this rectangle. - The initial idea was to have only flying enemies that floats around, but recently I changed my mind and I needed to move some enemies only horizontally or vertically.
I decided to expand the brain move commands to support an additional parameter to specify the type of movement (free, horizontal or vertical). - Another last minute change was the blitting of enemies: as I said some lines above, my initial idea was to have only semi-transparent enemies and I coded the effect just using the Set Bob command to blit the enemy’s graphics anly on selected bitplanes… but then I also wanted full opaque enemies 🙂
I expanded the enemy data structure to have this information for every enemy, so it’s not hardcoded anymore.
Enemy bullets now uses the same blit settings as their parents (because they were hardcoded too).
The above image represent an enemy template: here you can see all the enemy attributes, statuses, position, size, health, damage type he can take, blitting mode (bitmap), area of action limits, frames, damage it can deal, speed, bullet speed and finally the brain script to use. - Some enemies are able to shot bullets to the player (they are able to aim!), but I forgot the add the ability to set the bullet’s speed for each enemy.
I added a new property to the enemy definition called bulletSpeed (see the above image).
To achieve precise speed values, but still using integers which are faster, I decided to provide these values multiplied by 10, when the bullet is fired, after having calculated the destination position, the computed speed is divided by 10 to have the ability to create extremely slow bullets.
When you setup movement using AMAL you have to pass in how many steps you want to perform the movement, each step is executed during the vertical blank, so fewer steps mean faster movements, higher steps mean slower movements. - Another bug related with the bullet was pretty hard to find and what I’m going to say may be useful to other AMOS coders too.
With my current settings, in a given room, there can be a maximum of 7 bullets on the screen, each bullet uses a progressive bob number, looping from the lowest to the highest.
I found that after the first loop of 7 fired bullets, the second round of 7 was firing invisible bullets, the third visible bullets, and so on.
That was really strange behavior, an took me an entire morning to figure it out.The problem was with Bob Off <num> and my display update implementation.
To fix this I was forced to turn off the bullet bob twice like this:
The need to turn off the bob before its reuse is because Set Bob does not work with an already displayed bob.
- Enemies are driven by a generic AMAL program that listen for command sent from the main source using the internal registers, they are built using placeholders that I replace at runtime.
To let you understand what I mean, there is a piece of code in the AMAL program like this:
At runtime I replace all place holders surrounded by curly brackets, in the above code fragment for example, during the enemy creation, the {MOVE_RIGHT} string is replaced with the proper move-to-right animation (Using the AMAL Anim command).During my tests I discovered that some AMAL programs was throwing false errors, like labels already defined and other strange things, of course they was all false errors.
After a very long debug session I found that AMAL programs stored in strings which are longer than 1068 characters can cause these problems, so I fixed it optimizing the AMAL program by reducing its length.
I may investigate further about this problem because it is pretty limiting for very complex programs.
THAT’S NOT ENOUGH MAN, YOU HAVE TO CODE!
I’ve fixed some other problems during these burning days!
- The game provide the player with a document browser accessible from the game menu, where the player can open any document he gathers during the adventure: there was a bug that was opening everytime the first document available.
This was easy: I mistyped a variable name 🙂 shame on me!
A screenshot of the game menu with the document browser activated.
- I’ve found a bug in the [ONFURN…] script command.
This command allow the script (in dialogues & terminals) to jump to a label if the furniture/terminal state is true: LOCKED & UNLOCKED states was not detected correctly. - When there was an event lock tied with a door, the event was triggered automatically when the player entered the room from that door but this was wrong.
Now the player enters a room normally, with the door used to enter being opened, but only when he tries to exit, the event lock is triggered (if defined of course). - There was a little display bug with keys represented by four digits: only 3 digits where displayed.
It was only a display bug, internally it was handled correctly. - At every contact between player & enemy a sound effect was played, now it is played only if the enemy can do damage per contact.
CODER, ARE YOU STILL CODING?
Yes, I’m still coding because there are some stuff I need to implement:
- I have expand the enemy data structure again to play sounds, at least for the 2 attack types.
- I have to implement a dynamic samples loader, something similar to what I have done with the enemy animation frames.
- I really really like to use a channel for ambience sounds and to play themed music during the terminal sessions, dialogues and menu browsing.
- Since there are a tons of terms and names involvend in the story, I was thinking to add a glossary to the game menu that is populated with new entries during the adventure.
To conclude this very big update, here are some stats about my development folder:
That’s it! I hope I haven’t bored you with all these details!
… and dont’t forget to help me to find new supporters, I need your help to finish this game (…and to pay the bills) and I’m pretty serious about delivering something good!
