Recent Forum Posts
From categories:
page 1123...next »

I should mention that the game is not currently under active development. That aside, this is still an interesting topic.

Our game has no quests, NPCs, and no rounds, no factions. There is no wealth, only budget (no national debt of surplus allowed here!). We are not going for a linear story (sure there is a back story, but you could say there is no front story), its a pure strategy game.

The power of a player (in FG's context, it would be the usable output resource wise of their economy AKA, the size of fleet they can support) in any game follows some mathematical model. In the simple level based RPG realm and in RTS before hitting resource/pop based limits, a player generally tends to improve in power exponentially (growth rate proportional to their power). In an MMORTS, that would mean that if you doubled your power every 30 minutes (thats super slow paced for an RTS), a player who started only 1 day before you would crush you in a second, and be about 250 thousand times more powerful than you regardless of how long you play. Fail. If you could afford one unit after 30 minutes, after a day the server would be killed by one person's fleet if they choose to make low cost units. There is no strategy in unlimited growth; playing longer always beats being smarter. This is an RTS game, thus it can't have unlimited growth.

Basically we need a non exponential power function. The obvious choice is a logistic, with a carrying capacity determined by how good of player you are. I'd aim for a short time constant so your nation grows (or falls) in the matter of a few days (though it would depend on the server). Its true a non convergent but less than exponential power function could work, but I don't see a good way or reason for it.

The design is simple: some places are better (produce more resources for the extraction costs) than others. Your carrying capacity is higher if you can hold better planets. Unless you already have the best several planets in the game (making you the top ranked player), there is always a better place for you to go, but taking+holding it may be more expensive than the gain, in which case you will start to lose forces and lose some planets (likely your new better one). Planets slightly better than yours will tend to be held by players slightly better than you, and those planets will afford them slightly more resource for a slightly larger fleet. Its really just a PVP ladder. There is no real grinding/leveling. Its a strategy game: longer playtime should not make you better than someone assuming they have had enough time to stabilize their nation. In effect, everything after the first few days until your nation stabilizes out in the bad/uncontested planets is endgame.

For this to work, you simply have to prevent taking hundreds of bad planets from being an effective strategy. The only way to do this is to have some cost to having more planets that grows with the number of planets you have. My proposed explanation is bureaucratic cost, but the explanation really is a minor issue.

by Craig MacomberCraig Macomber, 10 Sep 2011 02:56
AlfonzFred (guest) 10 Sep 2011 01:19
in discussion Fragmented Galaxy / Game Play » Soft Capping National Size

Limiting player growth by harsh in game rules will dampen the end-game experience. Whats the point of striving for victory if you have nothing to gain except limitations? There are few games out there that I've seen that can really boast a persistant world, in combination with an RTS, and MMORPG. The main reason is usually the devs wish to create an environment persistant with a linear story. The main draw back of which is obviously ''How can we integrate an RTS into a story''. So they dream up ideas to limit player interaction to skirmishs, agreed PvP, or non-effectual (but fun) large scale encounters. I can't say I've read deeply, thus far, into your game, but on the surface it appears you're heading in that direction, so I chose to reply to this article in particular.

In my opinion the best solution to the problem of player limitation is either to constantly expand your universe, which can be done through quest packs etc.. which you could possibly charge for, or better just reduce the concept to a round based game, which in and of itself would introduce some other fun aspects into the works.

Imagine setting various variables as far as planet types, nebula, asteroid fields, distrobution of resources, NPC factions, quest hubs, black holes, white dwarves, what have you.. that you might like to see in a universe, setting a list of these variables and building a randomising program as opossed to a static universe would free you to make a complex and varried universe, yet completely different each round.

The over arching story can be the same, certain factions may continue, but it gives the players a chance to sieze land, build empires, and actually play the RTS factor of the game without being limited to instancing.

As far as questing, trading etc.. you could even integrate a randomisation of quests.. say only 30% of total quests created will appear in any universe generation, and factions may change in strength, wealth, or even personality.

Just some thoughts as it seems you guys are right at the start up phase of operations, and I do hope I didn't offend anyone.

-AlfonzFred-

by AlfonzFred (guest), 10 Sep 2011 01:19

Will the position of the weapon on a ship affect its line of sight (cannot fire through own hull)?
When does a ship get assigned to a node? Will its node ever change?

The answer to both of these is not until the AI is smart enough to deal with it. I'd like to allow both eventually, but it ups the complexity quite a bit. restricting firing arcs should not be too hard for the AI to tolerate, but letting ships move around in formations requires quite a bit more in configuration settings and AI. Its also not really needed for the pure ship combat game, but would be necessary for more realtime systems that may come later.

What is the difference between a designated formation positions (blue) and a node?
I see the formation position for each ship, but could there be another marker (red?) for the macro-formation?

All formation positions, including those occupied by sub formations as well as ships, are marked by the blue indicators at the moment. That marks where things are trying to fly to, vs where they physically are. Color-coding the formation positions based on type is a good idea. I'v probably been using "formation node" and "formation position" interchangeably. There will be a distinction at some point in terms of how the editor works I guess, but don't worry about it, I haven't been consistent with the terminology.

Would this move the 'base' of the Fighter Pack (Formation)? By 'base' I mean the average position of the ships.

That particular stat would just effect targeting AI (focus fire on enemies doing the most damage, not those damaging you, or ones easy to hit). If the fighters were set to strongly try and stay in formation, but their sub formation was set to easily leave formation, then the whole fighter sub formations would go fly out there. The base position for a formation is not set by the average position of the ships. Is what controls where the ships go (unless they leave formation), not the other way around. There may be options to bias the formation position toward the average of the ships to help keep formations together though.

Does each Formation have its own 'base'?

Both ships and formations are instances of the "FlightNode" class, which basically represents a thing with AI that flys around. Formations however don't have to obey any physics (they can specify their position where ever they want), and the ships have to thrust around to try and get to places. You will have many (sub)formations (and ships too) and they are essentially independent except that they may/will be configured to listen to or make requests of their parent formations.

In other words, how are you going to make sure that a Formation with low 0.0 weighting on Maintain Formation priority is not going to disperse the positioning of the rest of the fleet?

Thats a downside of having a low weighting on Maintain Formation. There may be other priorities you can use to help compensate (perhaps some cross formation blobbing/flocking priorities), but having low Maintain Formation priority should have serious downsides as it wrecks your spacial organization. Setting it to 0.0 might be pretty poor strategy in most cases, but thats an issue for the player to try out.

Kiting is pretty much the basic strategy of ranged combat. It would be foolish to leave it out :)

