It’s been a busy week with exams (Language Processors!), but some basic enemies have been added. They are randomly placed every 5 seconds at random positions by the Overmind (he’s the one throwing ‘rocks’ at your Core, we couldn’t call him Bob, right?) This is the change log since the last version:
Grid has evolved into a Singleton class so that other objects may easily get information about the current state of the game. Grid’s size, Cell status, in-game Items… That’s much faster than sending messages.
There’s a simple enemy generator called Overmind. Right now it just places enemies randomly at a fixed frequency. In a future it may decide the worst place to create an enemy, making the situation more complicated for the player. Mehehe…
A base Enemy class has been defined. Right now they just float above the Grid towards the Core. Their movement is not restricted by rows or columns.
They may collide with certain Items, damaging or destroying them if they are Destroyable. It won’t be good if they hit the Core, but not for now. In the video they destroy three Repeaters. Note that the Pulse does not affect them.
Enemies will have hit points, requiring a number of hits by Weapons or certain Items (Mines?) to be destroyed. But that’s for Alpha 4!
Once we implement basic weapons and destructible Enemies we will be able to test all this as a proper game. Will it make sense? It does in our heads… let’s hope its fun, at least, trying to prevent enemies from reaching the Core!
– A targeting reticle: as Beatfense will be played mainly on touch devices, it’s important to be able to seamlessly choose the Cell where you want to place an Item. So in a way similar to how Plants vs. Zombies does it, we show a cross-like reticle across the Grid. We may consider adding diagonals too…
– We have an abstract ‘Item’ object now. That is, something you are given (like Tetris pieces) and that you may place on a Cell of the Grid. For testing purposes, we have also created a random Repeater (Items that retransmit Pulse when activated) generator.
– We also decided to use a Singleton that handles and registers user interaction. This is specially useful to reduce messages between objects. Cells, for example, tell this User Interface object they are being clicked, so it stores their row and column. That way, cells will simply read this two values from the User Interface Singleton while the mouse is being pressed. If their own row or column coincides with those stored in the User Interface Singleton, they will turn blue, shaping the targeting reticle.
Better watch it! You’ll see the reticle at the beginning, in Cyan. The ‘Next Item’ is shown on the top of the screen. After a few Repeaters have been placed, the whole thing looks both chaotic and hypnotic! You may also notice that Repeaters can’t shoot twice during the same cycle. They have to wait for the next Pulse to be created, in order to avoid infinite loops.
We will reduce Repeater’s transmit directions to a predefined set. Choosing directions randomly increases gameplay and decision complexity: there are way too many combinations! Players must be able to learn the set of available Repeaters. That way they can create structures that require a certain Repeater, as we used to do in Tetris while waiting for the long piece.
We are also considering different layouts for the Grid: vertical? horizontal? We’ll see!
As we said in the last post, this is a little project to be developed by one person in a couple of months. Because of that, it can’t be a gigant game!
This project (and this devlog) aims to show the development of a game from its concept to its publication in the App Store. Like our previous three games, it will be developed in Unity3 + C#, focusing on iOs devices.
Let’s see the concept:
While everything is shown in that sketch in a nice handwritten Spanish, the concept is quite simple. It’s some kind of Tetris (place random pieces in a grid) mixed with Tower Defense (the player must create a defensive structure against incoming enemies), all within a nice musical setting (the grid behaves like a sequencer). We have to prevent enemies from reaching the Core, the bottom row of the Grid.
At this point we are still not sure about the name:
BeatfenSe – Beat, because of rythm, and Defense, because of Tower Defense.
BeatfenCe – Some kind of fence made of sound… quite poetic. It was the original name.
So we have a Grid of a given size, not decided yet; a certain Pulse that is transmited by grid Cells and a set of random appearing Items that will react to the pulse in different ways. The Pulse does not harm enemies, it simply activates items (shaping some kind of power grid). The player will place Items on the Grid as they become available (as in Tetris pieces, one by one)
At first sight, we have to begin by implementing a grid that behaves like Conway’s Game of Life (that is, a cellular automaton) with some differences. There’s this pulse that is transmited from cell to cell; when a cell receives an incoming pulse, two things may happen:
The Cell is empty, so it forwards the Pulse to neighbouring cells.
The Cell contains an Item (e.g. a Repeater), which absorbs the Pulse and reacts to it.
And this is exactly what we have done in Alpha Build 1. The grid is already working: cells update with a certain frequency and forward incoming pulses properly. When the pulse dies, a new one is created in the Core. Repeaters are shown as cubes with little floating spheres that indicate the pulse transmission direction. The scene is not interactive, yet.
One of our members, Aitor, is about to earn his Bachelor of Science Degree in Computer Engineering, for which an undergraduate thesis project is required. As I hold a PhD degree in Computer Science, I will be one his project tutors. And Medusa will publish a new game before Summer! Win-win(-win)!
The project will consist on creating a video game from scratch from an idea we had a few months ago. It’s complex enough to be interesting for an undergraduate thesis project (software engineering vs agile software development, modularity, user interface design, client-server programming for its own highscore tables…)
But it’s also a reasonably tractable project, as it will be developed by an one-man army. I’ll just guide and advise him a bit so the game is finished by April, published in May and the project properly defended by June-July.
Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies