To Object or Not to Object
May 26, 2015
I object!
These words are often seen at weddings in movies, but I've never seen it in real life...
However, that's not what this post is about. I kept putting off posting this week because I hadn't done much and was hoping for something amazing to spring up, but unfortunately you get something less-than-amazing. What follows is pretty much a stream of thought regarding the use of object-oriented programming in the Maven engine.
In the effort to make code more efficient, I inevitably come to the crossroads of simplicity versus extensibility. Should I give the user (me in the next stages of development) more options to choose from with a longer form to fill out every time? Or should I assume the user will would rather have a smaller form with less options?
Second to this is the issue of memory management. Currently, I forsee Maven consuming a fair amount of memory during runtime. The more layers of objects introduced, the more memory the game will consume.
This battle almost makes me want to scream in frustration when I have gotten to the point of Action (e.g. swing sword), Motion (e.g. walk), and Status (e.g. poisoned) systems. I have decided that Statuses take priority and can stop Motions and/or Actions; also, a single character may be afflicted by multiple Statuses simultaneously. A single Action may occur per frame and may block Actions. A single Motion may occur each frame in addition to the Action. The idea is that the developer-user may create his/her own Actions, Motions, and Statuses; but how much freedom should they be allowed/forced?
On top of all this, JavaScript inheritance is outright confusing compared to C++.
In other news, you may not see me around for the rest of the summer. (Don't miss my blog posts too much!) If the LORD is willing, another team member may step up to blog in my stead for the summer.
In the effort to make code more efficient, I inevitably come to the crossroads of simplicity versus extensibility. Should I give the user (me in the next stages of development) more options to choose from with a longer form to fill out every time? Or should I assume the user will would rather have a smaller form with less options?
Second to this is the issue of memory management. Currently, I forsee Maven consuming a fair amount of memory during runtime. The more layers of objects introduced, the more memory the game will consume.
This battle almost makes me want to scream in frustration when I have gotten to the point of Action (e.g. swing sword), Motion (e.g. walk), and Status (e.g. poisoned) systems. I have decided that Statuses take priority and can stop Motions and/or Actions; also, a single character may be afflicted by multiple Statuses simultaneously. A single Action may occur per frame and may block Actions. A single Motion may occur each frame in addition to the Action. The idea is that the developer-user may create his/her own Actions, Motions, and Statuses; but how much freedom should they be allowed/forced?
On top of all this, JavaScript inheritance is outright confusing compared to C++.
In other news, you may not see me around for the rest of the summer. (Don't miss my blog posts too much!) If the LORD is willing, another team member may step up to blog in my stead for the summer.