Thanks for your comments!

I've been busy with work and haven't been making any progress lately. Its kinda hard to get excited about it when my work involves mostly the same programming languages and working with the same engine. Next in line is getting the AI system really functional, which does look pretty fun though.

Re: Fleet Combat Status by Craig MacomberCraig Macomber, 27 Aug 2010 19:24

Ooh. I like the sub-modules for weaponry and shields.
Will the position of the weapon on a ship affect its line of sight (cannot fire through own hull)?
When does a ship get assigned to a node? Will its node ever change?

the nodes in the formation (grid points in them etc)

What is the difference between a designated formation positions (blue) and a node?
I see the formation position for each ship, but could there be another marker (red?) for the macro-formation?
Does each formation have a node for itself, or do only the ships have nodes? I remember you explaining this to me as a hierarchy: [Hanging_Mobile_2_sq.jpg http://www.architonic.com/imgProSat/davidweekssat/Hanging_Mobile_2_sq.jpg]

Target Overall DPS: .9 -Make the fighters focuse on ships damaging the fleet as a whole far more than on those damaging themselves

Would this move the 'base' of the Fighter Pack (Formation)? By 'base' I mean the average position of the ships.
How does this Target Overall DPS 'priority' interact with the Assault (Formation) Maintain Formation 'priority'? Does each Formation have its own 'base'? What if the Artillery (Formation) and the Assault (Formation) are very far from each other. Since the Artillery (Formation) has no Maintain Formation weighting, then is only the Assault (Formation) responding to the Maintain Formation priority? My point is that the Maintain Formation weighting should not be mutual between all sub-formations, because when the Assault (Formation) gets too far away from the Artillery (Formation), then the Front Defense (Formation) might abandon the Artillery (Formation) in favor of a position halfway between the Fighter (Ships) and the Artillery (Ships).
In other words, how are you going to make sure that a Formation with low 0.0 weighting on Maintain Formation priority is not going to disperse the positioning of the rest of the fleet?

I like that you include kiting as a setting/priority. Kiting is my favorite strategy in most videogames, second only to the "upgrade my stuff before fighting" strategy.

Great work! I look forward to playing with the app.

Re: Fleet Combat Status by PhenocaPhenoca, 27 Aug 2010 02:48

Head over to the new fleet-combat page and give it a read if you haven't, especially the short new Battle Simulator section at the end.
Formation.png

Thats a 14*14 grid formation, each node containing a single ship. It is placed inside a parent formation which contains it and a single other ship just behind the front grid. Basic thrust control AI is working so the ships 'try' to stay in formation by both attempting to fly toward their designated formation positions (shown in blue) as well as thrusting to match the velocity of their formation position. With a significant mass and limited thrusting power, there is a limit to what accelerations the ships can follow. Pictured here are the ships after the formation has exceeded their maximum acceleration by stopping and turning rapidly, just before all the ships regain formation.

As the battle simulator can run fine in slower than real time (this fleet of 197 ships did manage to run in real time though), it is possible to simulate and render battles of essentially unlimited scale. It might take a long time, but it could model (and render to a video) a battle of hundreds of formations and thousands of ships. I ran a little test with 40000 ships and it seemed to work (But it ran really slow as expected). 250000 ships works, but is really slow. One million ships did not work (Out of memory error)

I've been doing quite a bit on both the editor and battle simulator recently. With a bit more progress on the editor, and some more AI, we will be starting to have a real game.

Discuss here.

Fleet Combat Status by Craig MacomberCraig Macomber, 03 Aug 2010 21:55

I vote for approach #1. We should keep it RTS and get the engine up and running.

We can start by making a data structure that can hold the data for each fleet.

We should begin with just three ship classes (and graphics) and no graphics for the equipment (except for weapons-fire). It won't be hard to come up with some numbers for that small number of items.

Also the AI needs to start simple. If we initially only have two players the fleets could just start flying toward each-other and the AI should just shoot the closest ship.

Here would be the parts:

  • Game client
    • Battle sim (place ships on the map where each player would get points to spend on "buying" ships from their loadout and battle to the death!)
      • Graphics for three ships
      • Graphics for weapons-fire
      • Graphics for ship death
      • A rudimentary AI
      • A system of keeping track of each ship's hit-points
      • A UI for selecting/placing the ships for battle
    • Fleet creator (just for making all the different ships in your fleet kind of like a "Fleet Loadout")
      • Data Structure for ships/fleets
        • Ship class
        • Ship class "cost"
        • Ship equipment
          • Which hard-point the equipment is attached to
          • What kind of equipment it is
          • What stats the component has
          • What "price" the component has
        • A UI for creating the ships
        • A UI for making squadrons
  • Fleet file exchange website
    • Upload fleets
    • Download fleets

Did I miss anything? (probably a lot in the specifics) Let's get this list of what to do completed before moving on.

Re: Development Direction by tbg10101tbg10101, 22 Jun 2010 20:18

Where do we want to start? I suggest beginning with the non-campaign single-player mode because it would allow us to test and develop all the systems needed in the other modes. (except for p2p communication for multiplayer and campaign quirks)

I see 2 main approaches of getting to this point:

Approach 1) We start with getting fleet design and AI working. Once thats done, we can have autonomous fleet vs fleet battles (to battle someone, you just need their fleet file), and let people upload fleet files to tournament servers and we can use the data from what people over use in those to auto-balance the pricing and strengths of components. As soon as real fleet vs. fleet stuff is working though, we can start making (and accepting from the community) various single player maps and campaigns (and potentially mods to the available components and such as well). This pretty closely matches what we would need to drop into the FG MMO to add space combat

