infinite_suns

Il've been thinking some more about implementing the system I mentioned previously, and it's pretty obvious that, unless I want to get into weird scripting stuff, some core bits need to be hard-coded by ID number. The game needs to recognize what an entry is, in a general way at least, before it can pass the into to a specialized module that can actually interpret the data that the entry contains.

So. I've been coming up with a scheme for numbering these things. The lowest few hundred entries will be reserved for 'sacred numbers' -- ones that the program needs to have be what they are. Changing these around, removing them, etc, will require hunting through code to change the references and all the bullshit screwups that that entails.

The Sacred Numbers will designate broad catagories and a few very specific things -- Universe, Planet, Colony, Location, Ship, Minefield, Weapon, Engine, and Orders are a few of the broad ones. A few of the more specific ones are specific commodities that can be transported -- minerals, colonists, etc.

Anything -not- in the Sacred Numbers list can be switched around, changed, etc, with impunity -- so long as it's properly formatted and composed out of elements that are tagged with Sacred Numbers, nothing's gonna matter. Non-Sacred member entries won't have any hard-coding involved with 'em.

One of the implications of this format is that users will be able to save designs for ships pretty easily -- all a ship design is is a long stringing-together of these numerical entries.

I've started getting into IS stuff again. I've realised, yet again, that I need to scrap (pretty much entirely) what I've written so far.

Okay -- so much for hardwaring stuff into the program. I shoulda realised before that that was dumb. Various places and people -- well, pretty much everywhere and everyone -- have tried to hammer it into my stupid head.

So. I've gotta build two modules for the program. One's a file file-loader-and-parser that reads in the object data files and maintains a list of the information. I'm kinda leery of maintaining the entire list in memory, just because I don't know how the bloat might get, but, on the other hand, it needs to be there for quick access; it's the definition of the universe. On the other hand, all of the data, once created, pretty much contains most of what's needed for the program to use it. I think that I may keep auxilliary data out of the created objects but still within the parser -- things like explanations and info that aren't needed except in the screens where objects are shown and loaded for the user. The game engine -- the module that actually crunches the turns and such -- wouldn't need these at all, and they'd eat precious kilobytes if they were included in the actual object data.

The second part is an object builder. The object builder gets fed a stream as its argument -- pretty much in the same format as the object files are defined in the data files. This module needs to work recursively, since many objects contain objects themselves. It returns the object that it's built up, so that it can be added to whatever bit of the program wanted it.

The way this is built, the UI would allow a user to create an object that's a conglomeration of simpler objects, feed them to the builder, and have the object pop out properly-formed. For example, you want a starship composed of a ID 1052 hull, 2064 engine, 2895 shield, and ... a bunch of weapons. You get the idea. Of course, a hull would come with certain things, like cargo holds, fuel holds, etc. Those'd be part of the object's base definition. Of course, afterwards, it might be possible to change those, too -- I don't know.

This is gonna be a pain in the ass, but possibly less of a long-term pain in the ass than doing it the stupid way.

I Just Can't Seem To Figure It Out

I've been having problems with my basic IS data structures. Most of these problems originate from the fact that I can't seem to do the garbage collection properly.

cParticle{
vector *particlelist;
basic_string *string;
typeID m_tid; //Enum
int data;
int uid;
bool destroyed;
}

That's my principle data member. It clocks in at about 28 bytes, which is a lot, but it's lighter-weight that it could be. That's the price I pay for flexibility.

The problem is doing the garbage collection. I seem to be unable to get the delete operator to work properly because of the nested levels of indirection involved in the particlelist pointer: its members may contain further particlelists.

I don't want to drop the linking of particlelists through new, though. The pointer's only four bytes; an empty vector is 16 bytes. I'm assuming a similar level of space-savings with the pointer to a string, too.

