The purpose of inheritance is to reuse code
The purpose of inheritance is to reuse DATA. While polymorphism is a feature of many OOP languages that use inheritance, it’s not exclusive to inheritance or OOP. Function pointers could be used for polymorphism and many other tasks that aren’t tied to objects.
The real code reuse comes from functions, where I can run the same code in multiple places. If the function is pure, I can also be certain I’m not modifying any global state when I call it.
Yeah, you can achieve something analogous to encapsulation by the use of “static” in C
It’s not “analogous” to encapsulation, it IS encapsulation. It’s restricting the scope of your data, which makes the program easier to understand by breaking it down. Even a block {} is a form of encapsulation.
the purpose of classes is to model software in the same way that we conceive our phenomenical experience which consists of objects that have properties that determine their behavior.
But minigames aren’t real world objects. They have a lot of data that has nothing to do with the real world, and everything to do with the hardware. So it doesn’t make anything easier to understand, all the same code needs to be there in some way or another. You end up with classes that are nothing like the real world.
The purpose of inheritance is to reuse code and, by polymorphism, to allow for scalability by means of generic programming (among many other things). The fact that there only needs to be one instance of a single class doesn’t nullify those advantages.
Inheritance doesn’t automatically make scaleable software, abstraction does. But abstraction is not exclusive to OOP or inheritance. A function is a form of abstraction.
Globals allow unrestricted modification of the program’s state, while classes’ attributes restricts those modifications to parts of the program
Global state can be a problem, but at the same time, all games need it. It’s crazy to work in languages that forbid global state. But if we really wanted to avoid accessing it directly, we could pass parameters. Maybe we just pass it to a function then as a const parameter?
That way, the programmer gets a list of all the vars they need,
and they cannot modify it, therefore not tampering with any global state:
void step( const unsigned time );
In that way, it’s not global and its scoped in the function.
Since there is only one minigame active at any time, there needs to exists only the singleton instance of that minigame class in work RAM, therefore only one time variable. When it ends, the instance is deleted and the instance of the new minigame class is created..
If we are trying to reuse memory space for game structs, why not use a union? It’s a language feature instead of a macro.
In this way, the “primary game” doesn’t need to exist, since it would just be logic shared by all minigames, achieving your goal of avoiding the need to reimplement on each one the same functionality.
If we were to use inheritance from the base game, each minigame would get unnecessary copies of the main game state. Only one minigame will ever run at a time, so the copies of main game state don’t need to be a part of the minigame at all. They can exist in one place independent of the minigames that don’t need to access it.
The purpose of a classes and inheritance is to create a template that you can create instances of. However, only one instance of a game will ever exist, so why make it a class?
If we are trying to encapsulate, we can encapsulate at the file level. If you make a variable STATIC inside a .c file, its the same as making a variable PRIVATE inside of a class: it can’t be accessed anywhere else, not even with EXTERN.
“Task Panic” is a pretty good name because it describes what you’ll be doing in the game. Though we shouldn’t add “3D” after it because some games might be 2D.
I’m leaning towards the “dual D-pad” controls. Its a unique feature of the Virtual Boy and we should take advantage of that.
We shouldn’t mirror the controls because I want START to be able to pause the game.
Making it original is a great idea! Though, not sure what to call it. VBWare?
A repository like github would certainly aid in the open development process, I like it.
The VUEngine would be a useful tool in microgame development, especially with the new release.
What is the purpose of using inheritance? My intent for the microgame struct is to give the primary game access to each subgame’s functions. The data for each microgame can just be global and static inside its own file:
—-Example Microgame file:
#include “common.h”
static int exampleData, moreExampleData;
void init(void){
exampleData=0;
/*Called once at start of game*/
}
void update(void){
exampleData++;
/*Game logic*/
}
void draw(void){
…
}
/*Fill out function pointers here, the only part of the file that is given to the primary game.*/
const struct MICROGAME_INFO example{ init, update, draw };
—-
If we do it this way, a microgame creator can just write their game all in one file, without needing to inherit from anything. They can then include anything they want, such as the libgccvb or the vuengine. Of course some basic functionality can be given in common.h so that devs aren’t doing the same initialization in every file.