Approach 2) Screw fleet and AI design, and just do ship design. Then make a multiplayer 1st and 3rd person space shooter with custom ships (Initially it can not use custom ships). Add in AI to allow for single player then add in control of a full fleet with semi autonomous AI later. (With a bit of work on an modified physics engine and control AI, you could also make an in atmosphere fighter dogfighting setup if you wanted)

Both seem pretty good to me. Approach 2 basically starts as a generic multiplayer space shooter game, then gets features (custom ships, single player, fleet combat etc) where approach one really starts as more of a design and simulation type project. The end result would be the same as once it has all the features from both, we can enable all the play modes: autonomous fleet battle, rts, fps, first person swarm shooter (fps with a fleet instead of 1 ship). All of these could be both multiplayer and single player running on the same engine (if we design it correctly!), and single player campaigns could mix all the play styles as desired.

As for any MMO aspect (which could be added later) the online players could be responsible for the processing and data storage for their ships, planets, etc. This way the server would only need to support the load of offline player's replacement AI. Areas where no players were could be simplified or shut down until a player needs to access the area. Just an idea. I agree with you, Craig, let us forget about the MMO aspect until we can get the game out.

just single player and player to player multiplayer

Ahh, like in Civilization IV, I see what you are getting at. I see three different modes: Campaign, Multiplayer, and a randomly generated game (like a regular game of Civ with a randomly generated universe). This will make development much easier.

