Necromantion Workings : The Engine (1)

-

The Main Interface


The main question when starting a game is how to distribute the functionality, as otherwise the code can go really messy really fast. My solution was as follows:

The whole game is decomposed into several Engines. However, they are not arranged in quite the way one would expect. Each Engine is primarily concerned with a specific part of the UI screen's management. There are mainly three classes that implement this interface : 
  1. GameEngine
  2. HUDEngine
  3. MessageEngine
I will brief about what each of them does here, but will write separate articles for each. Now, to begin with, what is the Engine class all about? Well, it defines the following properties
  • offsetX
  • offsetY
  • length
  • breadth
Now, I should mention here only that this is a grid based game. So, all these values basically store the grid number. When drawing on the actual screen, the objects are magnified by a constant factor which I will mention later.

Now, these four variables allow us to know exactly where each Engine should render itself. Each of them are only aware of the part of the screen they have got. Suffice to say, it helps in the rendering process.

To elaborate on what the subclasses actually do,
  • GameEngine : This is by far the most important component as it controls the entire game mechanics. It is responible for both the updation and rendering of the game environment.
  • HUDEngine : This is responible for showing the stats of the player. The Heads Up Display part.
  • MessageEngine : This is resposible for printing out any messages to the user, which are related to the gameplay.
This is just a really brief description. Insignificant. And as it is pretty apparent, the first is the most important by far. And it is. The thing is, I divided it into these engines to split up the screen and help in the rendering.


















Comments

Post a Comment

Popular posts from this blog

Small-to-Large

-
The Vanilla Method Let's take the given problem: We have some sets as U = {S1,S2,S3....Sn} where U is the "container" set. Initially each set contains a single element. After each operation each set will contain some numbers. We define the cost of a set as the number of unique elements in the set. For each query, we merge two unmerged set and then report the sum of cost of all the sets.  The most brute force approach is for each query, add all numbers in one of the sets and put them in the other set. This will take approximately O(nlogn) time per merge operation and since there can be about O(N) mergings (because after atmost N mergings there will be only 1 set left) this will take time proportional to O(n^2logn) time. For the report, part, we just return the sum of the sizes of the set. This part is O(1) as we only have to check the size of the new merged set as the sizes of the other sets haven't changed. This is obviously a poor algorithm for a seem
Read more

Segment Tree Beats - An introduction

-
Segment Tree Beats  Disclaimer : This post is based on a recent post made by jiry_2 on codeforces. Before I begin, a clear understanding of segment tree and lazy propagation is required.  If you don't know those, I would recommend you to go search it up online and read it thoroughly, before coming back. With that out of the way, here goes... Hey wait wait wait. Hold on. Just to clarify, now that you have read it, in case you are confused with what I call terminal nodes in a segment tree update/query, it's basically the node that is completely inside the update range, the one where we generally end our search in a segment tree. I say generally.. well.. you will see :). Anyway without further ado...  A simple problem So the first problem I want to address, and it is fairly easy, is supporting two operations on a range: Range minimize (for each i in range, make it min(i, update_value) )  point query Solution : This is just a variant of the normal lazy
Read more

Getting prepared for RMO

-
Regional Mathematics Olympiad The Regional Mathematics Olympiad (RMO) is the second stage in the selection for the selection of the Indian team to the IMO, the first being the pre-RMO. It is one of the tougher olympiads conducted across India, wherein only about 300 students are selected to sit for the Indian National Mathematics Olympiad(INMO). The main thing that makes RMO tough, at least for the common students, is twofolds -- firstly, the syllebus is quite a bit different than the normal class X or XI curriculum that is followed in schools, especially in areas like combinatorics and number theory, the latter being a topic that is scarcely touched upon. Secondly, in topics that are known to us, like geometry, the level of questions, even if they don't require advanced theorems and results, they need a level of creativity that cannot be mastered overnight. From hereon I will say what I did to clear it last year.. when I was studying in class IX. Firstly, I focused heavil
Read more