Welcome to this humble tutorial. The ultimate goal of these chapters will be to create a fully working arcade game emulation coded entirely in Blitzmax. It’s not written as a BlitzBasic → BlitzMax tutorial. My aim is to give anyone the opportunity to get a good start in learning the fantastic BlitzMax. This is the start of a fairly ambitious series of tutorials on how to write 2D games using BlitzMax. The first part is a Getting Started part where I’ll be introducing.
|Published (Last):||5 January 2010|
|PDF File Size:||2.6 Mb|
|ePub File Size:||12.91 Mb|
|Price:||Free* [*Free Regsitration Required]|
I was asked to do a little tutorial for BlitzMax.
A suggested game was a simple top down shooter where the player controls a rotating turret in the center of the screen and has to shoot different enemies that approach him from all sides. The game gets more and more difficult by raising the speed of the enemies, introducing different enemies that take more hits and uttorial on. This sounded doable to me and it seemed to offer many possibilities to introduce some OO and other nice features of BlitzMax so I decided to give it a go.
The tutorial is a work in progress right now and only contains thoughts and reminders about how to proceed. It will be properly written over the next few weeks or months. Those will help you organize and simplify your code a lot compared to the “old” procedural versions of BlitzBasic and other Basics.
It might happen during this tutorial that I mix the usage of type and class as blitzmaax are identical and class is the more often used phrase to me. What is a Type now? It’s nothing more but a template for new objects. Every object you create with that type has all the fields as the type describes.
A Type in BlitzMax can also have methods which can be called for each object of that type. There are some more features of types which I’ll explain later on in the tutorial. Oh, and before I forget: Your first command in any BlitzMax game you code should be SuperStrict.
But I will not explain how to create a project or create a new file as it’s all pretty self explaining.
If you don’t manage to figure that out on blitmzax own you shouldn’t yet consider coding your own games. The idea is to create a simple version of a top down shooter which we extend later on.
Top down shooter tutorial with BlitzMax
So we use a simple single screen game without any scrolling maps or tiled background or such things. The player controls a turret or a base in the center of the screen.
The turret rotates following the mouse pointer and clicking the left mouse button will fire a bullet in the turret’s direction. Enemies will return in random intervals from the screen boundaries and move directly towards the player’s turret. They do not fire and might require several hits before they die or explode. As soon as an enemy touches the turret the game ends.
The enemies attack in phases. After all enemies of a phase have been destroyed the next phase starts with more enemies, harder enemies, faster enemies and so on. Later on we will extend the game and replace the turret with a moving player sprite, add keyboard control for movement, better room graphics, add several rooms, different weapons and what else I can come up with while coding this tutorial: Unfortunately game developer’s life isn’t that easy. Because different computers have different speeds older ones are generally slower than the newest high end quad core machines this main loop would run at different speeds too.
Your game would become unplayable on faster machines. There are several approaches to solve this problem. One is called delta timing. A game loop using delta timing would look similar to this one: But it has two disadvantages: This way you’ll avoid too many too complicated calculations and nearly no game player would realize a difference if the physics engines were called faster.
So people came up with another method of game loop: What you do here is calling the update methods with a given fixed rate all the time, for example every 20 milliseconds.
Of course it could happen that your game logic needs more time or the Garbage collector interrupts a bit or your game is synchronizing with the vertical monitor sync signal to avoid flickering and you don’t exactly match the 20 milliseconds.
So the next call to your update would be a few milliseconds too late. You would still call the update for all pending amounts blotzmax 20 milliseconds and the remainder the tweening value would be passed as input to all drawing methods. The drawing methods would then interpolate between last position and current position of all moving game objects and the distance travelled is dependent on the tweening value.
So instead of having a different value each call in the update routine as in the delta timing approach we now have a different value in the drawing routines. Visually the output is pretty much identical but the advantage of the fixed rate logic approach is indeed what the name says: A pseudo code game loop using fixed rate logic would look like this: As the drawing functions do the interpolation all your moving game elements need to have two positions: The new position on screen is calculated in the update phase and in the drawing phase your code will have to tutoriao between those two positions based on the size of the tween value.
Each drawing or rendering phase will move your game elements closer to their new position that was calculated glitzmax the update phase. Finally, when the new position is reached time is up for a new update phase and we’ll start all over again. There is a nice long thread in the BlitzMax forum here and a really good explanation of fixed rate logic in games can be found on Gaffer’s Blog.
For this tutorial we will use the fixed rate logic plus tweening approach – mainly just because I want to give it a try: I tutogial to mention that some of the code is adopted and modified or simplified from Chroma’s public domain BlitzMax framework which you can find on Google code pages here. It seems to be no longer maintained but it gave me a good starting point. Ok, create an empty directory for your project on your hard disk and fire up your preferred BlitzMax IDE.
First we’ll start bljtzmax the main tutoeial code base. You can just copy and paste it into a file named ComeGetMe. So what does that code do? First we switch on “SuperStrict” as I already recommended. We then define constants for the screen size and the update blihzmax which is the fixed frame rutorial. So we plan to call the blitzax functions times a second which means every 10 milliseconds.
It allows us to smooth the tweening value a bit to avoid spikes that may arise while other background processes on your PC start or terminate while playing the game.
So the game play will appear even more smooth 8- The number 20 in our example just tells the type to store the last 20 values and use them for smoothing. We open the graphics mode with given width and height and stay in windowed mode the 0 at the end of the Graphics command.
BlitzMax IDE(BASIC) Vs. C , which is better for beginners? – Forum –
This object will help us to keep track of all this fixed rate logic and the tweening value and all that. Finally we start our main loop which we’ll only leave if the player presses the Escape key or clicks on the upper right close button of our game window.
The loop itself is pretty simple: Then we ask the gameTime object how many milliseconds blutzmax passed since bliyzmax last call to GetDelta. The inner while loop helps us to call all outstanding updates. LogicFPS which is exactly our fixed time rate the update frequency, here We then need to do all drawing but we need to pass the tween value into the draw methods as explained in the previous paragraph.
The main loop finishes with a call to Flip 1 which switches the two drawing buffers of BlitzMax synchronized with the screen’s next vertical sync vsync to avoid flickering.
If the player presses Escape or clicks into the close box of our window we leave the main loop, call EndGraphics to switch off BlitzMax’ graphics mode and terminate the game.
I already added two empty functions DoGameUpdate fixedRate: Float and DoGameRender tween: Float which will contain all required calls to update and render the game objects. So that’s the first tutorlal of the main loop. Save the file as ComeGetMe. It’s good coding practise to always start your Types with a T and create a new source code file for each type. Shall we have a look at it?
Int ‘ do we use delta spike suppression? Float ‘ this array contains the delta values to smooth Field dssLenArray: Int ‘ how big is the array of delta values.
If the code looks just too complicated and you don’t want to delve into it that’s fine. It will work and you don’t have to understand the source code to get a running game. But if you want to learn how your game system ticks and also want to know about some more BlitzMax features you should read this paragraph.
Every type declaration starts with the keyword Type and the type’s name and ends with the keyword End Type. All code between those keywords belongs to the type. We start with some field declarations. You can imagine fields as properties of objects. For example every car has a color and a number of doors. So color and nrOfDoors would be fields of a type TCar.
As I already mentioned every type is mainly a template for objects. So if you create an object of type TXYZ it will have all the fields that are declared in the type.
And if you have two or more objects of type TXYZ all of those objects have their unique values inside the fields, just like you can have a red car with three doors and a blue car with five doors.
The delta field should be self explaining. All fields starting with dss are used for smoothing the delta values. Finally we store the accumulator and tween values as Floats. Then we meet something new: I already told you that methods can be called for each instance of a type.
But what if you don’t have an instance yet?