Where do we want to start? I suggest beginning with the non-campaign single-player mode because it would allow us to test and develop all the systems needed in the other modes. (except for p2p communication for multiplayer and campaign quirks)

Let's make a good plan before we jump into development this time. We can make this a semi-fresh start.

Any thoughts?

Re: Development Direction by tbg10101tbg10101, 22 Jun 2010 07:46

One of the main reasons behind my change in focus is that we can make a FG related game with no hosting costs (no central server). It would have just single player and player to player multiplayer. Tournaments when/if supported could be done on a server on game at a time, and if realtime player interaction is allowed, unlike the MMO fg design, the participating players will have to be online, so the vast majority of processing (all the AI) will be done client side. Another reason for the change in focus is that it will make a game that is easier to develop (its just a part of the larger game), and will be fun regardless of the number of other players. (Which is good to help start building a player base, but also good in the case that we never really get much of a player base)

With my shift to free and open source development tools, as long as we can manage to crawl along with unpaid developers, our costs will stay at basically 0$. Its true that I'm paying a bit for the web hosting, but I use it for several other things too, and its darn cheap.

I agree that having alliances greatly adds to a game. Fortunately for us, once we have things working, adding co-op, and 2v2 etc should be pretty easy. And for the mmo aspect, alliances will be crucial for good gameplay.

If this new project goes forward, there will need to be at least one single player campaign,

Yes. I see this quite broadly, as the single-player campaign could be the main part of the game, or an introduction to the multiplayer aspects like being a tutorial. Games which have implemented fleet-design along with campaigns have been Battleships Forever, Gate 88, Star Knights, Gratuitous Space Battles, and Celetania… I liked their approaches to fleet battle, yet it was really disheartening to see Celetania go bankrupt. Games which require high processing-power on the server-end require investors or high-quality personal servers. I was just dismayed that Celetania never had a success when it hit the market, and I think that this was because players needed the incentive of being on a team to donate, instead of doing a free-for-all. Me on a tangent: The point of donating for non-subscriber games is to obtain power in-game, but if nobody is in your alliance then there is nobody to show-off to, and nobody to support. In the games I have played, people (including myself) have donated primarily to help out their alliances.

