With this concept, larger systems will suck. 5 mill in a 50 bill system is like what, 0.01% max pop. How does that translate into work force units? It means none of the 3 initial structures will get enabled.

food isn't a "real" resource in games like botf/trekwar/civilization where you have lots of cities. Each city/starsystem just has a simple system to make sure it gets enough food (and is as you say, just a way to decrease available workforce / structure slots for other tasks)


I just made it that way to make it so that you need almost 100% population to run 100% of the buildings, it's basically just there to make population have a role in the game, so that if there is a hunger crisis or orbital bombardment you will get a production penalty. If this way does not work out maybe structures will have a fixed number of people required to operate instead.


All structures that produce something (power, industry, research) needs to have it's power/workforce/etc.. requirements met before they are considered online.
If you have half pop in a system this only means you can not operate (put online) more than half of the maximum number of structures for that system.
population/workforce has nothing to do with the actual output of structures. A structure is either online or offline.


That would definitely suck maybe colonyships needs to add a percentage of maxpop when colonizing, or I'll change the way workforce works.. Workforce and colonization is not really implemented yet, so haven't had a chance to think much about them yet

Here's an idea related to the whole enabling of structures. I just posted this to the Sup forums too, as Infrastructures.
http://botf2.star-trek-games.com/viewtopic.php?f=13&t=3250
In TW, with the obvious differences in system development, and with # of structures already being limited by design, it's an easier concept.
Starting infrastructures would obviously be 3.00 (for the 3 starting structures), and the rest would be mostly the same. The 50 mill pop you mentioned per colonization module would build 0.5 infrastructures per turn (pop/100), increasing as pop increases. Colony ships with more than one colonization module would create a proportional # of infrastructures (3.00 * #CMs), and pop (and hence infrastructures build rate) would be cumulative. So the more CMs, the faster the system would develop.
Defense bonuses, destruction by bombardment/invasion (there's no sabotage I guess), same deal.

So, pop does have a role, just not in directly enabling structures. It's more of an indirect approach.

Interesting idea, but Systems can have like 15 billion people, so that would produce 150 infrastructures per turn. with having less than 100 structures.
Maybe another way than pop/100 could be used, so that it scales "better" with high populations.

I'll give it some more thought when I fix up the planet structure / population systems.. Currently being bothered by a new Memory leak I have to fix.. But I've pretty much located it (not making a game like BOTF that you have to restart every hour)

Hehe, like I said in the post in the Sup forums, Infrastructures cap out at a value that in Sup is given by those tentative numbers I posted - for that game. The obvious differences I mentioned in my post above were TW has a hard limit on structures for a given system - so it's really easy to figure the IS cap. If a system can have 30 *structures*, then it can have a max of 30 IS - it doesn't really need more When the cap is reached, pop doesn't build IS anymore, unless it's needed again (sabotage, bombardment, etc). You could set a max IS construction rate per system (or even per planet type, it could be interesting to have more inhabitable planets build IS faster), but the situations where a system will (re)build all its IS in a single turn should be sporadic.

Terraforming not being implemented yet, here's an idea related to it. Use the techtree to unlock planetary bonuses, and even planet types. Using the Supremacy techtree as a reference, you could make progress made in the Biotech and Construction fields allow access to structures and environments, like:

- Construction 1 (Gamma Fusion - "metal alloys are strong enough to withstand weapon fire and the harsh vacuum of space") would allow colonization of Barren worlds, which would not count towards the system's stats until this tech was researched; this would give a somewhat more dynamic feel to the techtree and to the colonization phase of the game (could open new systems for colonization, if they're < 3 slots).
- Construction 2 (Integrity Fields - "stronger alloys may be used in all forms of construction") would allow building structures in heavy gravity worlds; meaning, the Deuterium Extractor in Gas Giants (which should not be available before researching this tech, empires have to rely on their initial reserves).
- Construction 4 (Phase Transition - "and the density of their intersecting volume is doubled") would allow expanding the colonies in Oceanic worlds, by doubling their max pop (to 2 billion, keeping growth rate and structures), and unlocking a mining structure that produces "minerals"; would work best with "minerals" [Duranium, used for ship construction only?] as a resource though.

