Jump to content
  • Advertisement
Sign in to follow this  
  • entries
    2
  • comments
    4
  • views
    3226

About this blog

Development of a simple turn-based game + engine

Entries in this blog

 

Update 1 - Building Structures

As I mentioned previously, the game engine I am using is a custom one built completely from scratch. This left me with a bit of a problem in implementing my GUI as I realized the Android code was probably not portable. I eventually settled on the idea of creating a single Display class which could pass messages to and from the Game itself, meaning that only the Display would need to be re-written when I try porting the thing to PC later. All update calls are sent to Display, which calls the Android UI, while all return messages are sent using classes and formats that the engine understands.

After I got the GUI working, I decided to focus on building structures as opposed to a crafting system because I'm still unsure of how I am going to display the players inventory to them. And plus, building little pretend villages is so much more fun than crafting a bunch of random junk, that is useless given that units still con't actually hold equipment.

I feel that the implementation was a bit more convoluted than it should be: All of the players input is channeled through a script called the CursorScript, when the player wishes to build a structure, they hit a button on the UI which is passed to the CursorScript. The CursorScript then calls display passing it a list of structures the player can build. On the Android system, a dialog appears with the name of the structure (material costs and descriptions are in the manual, there are only about 6 structures the player can build). When the player makes a choice, the Display class then calls the game and sends it an Evaluate command, which the is passed to the CursorScript, which then calls the scene to create an entity and finally an entity loader to load the appropriate structure. But it works and I can't see any glaring theoretical flaws (yet).

I'll probably end up passing the script directly to Display, there isn't really any reason for the Game to worry about this part, but that might cause a concurrency issue, since the Display must run on the UI thread while the game runs on its own thread.

Now that I a construction system working, I need to add resource costs and resource selection, and then ensure that certain structures are built only from certain resources. Then probably an inventory system, then item crafting or unit creation.

Zeyro

Zeyro

 

Project Desciption

Hello,
I want to start this Dev Journal off with a description of the game I aim to create. First a little history about the development of the idea, then an overview of the story, then game itself, a list of mechanics and finally a note about the game engine.

The Idea:
I wanted to create a fairly complex strategy game for mobile devices, I wanted to use a turn-based model as opposed to real-time because it is fairly difficult to take real-time game seriously on a mobile device, in my opinion and in my experience the user needs to spend a decent amount of thought ensuring that their fingers are on the correct controls, as well as playing the game itself. And even further than that, the game needs to be able to start and stop on a dime. All of these things point to a turn-based game being ideal for a mobile platform.
I also wanted something similar to starcraft and warcraft, which are what initially got me into games and game development. Specifically, I want aspects of unit building and base building, so I decided that the player will build structures which will allow the creation of items and units.
After that, I ran into an Android game called Ramble Planet (which you should really have a look at, it is really well done), that was so unique that it made me want to throw a twist or two into this project. I eventually settled on a resource-gathering twist. Instead of controlling resource nodes like in most 4X/RTS games, the player must kill enemy units to gain the resources they need to build units and structures and craft items.

The Story:
The back-story of the game is that the player is given command of a clan of Goblins that is caught between the opposing fronts of a Human and Orc war. The humans and orcs have no outward aggression to the Goblins, but the troops from both sides require food, which is threatening the Goblin food supply, and the orcs have no problem eating the Goblins, should they get hungry enough, So, the Goblin clan is forced to flee their homeland in search of a safe haven to call home.

The Game:
The game itself is played as a series of 9-ish maps in a campaign format. Each map is a grid, units and structures take up one space on this grid. The players objective is to move all of their units from the starting zone of the map to the ending zone. The player controls two types of Goblin unit, civilian and military. Civilian units use large amounts of food when they move, but military units use a little food every turn. Food can be found on each level and only a certain percentage (50% maybe) can be carried from one level to the next. The idea is that the player must carefully think about how many military units they need/will be able to sustain. The food mechanic will hopefully create a need to move forward as well a way to hold the player back. Food can be found by killing neutral units on the map (such as deer or wolves), or by raiding Human/Orc camps or neutral camps. All of these actions anger the Humans/Orcs to varying degrees (killing deer less than raiding outposts). The Human and Orc units are also far stronger than the Goblin units as well as better equipped. This means that while killing Human and Orcs units is a good way to get equipment, it is also very dangerous and will cause the enemies to hunt the player down faster. The Humans and Orcs also have their own bases on the map, but they are mostly cosmetic and offer the the AI a place to put new units, as well as reinforce the power of the two races. (These structures cannot be destroyed by player units.)

Core Mechanics: (From the GDD, with some descriptions)
-Combat
Player can kill units to help them gather resources.
-Crafting
Player crafts new equipment with a somewhat open-ended system, encouraging creativity and experimentation.
-Equipment
Player manages unit equipment to adapt to the situation or to improve unit stats.
-Build Units/Structures
Player is allowed to create structures that allow the crafting of new items/equipment, as well as new units.
-Resource Management
Player must manage crafting materials and food. They must ensure their units do not starve and craft better
equipment as time moves on.
-Base Defence
Players base/civilian units are vulnerable and must be protected.

The Game Engine:
The game engine is a custom one that I created from scratch in Java. The renderer it uses is also my own and only works on the Android platform. However, I have tried (and hopefully succeeded) in keeping the rendering and UI completely separate from the game itself. I plan to attempt to port the game to PC later just as an exercise (I've never tried to port anything before). The engine uses the Entity-Component architecture, with Entities being their own objects instead of ID's. (Only because I had never heard of the latter system until after I started making the thing). I don't claim that it is a good engine, only that it runs at 30 fps and has minimal memory leaks. (Not true leaks, but still detrimental after long periods of time).

This project was started a while ago,so more updates later this week about what part I'm actually working on. Probably the crafting system.

Zeyro

Zeyro

Sign in to follow this  
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!