So somehow, the concept of alliances should be kept, even if the focus is on 1v1 battles. For example, I am participating in a 2v2 team-elimination tournament tomorrow in a 1v1 cardgame named Alteil :)

I always liked your writing Matt. Great to still have you!

Agreed!

I have some ideas on how to design the user's perspective of space gameplay. We should talk about it sometime.

Hey Tristan :)

Re: Development Direction by PhenocaPhenoca, 11 Jun 2010 15:17

Don't be afraid to ask me for a GUI.

The fuzzy focus of the project has also been my fault too. I did not produce much in terms of GC design in the span that it was my responsibility.

I am very sorry about how little time I have spent on FG. Unfortunately college has been taking up all my time. I am trying to structure my time this term so I can actually dedicate some time to FG.

I always liked your writing Matt. Great to still have you!

I have some ideas on how to design the user's perspective of space gameplay. We should talk about it sometime.

Re: Development Direction by tbg10101tbg10101, 15 Mar 2010 20:43

As for your new idea, I think its cool. One thing that popped into my head was if you had all these people creating custom AI and then testing them in battles, you could combine all that data and effectively develop a sophisticated computer-driven AI modal. Essentially you could monitor which player-set AI settings produced the best battlefield results, and use that to create computer-bot controlled fleets that are intelligent enough to be challenging in battle. Could be interesting, and would make the single-player campaign more rewarding if you integrated it into that. Just a thought.

Oh yes, defiantly. I have had success with evolutionary algorithms before, and I would love to employ them both for tuning and balancing the game as well as generating optimized fleets. I specifically intend to use tournaments to exploit player's strategic designing ability in helping with this. The idea here is design a fleet, and let it fight, so battles work with no player intervention (its a design contest, though other play modes could be added). At least in this basic mode, it is very easy to run massive amounts of battles with player made and evolved fleets.

For modes with more, evolving AI to combat the player in realtime would be an interesting challenge. I hadn't really though about how far we could take realtime interaction. As it is a short term battle game, fast paced semi first person control is not out of the question even. Interesting. We may have many modes. Really I just was thinking of doing the basic stand back and watch your fleet fight game, but with a system for making sub-fleets obey commanding fleets hierarchically, there is no reason we can't simply swap the highest level command AI with the player and have a multiplayer first person swarm shooter with custom designed fleets. I see a lot of games that could be made on top of a general purpose fleet/ship design and combat engine. (And a single player campaigns using all the different kinds of games would be cool)

FG is really only still around at all because you have continued to work on it. For that reason alone, you have the complete right to take the development in this game in any direction you want. I feel guilty that I haven't spent much time at all on this project in the past year or so, but at the same time I know I've been working on other projects that have allowed me to improve greatly as a coder, much like how you view FG as a conduit for your own self-improvement.

Note also that it is only around because I choose to call some of my projects part of FG and change the design to include them (Planets got added after I decided planet were cool for example)

I'm glad you are hanging around. It's always nice to have more minds working on design! If this new project goes forward, there will need to be at least one single player campaign, so when the time comes I may want to seek out our lead writer for that ;) We can of course have lots of campaigns if desired (they should be really really easy to make)

As for actual progress on the idea, I made some. I decided to implement the library of designs as a tree, a single tree. All your folder/file like organization of saved designs as nodes, fleet designs as nodes with sub-fleets as sub nodes… Tree structure is like this:
Thing - What thing can contain/have as children in tree
Library - Anything
Formation - Formation, Ship
Ship - Hull (only one, Hull subclassed from Module)
Module - Module, Part
Part - Nothing (Parts only specify stats)

