Right now I’m making a couple changes to the duel system. Someone posted on the forums a desire to have a more formal 1v1 system since this is a popular form of competition between players. I said that’s what the duel system is supposed to be for and people suggested that the amount of shields in duels be raised and the ability to use hardware allowed. So these changes are being implemented. Will this make the duel system more popular? We’ll see…
The caffeinated coder is working on what we hope will allow us to make January 2009 Starport Token Buyer Appreciation month. More specifically it’s a system where you can refer other players who are making their first admiral tokens purchase. Every player will receive a promotional code that they can tell to another player and get a bonus of 40% of the tokens the other player purchases, up to the first fifty dollars that person spends. Since we’ll probably consider everyone a first-time buyer when the system comes online, it will be like an appreciation month
Next up I’m hoping to balance some aspects of the economy by potentially making ship and hardware prices variable, introduce some sort of more advanced system of ship customization so that players can create more variety in the choices of ship to use, and probably introduce some new types of hardware that can be deployed.
We will be adding an option to the game to allow players to run the game in windowed mode instead of full-screen if so desired. This should help support more players with different monitor types.
The asteroid belts are soon to come as well.
We found some memory issues that we cleaned up and will be patching in hopefully today. Some people were using up tons of memory while running the game and freezing up. We should have that fixed now.
I’m excited as I type this post. We are working on pulling servers statistics into a sql database onto the webserver. What that means is that (the website will start crashing periodically :)) we can build tables of stuff like characters with the top 10 experience across all galaxies. Or, for example, the people with the most npc kills or colony captures across all galaxies. No more will you be limited to comparing yourself to players in your galaxy. Sql will make the data accessable, searchable and sortable. Also for the rebang players it will immortalize your achivement of the win of that bang of the server.
Those are the lofty goals, it will likely start small with stuff like experience, rep and the stuff you currently see in most player’s profiles. The tables will expand from there. I’m hoping this will lower the instances of multi-accounting by making you more attached to your character. More scoreboards will mean more ways to compete and play starport and we’ll be looking for input as we develop this and it will be an ongoing process of us adding things to it as the game matures.
I’m currently working with Lovecraft to get this ball rolling and will happily update you with our progress.
I’ve noticed a couple of big threads on the forums about crashes when alt-tabbing. I’ve added some more robustness to our render and how we handle the loss of focus. I fixed the visual bug that occurs when you alt-tab on the login screen and the buttons stop drawing. I also fixed an alt-tab crash.
I can’t promise this will fix all the alt-tab crashes but hopefully it lowers the rate at which they occur. If you get a Starport crash:
1) Look for a thread that is related to what you were doing when you crashed, if its a bad bug there’s probably already a thread
2) Post your crash (the more posts we get the more serious we treat an issue).
3) Include what you were doing when it crashed, what OS you run, what video card you run, and most importantly the full text of any error message that you got. Other things like ram/processor type/processor speed are good too but the stuff I listed above is a must have.
I’ll hopefully be getting back to looking at performance of the lasers soon. Crashes take presidence over performance.
I felt the need to justify all the latest crashing and patching.
Some people noticed that when you fired the fusion blast it would crash the Starport client. We recently got rid of the FusionBlast.tga as well as many other art files. They are now all inside sprites.bmm. The reason we did this was to improve loading times. Now when the game launches instead of pulling in all the individual tga files it reads 1 big file. We also precalculate lots of things on the tgas and store the precalculated data in sprites.bmm. This is usually referred to as “data cooking”. This drastically decreased our loading times. We had to patch sprites.bmm in slowly because it was 50 some megs of data and we didn’t to have a 50 meg patch. The problem started occurring when we removed the old data files from the install. If you had an older install that had been patched you still had all the old data files (the patcher can but does not erase files it mostly just changes them). Thats why some of you were experiencing the problem and some were not. We couldn’t figure out what was going on for awhile because we have all the art assets in our project folders. So when the game tries to load the art files it would work for us.
As as side effect of the fix to this issue, we now store compressed copies of most of the art in the game. This does increase our memory footprint a bit but hopefully I can use it to speed up and stabilize our “alt-tab” recovery times. So if you have issues with alt-tabbing hopefully we can make that better.
So enjoy the faster load times and we apologize for the crashing. It should all be fixed now, if not I look forward to your flames :).
Tim AKA CaffCoder
Laser turrets are cool. Unfortunately the stuff that makes them cool is the stuff that cause huge performance hits. The problem is they can collide with things and they are rotated which can be slow. This can cause us to do tons of calculations between frames, checking for collisions, doing rotation calculations, etc. on huge lists of bullets. So we were thinking about lowering the firing rate of lasers by about half. Which would cut down the size of the list by half and essentially double your performance when doing crazy colony invasions with max lasers. This would be one of the more simple ways of fixing the problem. But as it could drastically affect the game-play I wanted to post it here and get some thoughts about it or maybe some discussion. If nothing else this is a warning that something is going to change with laser turrets and now’s your chance for input.
So my initial proposal is 1/2 the firing rate of laser turrets and 3 times the damage. Less bullets would be easier to dodge and 3 times the damage would attempt to make up for the fewer hits.
Flaks aren’t nearly as bad because they don’t rotate and they don’t bounce. Therefore we’re not really going to monkey around with them.
My latest and greatest idea that i intend to implement straightaway is asteroid belts! This is only the first part of a broad change to star system geographies intended to increase realism and make deep space combat more interesting.
Right now there are few obstacles in space. This makes tactics a bit boring as the edge generally just goes to the faster ships and the ones with superior weapon range. By adding in some obstacles, such as asteroid belts and space station panelling, I hope to create a wider variety of combat tactics.
The belts will be circular walls essentially, with holes in them. Some belts may have many holes, or very wide holes spanning great arclengths of the orbital ring, while others may be very dense and closed off with few holes. Some belts will probably even be around planets, in what would normally be a moon’s orbital.
I’m wanting to introduce more stuff that is from actual observed astronomy. One thing that I want to implement which i think might be cool is binary stars, which in the real, observed universe, represent a large percentage of star systems. I also wish to implement different star systems sizes, so that some can be bigger than others, and i might experiment with increasing the gravitational constant, or reversing it for a “hill” effect rather than a “valley” effect.
My last post titled garbage week proved to be prophetic. Aaron(Toonces) and I spent all week figuring out why starport was chewing through so much memory. It turns out, we haven’t a clue. On the brighterside we’ve mostly fixed the problem. We can only speculate on what it was… We turned off sound and disabled the chat bar and some other large sections of code and floated around for hours on the new perma watching memory usage go up. Then we ran it through Glowcode 6.2 and it pointed to several functions that seemed to be holding onto large chunks of ram. It was the damage sprites and the thrust sprites in the game that appeared to be chewing through the ram. We looked and looked but found no leaks. We were allocating and deallocating the sprites in what appeared to be a proper way. So we re-wrote a lot of the code making it more efficient and the problem went away. The way we were doing things before, although slower, shouldn’t have been making the memory usage go up but who knows.
So probably not as many cool new things in the near future, but better performance and less memory usage and the ability to play for 12 hours non-stop :).
The Starport client appears to be leaking so now that the email stuff is done I will tackle the leaks. That way we all can enjoy at least 12 uninterrupted hours of starport without rebooting our machines.
For the developers out there, I’m using visual studio 2005 and it comes with a built-in leak detector which makes things easier when it works correctly. I believe it tags each memory allocation with a number. If on exit, it finds an allocation that wasn’t properly freed up, it tells you that you leaked allocation number 4235 or whatever. You can then run the application again and put a breakpoint on the 4235th allocation and see what line of code you’re ultimately leaking. This assumes that the 4235th allocation is always the same, which in a game, is not likely. Its way better than nothing though. There are other things that you can do (like write better code in the first place). You can systemically debug, like I can turn off the graphics and see if the leak goes away and try to pinpoint it that way. Also if you use a good version control system you can roll back to a version that doesnt leak and slowly add in changes and see which caused the leak. It all seems very logical when its presented to you as an option, but you’d be suprised at the number of developers that just stare blankly at lots of lines of code and give up saying “it could be anywhere!”.
Shout out to Jym (Scott) who setup and showed me the leak detection stuff in Starport.