- Biotech 1 (Hydroponics - "allow plants to grow in completely controlled environments based mostly on water") would allow building the Aquatic Farm in Oceanic worlds (I'm assuming all empires start at tech level zero in all fields).
- Biotech 4 (Proto-Matter - "Its benefit to the terraforming process cannot be understated") would allow colonization of Volcanic worlds.
- Biotech 5 (Bio-Replication - "artificially replicate more advanced biological compounds") would allow building the Wildlife Preserve in Jungle worlds.
- Biotech 6 (Metagenics - "which can breathe new life into barren ecologies") would allow building the Mining Colony in Barren worlds.

A little update, just finished the ship action system and implemented the Colonization Action, so now it's possible to colonize planets:


Now I'm going to implement the redesigned fleet box (where you control your ships/fleets from), implement mining/harvesting, starship repair and combat, then start looking on the sensor system (which will be a bit complex)

Looks interesting.

The new fleetbox, show all fleets in the selected tile as tabs..
Need to add drag-drop support to move ships between fleets.

I'm likin it! Det er kul

hehe, thanks. Maybe you want to help with alpha testing next month?


Just made a december update on the progress on the trekwar.org devblog, which includes an image of a pimped out Negh'Var from the ship designer:
http://www.trekwar.org/images/klingon_warship.jpg

Update as of December 19.

I've recently added nebulas, and it's now possible for ships that have mining lasers + cargo modules with free space, here's a very fast little mining vessel:
http://www.trekwar.org/images/trekwar_miner.jpg

And I've made some gui updates to the main map (changed background for empty tiles, and faction backgrounds, and the border):
http://www.trekwar.org/images/trekwar3.jpg

I'm currently working on the GUI and back end systems for transferring cargo between ships with cargo holds and starsystems. Then I hope to get some sort of ship and ground combat as well as a sensor system working this christmas.

Hmm..... it definitely sounds good. I wonder how the end product will look?

It probably won't look all that different from the screenshots that are released now, there won't be much killer graphics, 3D or fancy animations in the first release. Instead I tend to focus on the gameplay and the strategy element But the client will be open source, so anyone that wishes can make improvements

What kind of protocol are you using? Might be fun to write a WPF client if it's not tightly coupled to Java.

So far it's using a pretty basic java serialization, but that implementation can easily be changed. I'm planning to do some tests with other methods for transferring data for the beta version (optimized serialization, compressed xml or json)

I use optimized serialization for Supremacy, and it's worked pretty well, but the downside is that it's extremely fragile (not easily versioned). Formats like JSON and XML are better in that regard, but any plain-text format introduces a host of other issues.

Yeah, relatively small changes can often cause synchronization issues between client/server.. will probably make interfaces for much of the game internal logic that might need tweaking during actual play, and then use the java ClassLoader to just use the changed classes dynamically, and see if that makes it easier to change code when game is running.

I would advise against serializing types over the wire--this is a rather fragile approach that can introduce big problems down the road (not to mention the additional size overhead). A more robust (future-proof) approach would be to use property bags or some sort of Data Transfer Object. XML and JSON usually work well too (I'd suggest JSON over XML). If you go with a plain-text format like XML, you just need to be careful about globalization issues. For instance, if a German client serializes a double value 0.5 as '0,5', then a U.S. English server will probably throw an exception trying to parse it. You'll have to be careful to always use culture-invariant formatting. I don't think this is an issue with JSON since it uses JavaScript notation, so that's another reason to use JSON .

Yeah, I was planning to try out JSON, since it's much smaller than XML for the data transfers. But that has a fairly low priority in the list of tasks for this project (only 280 more work hours until it's ready for beta)

Almost done with the Cargo system now, see post about it here:
http://www.trekwar.org/Wiki.jsp?page=Devblog-07032010

*bump*
Hello, guys! I've just read most of the info on the forums and on the site. It's quite interesting.

Any news on the game? When can we see some code?

Klogd hasn't been online in almost 2 months. I'll send him an email and try and get him to return.

Hm... No sign of him yet... On the contact page on trekwar.org there is an XMPP ID, he seems to be online there... I think I'll try to contact him when he's available...

Hi guys, sorry about the long period of inactivity. I've been working full time + had another paying job/project on the side. This side project is now almost completed and I'm feeling a strong urge to get more work done on getting Trekwar ready for alpha testing. So I'll probably do another post in a week or two with a more detailed update.

Welcome back klogd!

Can't wait to hear the update. I'll post a news item for you on our site portal when the time comes too.

Managed to implement fog of war + some of the sensor system today. So the sensor system should not have much work left on it.

Now I just have some rewriting of the structure system, and implementing ground/space combat before alpha testing can start..

Maybe alpha will take place this christmas, unless something unpleasant happens to my free time

I've also decided that the second alpha test will be much more free to play and less controlled by me than the first one, so I will be making a server admin interface so people can easily set up their own games in the near future (a couple of months after alpha)


http://www.erlendaakre.com/wp-content/uploads/2010/10/trekwar_fog_og_war.jpg

Nice work.

It's good to know you're back on this project, klogd. Keep up the good work

Thanks, I'll try and give more regular updates. Hopefully I can get some work done this weekend.

Meanwhile here's a mini update:

• Did some more work on the sensor system, it is now pretty much ready.
• Added a subspace scanner structure that can be built on planets.
• Added Diminishing returns for sensors (each additional sensor has 50% less efficiency than the previous) the 10th sensor will add 0% this means a ship can maximum scan around 10 tiles away if really pimped out with top of the line sensors.
• Questions about Trekwar can now be asked here: http://www.formspring.me/erlendaakre

I now have a pretty good overview of what needs to be done before Alpha testing. There is currently a total of 109 hours remaining in the todo list for the alpha release, I will NOT be adding any new features, so this number should be steadily declining for the next couple of months.

Work hours to Alpha: 109