I've got a crude tree display working with basic browsing filters (I'm very proud of my filters system, though making a GUI for it will be hard) and color coding, but no GUI to really do anything with it yet.

I'm really starting to like the versatility of this idea. There are a lot of potential game designs that it could work for (heck, you could do a first person ship combat RPG where you fight in tournaments to win money yo upgrade your ship.) The basic design based AI control version to auto balance the game helps a lot too.

Sounds great, Craig.

FG is really only still around at all because you have continued to work on it. For that reason alone, you have the complete right to take the development in this game in any direction you want. I feel guilty that I haven't spent much time at all on this project in the past year or so, but at the same time I know I've been working on other projects that have allowed me to improve greatly as a coder, much like how you view FG as a conduit for your own self-improvement.

As a college student who is now expanding my interests and beginning to found businesses and projects of my own, I know that I won't be able to devote any time to FG from a coding perspective. However, the conversations I have had on some of these forum threads and the debates over design theories we have engaged in have greatly improved my own thinking process over the years and have been honestly fun. Because of that, I'd like to say that I'm always open to bounce ideas off of or to just talk to about anything. I still follow FG's RSS feeds, so as long as stuff is being written on these sites I will be listening.

Although I probably won't code at all, I love to write and so in addition to posting on the forums I would also be willing to continue developing the storyline or writing descriptions for the game if its ever needed.

So yeah thats where I stand on taking FG in a new development direction.

As for your new idea, I think its cool. One thing that popped into my head was if you had all these people creating custom AI and then testing them in battles, you could combine all that data and effectively develop a sophisticated computer-driven AI modal. Essentially you could monitor which player-set AI settings produced the best battlefield results, and use that to create computer-bot controlled fleets that are intelligent enough to be challenging in battle. Could be interesting, and would make the single-player campaign more rewarding if you integrated it into that. Just a thought.

Re: Development Direction by Matt RMatt R, 14 Mar 2010 07:08

Edit: I should clarify that does not really effect the main plan, just the development order, though it may lead to a related separate game getting produced.

Fragmented Galaxy has been an extraordinarily poorly focused and organized project. I know this, and it is mostly my fault. Also, I don't really mind. For me it has always been an impulse based project. I felt doing ground combat first would allow us to quickly get a functional game out. Without ground combat, there would be no resources, and thus no economy, ships, or game. Well, I went and made planets for a while instead.

Anyway, the plan for ground combat, which will be the source of all resources and ship production, really hasn't been designed to a point where I feel I can implement it. The designs just seem to gain complexity, and I'm unsure of how big of portion of the game screwing with ground combat stuff should be. Originally the plan was to make is super simple, but the idea of significance between different parts of planets was introduced, and things got messy. On that front the project has basically stalled.

Now, on a different topic: Why do I work on this project? The concept for Fragmented Galaxy (aside from the unrefined ground combat ideas) seems very elegant from my perspective as a programmer. It has a very simple yet powerful and realistic economic system, very powerful political system based on some simple building blocks, a rather different and clever technology/research approach, an truly clever and powerful AI setup integrated with the fleet design which mirrors the ship design system. All of these are built on simple principles that are combine either through a hierarchical structure, networking or both. From the programming perspective Fragmented Galaxy is in some cases a worst case game (massively server side, computational expensive, realtime), but those are issues related to computational load. As far as basic implementation and design, Fragmented Galaxy is just a collection of fundamentally beautiful algorithms. This is why I'm still here, 3 years into the project.

And, as to why the project always gets sidetracked: I'm just here to play with clever algorithms. When I started generating planets, I ventured into the realm of procedural terrain generation, high end rendering, graphics card programming, and now the Python programming language. Any of these areas could happily consume years of my life, and I expect them to do so. As far as Fragmented Galaxy goes though, none of these are really very important to the game.