I could hard-link 'em all in, but that'd mean that each cParticle would be at least 60 bytes, which seems Unacceptable. (A star object will require, for definition, at least five or six subparticles, which makes a single star object a hefty 420 bytes.

...Though, now that I think about it, that means that 5 megs could hold approximately ten or eleven thousand objects of similar scale. It still seems like a waste. With pointers I could potentially double that.

What I think I'm going to do, however -- the only other thing that I can really think of that might work -- is simply do a lot of optimization through subclassing. I'd devolve the cParticle to an interface iParticle. Subclasses would implement only the data members that they would need, and the rest of the interface would be coded to return failure states if you attempted to change the data that they don't actually have.

iParticle --+- iLeaf---+- iSubcomponent -----------+- cDataSubcomponent
            |          |                           |
            |          |                           +- cStringSubcomponent
            |          |                           +- etc ...
            |          |
            |          +- Destroyable Subcomponent-+- Same as above, basically.
            |
            +- iBranch--+- Destroyable Branch -+- Ship
                       |                       +- Colony
                       |                       +- Minefield
                       |                       +- Weaponsfire
                       |                       +- Etc
                       |
                       +- Nondestroyable Branch -+- Star
                                                 +- Window
                                                 +- MailQueue
                                                 +- Etc

The iParticle class defines the interface to all of the subclasses -- all of the functions are virtual. The iLeaf class is another interface class -- its subclasses will not contain a vector of particles. Attempts to access the vector should return a state saying that it does not exist...along with all the rest of the data, at this point.

The iSubcomponent class is non-destroyable -- any attempts to read destroyed will return FALSE, and any attempts to destroy the object will fail. The iDestroyableSubcomponent will implement the boolean and act normally. After this, the classes are simply based on what data they contain, since in most cases, leaves will only need a datavalue, or a string, but not both.

The iBranch class contains an instantiated vector of cParticles, though this will be empty. The rest follows similarly to the leaf class heirarchy, though the various classes may also define what leafs are contained within the structure. (For example, a star object will always have data members X_POS, Y_POS, and CLIMATE, along with resource flags that I haven't figured out yet.)

This is, of course, more complex, but it saves RAM, and would allow me to embed objects directly into other objects without dealing with pointers, new, or anything other than the default garbage cleanup built into C++ and the STL.

I think that this is the approach I'm going to take. At least it'll require only a minimum of rewriting code; most I'll just be able to cut-and-paste in.

I love it when babbling on LJ helps me solve my problems, or at least gets the thoughts flowing enough to open up new ideas.

This is completely crack-headed, but it basically came to me in a dream.

All of the game objects, like ships and planets and weaponsfire, will be made up of a lot of smaller objects.

Each of these objects -- of the base class IparticleInterface -- contain five variables: a UID (Unique Identifier), a TID (an enum that's a Type Identifier,) an integer DataValue, a vector of more IparticleInterfaces, and a basic_string of chars.

The key to this is that, for the greater part, these objects just hold and manage data. The constants defined in the enumeration will be used by the various bits of the game engine to figure out just -what- the data defined there is, and what it will be used to do.

For example, a Ship would have the TID == SHIP, and within its container-vector would be objects with TIDs of HULLTYPE, X_POS, Y_POS, and a great number of other things. Between the string and the DataValue contained within each object, I can cover just about all information this way. Basically, I'm just going to be using a vast number of lookup tables to define everything.

For those of you out there who have some experience with such things -- is this completely and utterly stupid-crackheaded, or what?

My allergies -- or some bullshit cold -- are totally fucking me over. My nose is a faucet, my brains feel clogged with mucous, my throat's raw from post-nasal drip, and I'm nauseous from swallowing the same.

Bleh. :P

This's going to be a relatively long entry about IS's data organization and ideas for how the various modules will interface with it -- and what those modules will be.

I'll use a cut to spare your friends lists from the scroll.

( Read more... )

In case any of you didn't know, I'm rather new to this whole object-oriented programming thing. In fact, I'm rather new to this whole "programming something that isn't utterly freaking trivial" thing.

So far, I've got the way that most of my data is being stored sorted out, at least in a vague workable way. Whats beyond me, though, right now, is how I'm going to build the code to interact with it.

One of the problems is that I've got to queue up commands that the player issues, so that they can be saved and then transmitted to the host. (The player-clients are not allowed to make alterations to essential data; they are only allowed to request an alterations, which are executed by the host, during host. The client program catalogues the alterations that the player desires to make, and displays the data the player needs.)

The main problem is that I want to handle this in a relatively consistant way.

I need to do more research on game architecture.

I haven't done too much work in the days past since I last posted here; today, I went on a big productiveness-spree, but the rest of the days were pretty much lost to both laxity and other responsibilities.

Today I got Allegro installed and, presumeably, working.

I also got a chunk of the world-creation code going; I can now create randomly generated lists of stars of arbitrary size.

That only took about three hours of debugging because of DAMNEDSTUPIDERRORS on my part to get working. Hopefully I'll learn from that and not repeat it.

I think I'm going to get a quick display going in Allegro just so I can see these things here. Some of the data I'm getting makes me think that the random number generator isn't working quite as randomly as it could.

Okay, fleets will definitely be in. I'm just not sure how I'm going to implement it -- whether I'll want every ship to have to belong to a fleet (including fleets of one) or whether I'll do it in a somewhat more complicated (for me, anyway) manner.

I think I've got the basic architecture for the program laid out, and I've started laying down code. I've gotten to the point where I'm going somewhat nuts just doing documentation, and have to start getting stuff together in a more concrete form. Of course, half the time this means that I realise that I've implemented something in a stupid way and I have to go back and re-do everything I just did in a different manner, but, hey.

Also, though this has nothing to do with anything I've already mentioned, starbases will just be ships with the ability to create other ships, and, most times, also being unable to move from the spot where they were created. More on this later.

Because of the nature of Infinite Suns -- that is, being turn-based and asynchronous in nature -- combat cannot be directly controlled by the players. The only way that they can control it is by altering the variables that enter the arena.

Ships do not automatically enter combat when they encounter the ship of another faction. One of these ships has to be actively hostile to the faction it is encountering. Ships can be set to not initiate combat (and, indeed, this is the default setting that ships are created with,) to initiate combat if they encounter -any- ships not of their own faction, or if they encounter ships of specific factions: they can select any or all of the other factions to be hostile to. It will also be possible to globally set all of a faction's armed ships to be hostile to a set of factions, and this global hate list will be used to initialize newly created ships, too.

(Currently, I think that I'll have two ways for a player to change the factions that a ship is hostile to. One will be via the long way -- giving them a menu of factions to select from, and select each faction that they wish to be hostile to. The other way will be to save a list of a group of factions to be hostile to, which is named by the players, and is easily selectable. This way, a player doesn't have to designate for each ship that it is hostile to Germany, Japan, and Italy ... the player just has to select the "Axis" group.)

When two groups of ships from different factions encounter eachother, different things may happen. There are four flags that can be in play for each ship: Hostile, Neutral, Noncombat, and Reserve.

Hostile: If a ship is flagged as hostile to another faction's ship, it will automatically attack it.

Neutral: If a ship is flagged as Neutral, it will not automatically engage another faction's ship. However, if another ship of its own faction is co-located and is engaging in combat, it will throw in with its own faction. It will be in the first attack wave, along with all of the allied Hostile ships. If the Faction that the neutral ship is on is being attack, it will also be in the first defense wave.

Reserve: If a ship is flagged as reserve, it will not be in the first attack or defense wave unless all there are are reserve ships. Once the first wave of their own ships is dead or fled, the reserves enter combat.

Noncombat: If a ship is flagged as Noncombat and defending, all other ships in the location will enter combat before it does. If the ship is flagged as Noncombat and is on the attacking faction's side, it will not enter combat at all.

A ship cannot be flagged Hostile and Neutral or Hostile and Noncombat. It is possible for a ship to be flagged as Hostile and Reserve, Neutral and Reserve, or Noncombat and Reserve. Noncombat implies Neutral.

A ship that is noncombat and reserve and is being attacked goes, as expected, in the fourth wave.

Point of Definiton: "Attacking":

When one faction has any ships flagged as hostile, and their enemy doesn't, then all of the ships on the side with the hostile ships are considered "attackers," except for the noncombat ships, which effectively don't exist for the combat.

When both sides contain ships that are flagged as hostile, both sides are effectively actually defenders. Because of this, noncombats will enter combat, albeit in the last possible wave.

Combat Resolution:

Combat happens between two groups of ships at a time. Both groups are introduced at maximum range, and then close to weapons range with eachother according to their ship profiles. Firing happens in both fleets simultaneously; however, weapons will have ranges and may have recycle times. Different ships also close at different speeds, based on their engine tech and racial attributes.

It's entirely possible that a fleet of fast ships with longer-range weapons could maintain enough distance to stay out of their opponent's weapons range, blasting them into kibble all the time.

After enough ships on their own side are destroyed or after it is damaged enough, a ship might decide to attempt to withdraw from combat. Attackers and defenders may try to pursue fleeing ships; defending noncombats that have managed to seriously damage an enemy will not. However, if there are ships in the faction that aren't fleeing, the other side may concentrate on the ships that are still putting up a fight instead of going after the ones who've broken from combat.

Target selection:

Ships will decide which of the opposing ships they want to attack. They may coordinate with their comrades or they may not; the level of cooperation is race-specific. Some races may prefer to double-up on enemies, some may prefer to engage individually, and others may just select entirely randomly.

Additionally, each ship will have certain preferences for the way it targets its weapons. A battleship will go after battleship-level targets first. Other ships may go after smaller ships first. Some ships with multiple weapons systems and advanced targetting systems might engage several different targets at once.

Winning Combat:

If one side is entirely eliminated, the other side wins. If one side flees from battle and the other side has ships which did not flee from battle, then the side with unbroken (that is, not fleeing) ships wins.

If both sides flee, then the defender wins, on a technicality. There is one exception to this, however: if the planet is owned by the attacker and the attacker has a starbase that's still functional, the attacker is designated the winner. This is condition is actually only possible with races that have mobile starbases, because otherwise a starbase is incapable of being broken or fleeing from combat.

The winner of the combat is then allowed, during his turn, to have his ships interact with any planets present. The loser is not.

If both factions are still present in the system during the next turn, they will attack each other again. However, the loser can (and probably should) withdraw and go somewhere else.

I originally conceived of IS as using space lanes similar to those of the Masters of Orion series. With time to mull it over, however, I've decided that it's just too much of a pain in the ass to implement at this time, no matter how I like the idea. Maybe I'll make it an option in some later revision of the game, but not right now.

Anyway.

Currently, there are only two things that can move on their own power: starships and (very few kinds of) starbases. They all move between stars via FTL travel. Ships consume fuel, a resource generally found on or around planets, to do this. There will be differing levels of engines in the game and different racial attributes that will affect things such as maximum speed and engine efficiency.

Ships are free to move about within the confines of the starmap. This is done by setting a destination point and speed for the ship. When this is done, the ship will move in a straight line towards that destination at the speed it's set at. Destination points can either be set in empty space or on planets; when the ship gets to a planet it is considered to be 'in orbit,' and may interact with the planet, scan it, colonize it, or whatever.

Ships may also be set to intercept other ships; in this case, they will do their best to ensure that they co-locate with the target ship at the end of the target ship's movement. (...Argh. This means I'll have to change another aspect of my current concept. Duh.)

I don't want fuel to be overly scarce in IS: I want it to be a resource that ships need to renew periodically, and that players will have to manage strategically only when they're moving large fleets around.

In Infinite Suns, the game universe is a large map populated by stars. The dimensions of the map and the number of stars therein are user-defineable; these variables are set when the Host sets up the game and generates the universe.

The starmap and the ships use integer math, so the starmap can basically be thought of as a bitmap. Stars occupy one pixel, and pixels are one light-year across.

The stars that occupy the map are generated randomly, according to the following rules:

1: No star may occupy the same location that another star does.
2: No star may be placed immediately adjacent to another star -- all eight squares next to it must be empty.

Each star is assumed to have one planet that can be settled; the terms "star" and "planet" are, in this game, interchangeable. Each star is generated with an ID number, and, eventually, a name. Along with this, a few more values are set, including a climate value for the planet, the amount of minerals available on the surface of the planet and under the surface, and whether or not the planet has natives, and, if it does, what kind they are and how numerous they are.

After the stars are generated, they don't move around, and there's no way to destroy one. That may change at some point, since I've always been a fan of weapons that could be used to destroy entire planets, but currently I'm not considering it.

Welcome. This is the development journal for Infinite Suns, a game which is currently being developed by tropism.

Infinite Suns is a multiplayer, turn-based game of the same genre as Masters of Orion, VGA Planets, and Galactic Civilizations. It's being developed on a Windows system for Windows systems, though the only thing standing between me and developing a port on other platforms is my massive and monolithic tendancy to slack.

The game is being developed primarily as a game that is played by email, with a single person acting as a host. There are, at the moment, no plans for implementing NPC AI; Infinite Suns is to be a purely multiplayer game. As such, there are a few specific aspects of the game play that I want to emphasize with the design.

First, the gameplay is to be relatively streamlined and simple, though having some extended strategic options. This isn't a sociopolitical simulation, here; it's a game where people manage planets only because it's necessary so that they can build ships to blow eachother up with.

Second, there should be no arbitrary limits on players. If they can scrape together the resources to build a fleet of ten thousand ships, then they should be able to build each of those ten thousand ships. If the host wants to make a starfield that's 256x256 or 25600 by 25600, well, then, he should be able to. Whether you want two players or fifty, the players should be accomidated.

Third, this is a game played by people with people. As such, it requires facilities that people can use to communicate with eachother, in-game. Infinite Suns is to have a relatively robust, email-like system, allowing players to send messages to eachother, whether they are one-word demands or ten thousand word screeds railing about whatever. A part of this game which is often overlooked is roleplaying, and I believe that that is because the communications facilities in most similar games suck.

More shall come at some point in the near future; over the next couple of days I plan on puking most of what I've got forth into this journal. The content will range from sketchy speculation to technical detail of implementing various features. Feel free to comment with suggestions or advice, or to tell me why this whole thing sucks.

This is a test. This is nothing but a test.