Post #12 TETRIS in ABAQUS... or Writer's Blocks
- guyrushton9
- Dec 16
- 4 min read
Recreating a classic game using python scripting in ABAQUS.
Once again I am late with my blog post but this is just in time for a Xmas so that’s OK. I decided to do something silly and make a game in ABAQUS, because why not? After quite a bit of head scratching over what I thought would be a nice simple demonstration of some scripting techniques, I have produced a full working version of the classic game Tetris.
Why Tetris? Well, I am old school. Also, it is simple and does not require a lot of fancy graphics, which ABAQUS emphatically cannot do. My initial thought was Pong, then space invaders, but Tetris seemed easy... which is why my blog post is late!
Since making this took three blog posts worth of time I am going to stretch the content to multiple posts:
Game Design – what the project has to do to be successful.
The User Interface – a plugin that provides controls and a game loop.
Visual Game Elements – creating the playing area, the shapes and the game announcements.
Game Mechanics – controlling the piece movements, identifying the contacts and scoring.
As always, the full source code for this blog is available to download for free via the button above, simply register as a site member.
Game Design
For those who are old enough to have forgotten, or too young to remember, Tetris was a dead simple game: the aim was to stack blocks of different shapes into complete rows that occupy the whole width of the playing area, at which point they were deleted and you scored points.
The user can move the blocks from side to side, rotate them and advance them down the track. Placing a single block to complete more than one row earned more points than completing rows individually. The blocks advance down the playing space at an increasing speed over time, they cannot escape sideways out of the playing area and as soon as they come into contact with another block they stick and a new block is created at the top. If the stack of blocks reaches the top of the playing area the game is over.
Bearing this description in mind the game must have the following elements:
Game data initialisation – variables are required to hold game elements such as the current score, block position, block shape and the game status, i.e. running or complete. This information must remain at all times and be available to both the kernel and the GUI.
Playing area initialisation – a suitable playing area has to be generated. In this case because of the screen shape the blocks will move from left to right rather than falling vertically. The track is actually realised as a grid of 30x9 units. All the normal screen annotations must be removed and game features, such as the score, displayed.
Block creation – a set of different shapes has to be created. In the original game they were made up of separate square bricks moving together. This is copied, not only for the aesthetics but also because it makes identifying completed rows and row deletion much easier. Each shape is made of up to four unit cubes.
Automatic block advancement – a game loop is needed that will advance the current block down the track at regular time intervals. This is easy to do in a normal program but posed some problems in ABAQUS.
User controlled block location – the user has to be able to move the blocks, up and down and rotate them in both directions. Additionally, they should be able to advance the block down the track to contact. The controls need to be smooth, respond immediately and yet also fit inside the game loop.
Position limiting – the location of the block needs to be controlled so that what ever its orientation it cannot be pushed outside of the track.
Contact identification – contact between the current blocks and those already placed and between blocks and the play area has to be understood. This is needed both to prevent the current shape moving sideways due to existing blocks and to identify when a contact that prevents it advancing further down the track has been made.
Scoring – the current score should be displayed. When the current block can advance no more then an assessment must be made of whether any rows have been completed. If a row has been completed then it must be deleted and the score incremented. If more than one row is completed at the same pass then then a bonus score is added. The blocks that are in incomplete rows need to be moved down the track to fill in the spaces left by the deleted rows.
Game exit – when the stack of blocks reaches the top of the track, or the user presses the exit button, a game over sign should display and then a list of high scores. If the current score is high enough to join the leaderboard the user should be prompted for a name.
Game cleanup – remove the evidence that the game existed, you are supposed to be using ABAQUS for work!
The scene is set. The next three posts will detail how the game was created and how the features of scripting within ABAQUS both helped and hindered.
Next up… creating the plugin with the user interface and the game loop.
Comments