I tend to not have a problem when it comes to understanding logic, or so I think, but occasionally this one problem shows up that proves to be quite bothersome. In most circumstances, I would just give up and find some way to avoid having to solve the problem altogether -- for those who don't know me, compromise is one of my favorite solutions when the going gets rough. However, sometimes I find myself looking forward to the end result and imagining what it could become, which can find me miraculously pushing myself forward, tossing more fruitless solutions at the problem and watching them all become further victims of what could arguably be my favorite key on the keyboard: Delete.
I may be in one of those "I'm too close to the problem" sort of moments, where I am too focused on the problem to the point where I am incapable of thinking outside of the box for a solution. Sleeping over a problem is usually a good choice for me, since there's not usually a rush, but I do ever so want to rush right now that I don't want to have to sleep over it. Besides, I slept over it last night, and all it produced was a figuratively new angle that ultimately led to taking a step backward to a literally new angle.
I am a little excited by all of this positive emotional overload for if this works, but having to create algorithms to imitate lighting effects... Manipulating individual pixels and all that is perhaps beyond the reaches of my usual capabilities. But it's the basis for this program I'm working on right now, and everything else will fall into place afterward. Gah, it's ever so frustrating, though.
Happy thoughts, Trevor.
Soon you could be done with it.
Patience till then, 'k?
***Update
Not even a half-hour after writing this and I made an awesome breakthrough that solved pretty close to the entire problem. Just some minor tweaks with it, but the main headache has been resolved. The main part that's left is to perform the same steps with diagonal movement, and... well, let's just say that results for viewers like you will be seen very soon (like, within the next week or two soon).
19 July 2009
10 July 2009
Autarky - Part II
The last I wrote, I mentioned the Real-Time Strategy genre, which might have created an inherent false perception of the overall idea; at least, from the stand-point of playing against an opponent with the intent to defeat said opponent through genocide. Now, before I continue working over the weekend on this, let me unveil a few important factors to this idea.
#1 - Economic simulator
Perhaps the most important tid-bit of information to point out is the specific genre I would define this game, which I have decided on the (at least temporarily) title of Autarky. The overall premise of the game will revolve around establishing one's own economy and attempting to stimulate it in order to attain profits. Now, the specific goals for victory will change depending on a number of different "scenarios" that can be at play, but the most notable of these scenarios will be to "attain X profits" or "attain Y population" with potential add-ons such as "the current economic status must at least be average."
#2 - Difficulty Settings
The other notable point of interest is how I intend to manage difficulty levels. Since the economy is such a difficult system, I imagine the game might seem overwhelming to newcomers until they are capable of managing little pieces of the game mechanics at a time. Rather than throwing the entire economic system at a player, the difficulty settings will allow for players to play through a scenario with more or less things to micro-manage.
Say the player decides to play on the Easy difficulty setting. In this setting, the player may only have to worry about creating new buildings and controlling what the individual citizens become in order to get jobs at those newly-created buildings. Such things as the controlling of taxes -- sales or otherwise -- wouldn't be editable by the player, but would be placed on an automatic control to be changed depending on the player's current economic state. As the player chooses more advanced difficulties, there will be more options that the player will be required to handle on his own and less that will be automatically controlled.
#3 - Your Own Opponent
Autarky stands for a self-sustaining economy, and in the beginning the player will have no choice but to be self-sustaining. The way the game works, the player's citizens and their needs constitute as a valid opposition, so the player will not have any other players as an opposing force. At least, this is how it will stand in the beginning.
#4 - Multi-Platform?
I've been seriously considering working this out in both XNA (what I am currently working it out on) and Processing. An XNA version would perhaps find its way on Xbox Live or Community Games, whereas a Processing version would find itself on Facebook. Certainly the Facebook version wouldn't be profitable (at least, from what I've read about Facebook development, which could essentially be wrong), but it would also be a little different. Mechanically similar, but visually not similar. Still something I'm just tossing around right now and am uncertain as to whether or not I'll step forward to work on. Being just me, the chances are a little slim of both.
#5 - Expansion-worthy?
As I have been coding, I have been keeping in mind flexibility for the future. I have been striving to make the code malleable enough to allow for expansions to become a possibility in the future. I have also thought up potential expansions that would revolve around an entire subsystem within the economic theme. Both expansions would revolve around having an opponent, adding this whole multiplayer complexity to the mix (and both are also unnamed. The following are just descriptive titles).
Multiplayer Economical Conquest - Ruin an opponents economy by buying out their buildings and expediting your citizens to temporarily work in their territory (nets you tax income that will not go to them). Just the basics, but a whole lot of other subtle ways to sabotage your opponent shall exist, too.
Multiplayer Military Conquest - Adds a military aspect to the multiplayer. From an economic standpoint, military is not very cost efficient and would take a lot of time for a player to set-up in order to work. Currently, I'm uncertain as to how this could work out, since it could make for ridiculously lengthy games, but...
"But" we'll have to see if I can keep my interest long enough in just the normal game before I put more considerable thought into expansions.
Until next week's update.
-Trevor
#1 - Economic simulator
Perhaps the most important tid-bit of information to point out is the specific genre I would define this game, which I have decided on the (at least temporarily) title of Autarky. The overall premise of the game will revolve around establishing one's own economy and attempting to stimulate it in order to attain profits. Now, the specific goals for victory will change depending on a number of different "scenarios" that can be at play, but the most notable of these scenarios will be to "attain X profits" or "attain Y population" with potential add-ons such as "the current economic status must at least be average."
#2 - Difficulty Settings
The other notable point of interest is how I intend to manage difficulty levels. Since the economy is such a difficult system, I imagine the game might seem overwhelming to newcomers until they are capable of managing little pieces of the game mechanics at a time. Rather than throwing the entire economic system at a player, the difficulty settings will allow for players to play through a scenario with more or less things to micro-manage.
Say the player decides to play on the Easy difficulty setting. In this setting, the player may only have to worry about creating new buildings and controlling what the individual citizens become in order to get jobs at those newly-created buildings. Such things as the controlling of taxes -- sales or otherwise -- wouldn't be editable by the player, but would be placed on an automatic control to be changed depending on the player's current economic state. As the player chooses more advanced difficulties, there will be more options that the player will be required to handle on his own and less that will be automatically controlled.
#3 - Your Own Opponent
Autarky stands for a self-sustaining economy, and in the beginning the player will have no choice but to be self-sustaining. The way the game works, the player's citizens and their needs constitute as a valid opposition, so the player will not have any other players as an opposing force. At least, this is how it will stand in the beginning.
#4 - Multi-Platform?
I've been seriously considering working this out in both XNA (what I am currently working it out on) and Processing. An XNA version would perhaps find its way on Xbox Live or Community Games, whereas a Processing version would find itself on Facebook. Certainly the Facebook version wouldn't be profitable (at least, from what I've read about Facebook development, which could essentially be wrong), but it would also be a little different. Mechanically similar, but visually not similar. Still something I'm just tossing around right now and am uncertain as to whether or not I'll step forward to work on. Being just me, the chances are a little slim of both.
#5 - Expansion-worthy?
As I have been coding, I have been keeping in mind flexibility for the future. I have been striving to make the code malleable enough to allow for expansions to become a possibility in the future. I have also thought up potential expansions that would revolve around an entire subsystem within the economic theme. Both expansions would revolve around having an opponent, adding this whole multiplayer complexity to the mix (and both are also unnamed. The following are just descriptive titles).
Multiplayer Economical Conquest - Ruin an opponents economy by buying out their buildings and expediting your citizens to temporarily work in their territory (nets you tax income that will not go to them). Just the basics, but a whole lot of other subtle ways to sabotage your opponent shall exist, too.
Multiplayer Military Conquest - Adds a military aspect to the multiplayer. From an economic standpoint, military is not very cost efficient and would take a lot of time for a player to set-up in order to work. Currently, I'm uncertain as to how this could work out, since it could make for ridiculously lengthy games, but...
"But" we'll have to see if I can keep my interest long enough in just the normal game before I put more considerable thought into expansions.
Until next week's update.
-Trevor
03 July 2009
Did someone say RTS? - Part I
Call me a liar, but I really hadn't been working on any programming projects around the time of my last update. However, I seem to have this whole oscillating thing going on -- my interest in writing and programming move forward as though one is a Sine wave and the other is a -Sine wave. Er, yeah -- trigonometry to prove a point... Hey, the image in my head seemed clearer than it sounded when put in words.
At the heart of my current (or rather "in planning") programming project comes one of the problems I see with the RTS genre: units being produced from buildings. No, I don't have a problem with requiring a building to exist in order for a unit to exist, but it is the physical action of creating a unit from the building requiring the unit to exist. In my words, that no doubt sounded drastically more complicated than it needed to be, so let's get to the basics of my idea. Just keep in mind that before you continue, you should toss the ideas lingering in your mind from those existing RTS games you are so familiar with.
In the beginning, let's say we have a House, Residential District, or some other sort of living-based area built (or even, say, a school). From the House we can generate our base unit: let's refer to him as the Citizen. The Citizen will be the only unit that is generateable via a building.
At this point, we might want to build some other form of building. So, we rally together some citizens and build something: let's say we build a Military Academy -- our basic military structure. From this, funds from the player are expended in order to pay the citizens who build the building.
So now we have ourselves a Military Academy. Now having unlocked the ability to train some form of military unit -- let's just go for the generic term Soldier for now -- let's go ahead and train ourselves one. Enter a Citizen into the Military Academy in order to train to become a Soldier.
Let's say we build other buildings, which allows further unit types to be trainable at the Military Academy. We also build some buildings which allow for the Citizen to become other non-military units. As a general rule, the Citizen must pay the player in order to train to become something else.
There are a couple other Citizen-Player scenarios which would come in play in order for both to attain profits necessary to advance. Rather than simply training at buildings, a Citizen also has the opportunity to work at buildings. The Citizen gets a paycheck from the building, and the player gets a tax of the Citizen's pay. The pay the Citizens attain from working is otherwise not taken from the player, but an invisible source -- presumably the company/corporation that owns the building. If no Citizens are currently assigned to work at a building, the building is still in business, allowing the player to gain a set minimum amount of profit over a period of time. And don't forget, from mentioned in the building-creation process above, that the Citizens assigned to build new buildings get paid directly from the player as well.
And... that about covers the basics. Trust me, I'll eventually post more, but I'd like to tweak around with the idea a bit and actually make some test runs with this and some of the other more advanced thoughts I have before posting more. In the mean time, I might actually get around to posting a snippet from my writing on here soon...
At the heart of my current (or rather "in planning") programming project comes one of the problems I see with the RTS genre: units being produced from buildings. No, I don't have a problem with requiring a building to exist in order for a unit to exist, but it is the physical action of creating a unit from the building requiring the unit to exist. In my words, that no doubt sounded drastically more complicated than it needed to be, so let's get to the basics of my idea. Just keep in mind that before you continue, you should toss the ideas lingering in your mind from those existing RTS games you are so familiar with.
In the beginning, let's say we have a House, Residential District, or some other sort of living-based area built (or even, say, a school). From the House we can generate our base unit: let's refer to him as the Citizen. The Citizen will be the only unit that is generateable via a building.
At this point, we might want to build some other form of building. So, we rally together some citizens and build something: let's say we build a Military Academy -- our basic military structure. From this, funds from the player are expended in order to pay the citizens who build the building.
So now we have ourselves a Military Academy. Now having unlocked the ability to train some form of military unit -- let's just go for the generic term Soldier for now -- let's go ahead and train ourselves one. Enter a Citizen into the Military Academy in order to train to become a Soldier.
Let's say we build other buildings, which allows further unit types to be trainable at the Military Academy. We also build some buildings which allow for the Citizen to become other non-military units. As a general rule, the Citizen must pay the player in order to train to become something else.
There are a couple other Citizen-Player scenarios which would come in play in order for both to attain profits necessary to advance. Rather than simply training at buildings, a Citizen also has the opportunity to work at buildings. The Citizen gets a paycheck from the building, and the player gets a tax of the Citizen's pay. The pay the Citizens attain from working is otherwise not taken from the player, but an invisible source -- presumably the company/corporation that owns the building. If no Citizens are currently assigned to work at a building, the building is still in business, allowing the player to gain a set minimum amount of profit over a period of time. And don't forget, from mentioned in the building-creation process above, that the Citizens assigned to build new buildings get paid directly from the player as well.
And... that about covers the basics. Trust me, I'll eventually post more, but I'd like to tweak around with the idea a bit and actually make some test runs with this and some of the other more advanced thoughts I have before posting more. In the mean time, I might actually get around to posting a snippet from my writing on here soon...
Subscribe to:
Posts (Atom)