And that leads me back to a new idea. I'm going to want to get to play with those clever AI, ship and fleet design ideas sometime, and ground combat just isn't seeming very interesting at the moment. Thus, I came up with the idea of making a fleet battle game. Basically you would be given a fixed budget to make a fleet, and battle another fleet made with that budget (or potentially a different budget as a handicap). This could start without fleets, just with single ships, and fleets could be added later. Saving fleet/ship designs (including AI settings) out to files for sharing would allow a single player campaign (which could serve as a tutorial) of preset opponent fleets and corresponding budgets (you could score based on budget used, or losses taken, or both, or simply win/lose). We could allow players to battle their own fleets, battle over the network (Lan) or online, and we could host official tournaments (submit your fleet, battles run server side)

This would be a pure strategy and design game with no realtime aspects. Simply make your fleet (or select one you already made), and press go. Potentially realtime or turn based modes could be added where you could send in backup waves or something like that.

This entire system could be kept intact, but imported into Fragmented Galaxy to allow you to use your same fleets in the MMORTS. The only issue I see is with techs; not all nations in Fragmented Galaxy will have the same techs, and none will have the exact same development status on the techs. It is only an issue with integrating the fleet battling game with FG, and thus I'm not going to worry about it now.

Anyway, I now have an idea that will let me play with the AI, ship and fleet stuff, and make an interesting game that does not have serious hosting issues. It might happen sometime.

Development Direction by Craig MacomberCraig Macomber, 10 Mar 2010 22:12

The first time I clicked it the app unexpectedly quit before doing anything, meaning FG quit, not safari, and I got the infamous question mark lego symbol instead.

However, I clicked it again, verified the certificate, and it ran fine. The controls were a bit lagged, but thats obviously because of the fact that its now running in a browser, and it wasn't too big of a lag anyway.

I put up a web build at: http://craig.p3dp.com/webbuilds/webPlanet.html
If you have panda3D installed, it should run in the web browser after complaining about my certificate.

Head on over to the downloads page to check out the new release. I took out the networking that was in the last release because it does not have proper error handling yet, and has a really long timeout.

Again, it is just a planet viewer, with just one planet.

Basic testing shows that it does run on Mac, Windows and Linux, though there are some rather ugly graphical bugs in some cases, possibly on all Windows and Linux computers.

I just tried to run the download, and failed (roughly same issue you had). I think the upload/download process may have messed up the file type or something. Matt somehow got the download version to run, and Tristan got it running on windows (both after quite a bit of trouble). Maybe its just flakey or something. I'll look into it some more. Thanks for trying it.

I'll pack up another release and maybe zip it or something. I'll also try and make (or find) a much more minimal test app for you guys to determine whether it is a panda problem or a problem with the the FG client. I think I'll also try and stick some error handling in the networking just incase the server becomes inaccessible.

Also, if I can figure out the darn ssl certificate stuff, I'll make a version that you can play in the web browser with the panda web plugin. I think that should resolve most of the launching issues.

The download works fine but when i try to use it, the window pops up black, and then after about 30 seconds disapers. ive tried loading it a couple of times but it keeps doing the same thing. My OS is windows xp 32bit. how do you make it load correctly?


Graf

Thats interesting. Thanks for the info.

Also I wanted to add that the planet looks spectacular! My favorite is the quality of the reflection of the star on the ocean surface. Keep up the good work!

The reflection of the sun is just specular highlight, not a real (computation expensive) reflection. That planet is so full of gfx hacks and short cuts.

I just realized that I don't think I match the sun color with the spec color properly. I could make the water appear to reflect the sky colors better. (so sunsets would get colored reflections). I better not start playing with the graphics effects again….

So far it works fine on macs, runs with bad gfx artifacts on windows, and at least runs on linux (my tester did not provide much feedback). Pretty good for an initial release.

page 1123...next »
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License