Some of it, of course was Open Source (Who's hosting that now, BTW?)
SDL (as well as several SDL utility libraries) can be found over at libSDL.org. A number of the open source software libraries and tools that Loki employees and community members developed can be found at icculus.org. I believe some projects are hosted at neither of those sites. Those can most likely be found at seul.org.
Loki purchased the rights to publish a Linux version of Win32 software titles. Loki essentially was selling software and paying a small royalty to the original owner of the software rights. So, when Loki folded, most of the Linux titles simply went back to the companies that the Win32 versions of the software came from. Kohan: Immortal Sovereigns went back to Timegate Studios. SMAC went back to Firaxis. And so on. If you want those titles supported now, talk to the company that originally created the game title.
Some of the publishing deals were a little more. Unreal Tournament, for instance, was just a contract with Epic to provide support for the Linux version of the game. In those deals, Loki was only providing a service.
So, for the idiots that keep saying that Loki should release all of it's game code to the community as a gesture of goodwill... wake up. That's like licensing the Quake III engine from iD and then releasing it open source to whomever wants it. It's a naive and mistaken path of thought to take.
As for the IP rights of the trademarks that Loki owns (such as the OpenAL trademark, web domain, etc.), those will be auctioned off in order to pay Loki's debts.
What were they buying for $350K??? Sounds like a lot of Aeron chairs and BMWs to me.
When I worked at Loki, I sat in a $89 chair and drove a Dodge Neon. People don't seem to realize that $350K is not an unreasonable amount of money to spend in running a publishing business. Have you ever seen what rent is like for office space in southern California? How about telephone bills for the company? Electric bills (air conditioning)? Payroll? Printing and design expenses for the software packaging? Trade show booth space/travelling expenses? Bandwidth costs for the FTP, web servers, and CVS server? How about the bandwidth for the Bugzilla bug tracking database? Or the Loki newsgroups?
The one frivilous thing I can think of that Loki purchased was a Terminator 2 pinball machine that Scott Draeker, Andy Mecham (the head of QA), and myself found at an arcade machine auction for about $2000 or so.
People seem to think that because they could get a dozen people together in someone's basement and form a company that every company should have the same minimal overhead if they are "efficient". That's hardly the way business works. Unless you've seen the actual numbers of the budget of a real publishing company, please don't assume that expenses of $350K is so outrageous.
Try taking the budget of Interplay or Electronic Arts and scaling it down to the size of Loki. I think you'll find that $350K is pretty darn cheap.
Reading Mr. Ganssle's view in the article on utilizing Linux as an embedded OS has really suprised me. I'm afraid that I'll have to disagree with his opinion on the issue simply because I actually have hands-on experience utilizing Linux within the embedded space. I've found that the Linux OS is a natural match to embedded platforms because the kernel and POSIX APIs of the OS can be customized in an intelligent manner to meet the size and processing requirements of a number of projects.
Most engineers that are shopping for an embedded OS want an "out of the box" solution for their embedded device. They want to simply be able to pay X number of dollars and get an OS so that they can quickly move on with their embedded software development. "Generic" embedded OSs, such as WinCE, are indeed a quick fix to that problem. Those same "generic" solutions also lock your project into continous OS licensing costs for the lifecycle of the project, a kernel that can't be touched for optimization (at least, not without paying a hefty fee to the OS manufacturer), and often require larger system resources to compensate for being generic.
Linux offers a unique alternative to these three problems. By leveraging against the open source development of the Linux kernel and the GNU POSIX APIs and OS structure, licensing costs for the OS can be considerably less per device (if you pay any licensing costs at all), simply because the licensing isn't priced to recover the hundreds of thousands of man hours put into developing Linux and the GNU toolchain. This can potentially turn a software cost of tens of dollars per unit into a few dollars per unit. When dealing with high volumes of product, this savings can be quite considerable.
The Linux kernel can most certainly be optimized. Whether your organization optimizes the kernel itself (and you will have the kernel source code, thanks to the GPL) or if you pay another organization to do it, you won't find yourself staring at a kernel that is a black box. And make no mistake... you will need to optimize the kernel in some manner for your embedded platform. Many companies choose to leverage their savings on OS licensing costs towards kernel customization costs (i.e. spend less money on the OS and spend more making it BETTER). Also, if you are using Linux as an OS, you aren't left "holding the bag" if your embedded OS manufacturer goes out of business. Switching OSs can be an extremely costly process because it precipitates a porting processes of the embedded software as well.
A generic Linux kernel straight out of a RedHat distribution will, as Mr. Ganssle has stated, require too many resources of an embedded device. That is why customization work is needed. The core of the kernel (memory management, process management, etc.) needs to be customized, and other portions of the kernel can be removed entirely in order to perform the needed optimizations. You certainly wouldn't want to put Windows 2000 on a simple embedded device... the required hardware resources would most likely be inflated in order to support the OS. In the same way, you wouldn't use a generic Linux kernel.
The Linux embedded space is poised to explode in the near future, and I'm glad to see it happening. The Linux kernel lends itself well to customization, and the GNU toolchain offers a low-to-no cost alternative to expensive development tools, such as Tornado (VxWorks) or Microsoft Visual Studio. All in all, it looks like a bright future for the penguin.
Hello everyone. My name is Andrew Henderson, and I have been the lead programmer on SMAC/SMACX at Loki. I've seen from many of the posts that there is some enthusiasm over the Loki port of Alpha Centauri, and I'm very glad to see it. This project has been stealing our evenings and weekends for quite some time now, and I'm glad to finally see it come to a close.
There are a few things that I think anyone interested in this port of Sid Meier's Planetary Pack should know:
1. A PPC port is very unlikely.
I'd like to apologize to all the PPC users out there. I'd love to see SMAC on the PPC platform, but there is just too much involved in moving our codebase from Intel to PPC. There are roughly 25,000 lines of Intel assembly in SMAC, making the convertion a major undertaking. SMAC has specialized asm blitters for sprites, self-modifying asm for rendering the voxel vehicle units, and a complete asm texture mapping engine for rendering the landscapes. The costs in terms of both manpower and time in doing a PPC port are very steep.
2. SMAC/SMACX will most likely run on FreeBSD.
While it is not officially supported, we have gotten beta versions of SMAC to run on a FreeBSD box that has the Linux compatibility kernel module installed. If you have a FreeBSD box and would like to try out the SMAC/SMACX demo, I encourage you to download it. There is a good possiblity it will run for you.
3. Many bugs in the Win32 version of SMAC and SMACX have been fixed in the Linux version.
Well over a hundred bugs that were in the Win32 version have been fixed in the Linux version. For those people that want justification for purchasing the Linux version if they already have the Win32 version, here it is. This leads me to my last point:
4. The Linux/*BSD communities have some of the best beta testers out there.
I have to admit that I'm very impressed with the quantity and quality of bug reports Loki has received during the beta process of porting the game. Our beta testers were very persistant in finding and reporting bugs. The beta folks were an invaluable help in porting the game, and I'd like to thank them for their incredible time and effort.
All in all, I'd judge the port of Sid Meier's Planetary Pack a success. The programmers had fun, the beta testers had fun, and I hope that whoever tries out the demo of the game will enjoy it.
After all, we're all in this for the fun, aren't we?
I made a conditional offer yesterday with a limit of $30, thinking that was padded rather generously, and wired money from my bank to E*Trade to precisely cover the desired shares at this limit.
Good move. Plan on a buffer amount of money in your account. This buffer should typically be on the order of $10/share higher than the high end of the IPO price range for the stock you want to buy. Then, when the IPO price gets bumped up, you aren't up the creek.
If my limit ends up being below the intial share price, am I just plain screwed, or will I have the opportunity to revise my offer? Likewise if I get chosen as "in" but my offer is above the actual price...will there be an opportunity to add more shares?
Once the initial two-hour IPO window at E-Trade passes, you can't increase the number of shares you want to buy. You can, however, decrease the number of shares. Also, when the price range is increased, you are required to go back to the IPO section at E-Trade and reconfirm your offer even if your offered share price still is at or above the new IPO price. If you don't, you are skipped in the selection lottery.
On a side note, be sure that the money required to pay for your IPO stock is in your account by roughly 6:00 PM EST the night before the stock goes public. This avoids a lot of problems that might crop up, so sell any stock that you need to before the close of the market at 4:00 PM the day before the IPO stock hits the market.
Everyone seems to be quite anxious to jump on the IPO bandwagon to make a quick buck, but get mad when the system (E-Trade in particular) does things that seem unfair. There are a few things to keep in mind when dealing with IPOs:
1. A company can raise its initial offering price. Period. If you are serious about investing, you'll have to have a respectable sum to invest in the first place. Since you have to buy stocks in blocks of 100 (yes, your trade of 37 shares of stock is matched up with someone else's 63 shares thanks to modern technology), plan to have enough cash on hand to buy at least 200 shares. That way, if the range increases, you can still buy a block of 100 shares and use any remaining money to pay for an odd amount of shares when the stock hits the market. It takes money to make money, and IPOs often raise their price ranges when there is a large amount of interest. Which leads into...
2. A quick bit of advice is to avoid IPOs that lower their ranges. Another tip-off to an IPO you might want to avoid is one that extends the time period of their IPO because a small amount of IPO shares have been allocated and the rest is still waiting for a buyer. After all, the price of IPO stock is initially driven up by the demand of everyone wanting to buy their share of the sure-fire performing stock.
3. E-Trade is not a brokerage firm... at least not in the traditional sense. They aren't obligated to call you and let you know that you need to reconfirm your IPO bid (though they will try to contact you through as many as 5 different e-mail addresses). You need to stay glued to E-Trade the two days prior to when the stocks initially hits the market. The first day is to catch that two-hour window with E-Trade to get in your IPO bid for the stock in the first place, and the second day is to reconfirm your IPO bid (which, unfortunately, happens quite often with the good stocks).
4. With E-Trade, make sure you read their IPO readme. Also, feel free to call E-Trade directly at 1-800-STOCKS5 to get the scoop from a real person. It will be about a 30 minute wait in the hold queue, so be patient.
5. Those 100 share block-o-stocks are delegated by a lottery system when there is more interest than supply for an IPO stock. Even if you have the money set aside to purchase stock, you may not get it. It really is the luck of the draw in some cases.
Nobody ever said IPOs were an easy way to get money, only a quick way. Still, the payoffs are worth a little time spent in preparation. Take some time to learn the system before trying to jump into the deal of a lifetime and you'll end up with much better results.
Loki Hack has made an example of the improvements that can be found by releasing code as open-source. Large software shops aren't just going to turn over their code bases to the masses, so what's a good middle-ground?
Beta-testing.
A software company has their typical beta testing list of folks who use a piece of software over and over to try to ferret out any defects in the program's logic and functionality. Perhaps by picking a small subset of the beta-test group and supplying them with the code, you'll result in a nice hybrid between open-source and locked-down-source.
The "beta-coders" could evaluate software for bugs, then offer suggestions to fix those problems by examining the code and attaching the beta program to a debugger. Also, extra features could be suggested (as well as suggestions on how to implement those features).
Perhaps Loki just hinted at the future of the beta-testing environment: 20 game players with good coding and troubleshooting skills go on the rampage for 48 hours to produce a better project.
Beats the hell out of filling out beta-test reports and mailing them in;>
1. Drove from Daytona Beach, FL to Atlanta and back: Three tanks of gas @ $15.00 per tank.
2. Used the single hotel room reserved by Loki: Free.
3. Ate meals provided by Loki: seven meals @ about $6.00 per meal (certainly more than that, being from a hotel).
4. All the snacks and soda you could pack down: $15 (being VERY conservative).
5. Two free T-shirts: $25.
6. Three day pass for ALS: $300.
Total money spent: $45.00 Total value gained: $382.00
Not even counting the free software and prizes given to the contestants, I would hardly say we were working for "free". Besides, most of the practical knowledge gained from the event goes a bit towards increasing your earnings potential, now doesn't it?
When I signed up for Loki Hack, I figured I had no chance in hell of being selected to go. Something like this, it seems, would be seen as just an opportunity for programmers to gain visibility, allow Loki and Activision some free advertising, and give CivCTP a boost in sales ("Free mods done by real open source programmers!"). I found out that this was quite far from the truth when I was selected to go.
The first few hours of the competition were spent scanning the 500,000+ lines of C++ of CivCTP, with little said between the contestants. Then we all began talking to each other to see if someone had seen some object or another anywhere during their travels through the code base. Before you knew it, it wasn't a competition any more. It was a big knowledge swap meet.
Why did we all sign up? I don't know. My personal reasons were a chance to check out the structure of a commercial game and also to get a chance to meet the other folks who had more experience than me. I only really wanted to learn more about game programming. After all, I think just about every coder has the deep-down desire to create games, right?
Perhaps Loki gained some free advertising from the event. I can tell you from being there that extra press was a necessary side-effect. The Loki staff were more interested in talking to the contestants. Was this for the screening of potential Loki coders? Perhaps. Was it for learning more about different areas of code development we weren't that familiar with. Most certainly. If you even made mention of some topic of programming or of a particular library that others weren't familiar with, you suddently found that you had an audience of 5-10 people, hanging-off your every word and wanting to learn more.
Just about everyone there was an expert in some area. Just a quick glance showed people that were very high in the food chain in many open source projects: Clanlib, GGI, GCC, and many others. Were they there to get more their names plastered all over press releases? They didn't need it. They were already well-known within the Linux community.
I had the opportunity to talk to several other of the programmers there, as well as with Loki's staff. It wasn't the lure of job offers or being mentioned on Slashdot (;> ) that drives these folks. Its the idea that more than one viewpoint produces a better final result. Which, last I checked, was one of the big reasons for open source in the first place.
While it was true that testing of our hacked code wasn't very robust, it wasn't meant to be. Loki and Activision aren't going to just scoop up our code, merge it together, and then repackage it to sell another million copies. Some features that we developed may be taken under consideration by Activision for a later Civ release, but it would be the concepts that we created, not our code.
I'm afraid that people have gotten the notion in their heads that this whole event was a chance for Loki to grab the spotlight, Activision to make some money, and a few hackers to be abused by some corporate machine. Far from the truth. It was a chance for Loki to use their leverage to let the open source movement to gain some steam and for some talented folks to show Activision that open source works. The result was a resounding success.
... and I think I learned more about "real-life" coding in 48 hours than I did in four years of college;>
Slashdot Mirror
Some of it, of course was Open Source (Who's hosting that now, BTW?)
SDL (as well as several SDL utility libraries) can be found over at libSDL.org. A number of the open source software libraries and tools that Loki employees and community members developed can be found at icculus.org. I believe some projects are hosted at neither of those sites. Those can most likely be found at seul.org.
Loki purchased the rights to publish a Linux version of Win32 software titles. Loki essentially was selling software and paying a small royalty to the original owner of the software rights. So, when Loki folded, most of the Linux titles simply went back to the companies that the Win32 versions of the software came from. Kohan: Immortal Sovereigns went back to Timegate Studios. SMAC went back to Firaxis. And so on. If you want those titles supported now, talk to the company that originally created the game title.
Some of the publishing deals were a little more. Unreal Tournament, for instance, was just a contract with Epic to provide support for the Linux version of the game. In those deals, Loki was only providing a service.
So, for the idiots that keep saying that Loki should release all of it's game code to the community as a gesture of goodwill... wake up. That's like licensing the Quake III engine from iD and then releasing it open source to whomever wants it. It's a naive and mistaken path of thought to take.
As for the IP rights of the trademarks that Loki owns (such as the OpenAL trademark, web domain, etc.), those will be auctioned off in order to pay Loki's debts.
Andrew
What were they buying for $350K??? Sounds like a lot of Aeron chairs and BMWs to me.
When I worked at Loki, I sat in a $89 chair and drove a Dodge Neon. People don't seem to realize that $350K is not an unreasonable amount of money to spend in running a publishing business. Have you ever seen what rent is like for office space in southern California? How about telephone bills for the company? Electric bills (air conditioning)? Payroll? Printing and design expenses for the software packaging? Trade show booth space/travelling expenses? Bandwidth costs for the FTP, web servers, and CVS server? How about the bandwidth for the Bugzilla bug tracking database? Or the Loki newsgroups?
The one frivilous thing I can think of that Loki purchased was a Terminator 2 pinball machine that Scott Draeker, Andy Mecham (the head of QA), and myself found at an arcade machine auction for about $2000 or so.
People seem to think that because they could get a dozen people together in someone's basement and form a company that every company should have the same minimal overhead if they are "efficient". That's hardly the way business works. Unless you've seen the actual numbers of the budget of a real publishing company, please don't assume that expenses of $350K is so outrageous.
Try taking the budget of Interplay or Electronic Arts and scaling it down to the size of Loki. I think you'll find that $350K is pretty darn cheap.
Andrew
Reading Mr. Ganssle's view in the article on utilizing Linux as an embedded OS has really suprised me. I'm afraid that I'll have to disagree with his opinion on the issue simply because I actually have hands-on experience utilizing Linux within the embedded space. I've found that the Linux OS is a natural match to embedded platforms because the kernel and POSIX APIs of the OS can be customized in an intelligent manner to meet the size and processing requirements of a number of projects.
Most engineers that are shopping for an embedded OS want an "out of the box" solution for their embedded device. They want to simply be able to pay X number of dollars and get an OS so that they can quickly move on with their embedded software development. "Generic" embedded OSs, such as WinCE, are indeed a quick fix to that problem. Those same "generic" solutions also lock your project into continous OS licensing costs for the lifecycle of the project, a kernel that can't be touched for optimization (at least, not without paying a hefty fee to the OS manufacturer), and often require larger system resources to compensate for being generic.
Linux offers a unique alternative to these three problems. By leveraging against the open source development of the Linux kernel and the GNU POSIX APIs and OS structure, licensing costs for the OS can be considerably less per device (if you pay any licensing costs at all), simply because the licensing isn't priced to recover the hundreds of thousands of man hours put into developing Linux and the GNU toolchain. This can potentially turn a software cost of tens of dollars per unit into a few dollars per unit. When dealing with high volumes of product, this savings can be quite considerable.
The Linux kernel can most certainly be optimized. Whether your organization optimizes the kernel itself (and you will have the kernel source code, thanks to the GPL) or if you pay another organization to do it, you won't find yourself staring at a kernel that is a black box. And make no mistake... you will need to optimize the kernel in some manner for your embedded platform. Many companies choose to leverage their savings on OS licensing costs towards kernel customization costs (i.e. spend less money on the OS and spend more making it BETTER). Also, if you are using Linux as an OS, you aren't left "holding the bag" if your embedded OS manufacturer goes out of business. Switching OSs can be an extremely costly process because it precipitates a porting processes of the embedded software as well.
A generic Linux kernel straight out of a RedHat distribution will, as Mr. Ganssle has stated, require too many resources of an embedded device. That is why customization work is needed. The core of the kernel (memory management, process management, etc.) needs to be customized, and other portions of the kernel can be removed entirely in order to perform the needed optimizations. You certainly wouldn't want to put Windows 2000 on a simple embedded device... the required hardware resources would most likely be inflated in order to support the OS. In the same way, you wouldn't use a generic Linux kernel.
The Linux embedded space is poised to explode in the near future, and I'm glad to see it happening. The Linux kernel lends itself well to customization, and the GNU toolchain offers a low-to-no cost alternative to expensive development tools, such as Tornado (VxWorks) or Microsoft Visual Studio. All in all, it looks like a bright future for the penguin.
Hello everyone. My name is Andrew Henderson, and I have been the lead programmer on SMAC/SMACX at Loki. I've seen from many of the posts that there is some enthusiasm over the Loki port of Alpha Centauri, and I'm very glad to see it. This project has been stealing our evenings and weekends for quite some time now, and I'm glad to finally see it come to a close.
There are a few things that I think anyone interested in this port of Sid Meier's Planetary Pack should know:
1. A PPC port is very unlikely.
I'd like to apologize to all the PPC users out there. I'd love to see SMAC on the PPC platform, but there is just too much involved in moving our codebase from Intel to PPC. There are roughly 25,000 lines of Intel assembly in SMAC, making the convertion a major undertaking. SMAC has specialized asm blitters for sprites, self-modifying asm for rendering the voxel vehicle units, and a complete asm texture mapping engine for rendering the landscapes. The costs in terms of both manpower and time in doing a PPC port are very steep.
2. SMAC/SMACX will most likely run on FreeBSD.
While it is not officially supported, we have gotten beta versions of SMAC to run on a FreeBSD box that has the Linux compatibility kernel module installed. If you have a FreeBSD box and would like to try out the SMAC/SMACX demo, I encourage you to download it. There is a good possiblity it will run for you.
3. Many bugs in the Win32 version of SMAC and SMACX have been fixed in the Linux version.
Well over a hundred bugs that were in the Win32 version have been fixed in the Linux version. For those people that want justification for purchasing the Linux version if they already have the Win32 version, here it is. This leads me to my last point:
4. The Linux/*BSD communities have some of the best beta testers out there.
I have to admit that I'm very impressed with the quantity and quality of bug reports Loki has received during the beta process of porting the game. Our beta testers were very persistant in finding and reporting bugs. The beta folks were an invaluable help in porting the game, and I'd like to thank them for their incredible time and effort.
All in all, I'd judge the port of Sid Meier's Planetary Pack a success. The programmers had fun, the beta testers had fun, and I hope that whoever tries out the demo of the game will enjoy it.
After all, we're all in this for the fun, aren't we?
Andrew Henderson
Programmer
Loki Software
I made a conditional offer yesterday with a limit of $30, thinking that was padded rather generously, and wired money from my bank to E*Trade to precisely cover the desired shares at this limit.
Good move. Plan on a buffer amount of money in your account. This buffer should typically be on the order of $10/share higher than the high end of the IPO price range for the stock you want to buy. Then, when the IPO price gets bumped up, you aren't up the creek.
If my limit ends up being below the intial share price, am I just plain screwed, or will I have the opportunity to revise my offer? Likewise if I get chosen as "in" but my offer is above the actual price...will there be an opportunity to add more shares?Once the initial two-hour IPO window at E-Trade passes, you can't increase the number of shares you want to buy. You can, however, decrease the number of shares. Also, when the price range is increased, you are required to go back to the IPO section at E-Trade and reconfirm your offer even if your offered share price still is at or above the new IPO price. If you don't, you are skipped in the selection lottery.
On a side note, be sure that the money required to pay for your IPO stock is in your account by roughly 6:00 PM EST the night before the stock goes public. This avoids a lot of problems that might crop up, so sell any stock that you need to before the close of the market at 4:00 PM the day before the IPO stock hits the market.
Everyone seems to be quite anxious to jump on the IPO bandwagon to make a quick buck, but get mad when the system (E-Trade in particular) does things that seem unfair. There are a few things to keep in mind when dealing with IPOs:
1. A company can raise its initial offering price. Period. If you are serious about investing, you'll have to have a respectable sum to invest in the first place. Since you have to buy stocks in blocks of 100 (yes, your trade of 37 shares of stock is matched up with someone else's 63 shares thanks to modern technology), plan to have enough cash on hand to buy at least 200 shares. That way, if the range increases, you can still buy a block of 100 shares and use any remaining money to pay for an odd amount of shares when the stock hits the market. It takes money to make money, and IPOs often raise their price ranges when there is a large amount of interest. Which leads into...
2. A quick bit of advice is to avoid IPOs that lower their ranges. Another tip-off to an IPO you might want to avoid is one that extends the time period of their IPO because a small amount of IPO shares have been allocated and the rest is still waiting for a buyer. After all, the price of IPO stock is initially driven up by the demand of everyone wanting to buy their share of the sure-fire performing stock.
3. E-Trade is not a brokerage firm... at least not in the traditional sense. They aren't obligated to call you and let you know that you need to reconfirm your IPO bid (though they will try to contact you through as many as 5 different e-mail addresses). You need to stay glued to E-Trade the two days prior to when the stocks initially hits the market. The first day is to catch that two-hour window with E-Trade to get in your IPO bid for the stock in the first place, and the second day is to reconfirm your IPO bid (which, unfortunately, happens quite often with the good stocks).
4. With E-Trade, make sure you read their IPO readme. Also, feel free to call E-Trade directly at 1-800-STOCKS5 to get the scoop from a real person. It will be about a 30 minute wait in the hold queue, so be patient.
5. Those 100 share block-o-stocks are delegated by a lottery system when there is more interest than supply for an IPO stock. Even if you have the money set aside to purchase stock, you may not get it. It really is the luck of the draw in some cases.
Nobody ever said IPOs were an easy way to get money, only a quick way. Still, the payoffs are worth a little time spent in preparation. Take some time to learn the system before trying to jump into the deal of a lifetime and you'll end up with much better results.
>
Beta-testing.
A software company has their typical beta testing list of folks who use a piece of software over and over to try to ferret out any defects in the program's logic and functionality. Perhaps by picking a small subset of the beta-test group and supplying them with the code, you'll result in a nice hybrid between open-source and locked-down-source.
The "beta-coders" could evaluate software for bugs, then offer suggestions to fix those problems by examining the code and attaching the beta program to a debugger. Also, extra features could be suggested (as well as suggestions on how to implement those features).
Perhaps Loki just hinted at the future of the beta-testing environment: 20 game players with good coding and troubleshooting skills go on the rampage for 48 hours to produce a better project.
Beats the hell out of filling out beta-test reports and mailing them in ;>
1. No showing of the code to anyone for five years (no printouts).
2. ALL code seen during the competition may be discussed with anyone. So, if you want to know what is inside CivCTP, just ask someone who went.
3. ANY knowledge gained by a programmer by looking at Activision/Loki's code may be used for that programmer's IMMEDIATE monetary gain if desired.
Hardly a standard corporate NDA, hmmmm? ;>
Andrew Henderson
Runner-Up, Loki Hack '99
1. Drove from Daytona Beach, FL to Atlanta and back: Three tanks of gas @ $15.00 per tank.
2. Used the single hotel room reserved by Loki: Free.
3. Ate meals provided by Loki: seven meals @ about $6.00 per meal (certainly more than that, being from a hotel).
4. All the snacks and soda you could pack down: $15 (being VERY conservative).
5. Two free T-shirts: $25.
6. Three day pass for ALS: $300.
Total money spent: $45.00
Total value gained: $382.00
Not even counting the free software and prizes given to the contestants, I would hardly say we were working for "free". Besides, most of the practical knowledge gained from the event goes a bit towards increasing your earnings potential, now doesn't it?
Andrew Henderson
Runner-Up, Loki Hack '99
The first few hours of the competition were spent scanning the 500,000+ lines of C++ of CivCTP, with little said between the contestants. Then we all began talking to each other to see if someone had seen some object or another anywhere during their travels through the code base. Before you knew it, it wasn't a competition any more. It was a big knowledge swap meet.
Why did we all sign up? I don't know. My personal reasons were a chance to check out the structure of a commercial game and also to get a chance to meet the other folks who had more experience than me. I only really wanted to learn more about game programming. After all, I think just about every coder has the deep-down desire to create games, right?
Perhaps Loki gained some free advertising from the event. I can tell you from being there that extra press was a necessary side-effect. The Loki staff were more interested in talking to the contestants. Was this for the screening of potential Loki coders? Perhaps. Was it for learning more about different areas of code development we weren't that familiar with. Most certainly. If you even made mention of some topic of programming or of a particular library that others weren't familiar with, you suddently found that you had an audience of 5-10 people, hanging-off your every word and wanting to learn more.
Just about everyone there was an expert in some area. Just a quick glance showed people that were very high in the food chain in many open source projects: Clanlib, GGI, GCC, and many others. Were they there to get more their names plastered all over press releases? They didn't need it. They were already well-known within the Linux community.
I had the opportunity to talk to several other of the programmers there, as well as with Loki's staff. It wasn't the lure of job offers or being mentioned on Slashdot ( ;> ) that drives these folks. Its the idea that more than one viewpoint produces a better final result. Which, last I checked, was one of the big reasons for open source in the first place.
While it was true that testing of our hacked code wasn't very robust, it wasn't meant to be. Loki and Activision aren't going to just scoop up our code, merge it together, and then repackage it to sell another million copies. Some features that we developed may be taken under consideration by Activision for a later Civ release, but it would be the concepts that we created, not our code.
I'm afraid that people have gotten the notion in their heads that this whole event was a chance for Loki to grab the spotlight, Activision to make some money, and a few hackers to be abused by some corporate machine. Far from the truth. It was a chance for Loki to use their leverage to let the open source movement to gain some steam and for some talented folks to show Activision that open source works. The result was a resounding success.
... and I think I learned more about "real-life" coding in 48 hours than I did in four years of college ;>
Andrew Henderson
Runner-Up, Loki Hack '99