The Open Source Game Experiment….
Open source projects are an interesting thing. You work with developers you will likely never meet in person. Not too different than some of the professional projects I’m involved with. However, when building an open source video game, things like age differences, time differences, language barriers, and a multitude of other barriers come into play. A Video game is particularly difficult, as a game can take years to develop and your average gamer gets a game and plays it for a month or two and then is onto the next greatest thing. Keeping interest in such a long term project in both the developers and the intended audience can be quite a challenge. I get the impression that other sorts of open source software projects have the luxury to evolve more naturally. With a video game, if you spend 3 years in the making, you can expect video game technology in general to improve 10 fold for each year of development. This means that when you finally have your 1.0 release it's already 30 internet years behind. That makes it hard to hold the interest of an average gamer, who has watched dozens and dozens of games go from announcement to release all with superior tech behind them. (Not to mention a full time staff creating them.)
Like many open source projects, it’s unlikely you have a sponsor and you’re putting in hundreds of hours of work for free, in hopes that it will turn into something people enjoy. Again, at least a piece of software will find some usefulness with someone, somewhere. A game on the other hand either will or will not be played by the masses.
Anyhow, without further ado, I present the unfinished product. Trepidation, an open source first person shooter which has been shelved for almost 5 years.
While I'm not the person to go through and build the gfx and 3d models, I did go through and fix about 3 dozen bugs in the code. The master server has been running for almost 6 years, with no plans of going down soon. If interest is generated in this project, I would consider pursuing it further, otherwise - here is what we had. The source code is available via subversion (see the site).
Here is a quick video highlighting the weapons (a work in progress). Visit the website here: http://trepidation.u7net.com
You can download the game here: http://trepidation.u7net.com/downloads/?cat=1
About Trepidation:
Trepidation is an open source first person shooter based on the IOQuake3 engine. Trepidation was a project originally conceived on April 9, 2006 with the intent to build a free first person shooter with a sci-fi theme. The idea was initially developed by members of the Star Trek Elite Force gaming community. The project disbanded before the game was complete sometime in 2008.
The game includes:
- 16 multiplayer levels (maps). Many quake 3 maps have also been tested and work with the game.
- An original soundtrack featuring 10 original tracks.
- 6 Game Modes.
- In game Voice Over IP Support (VOIP)
- All New Weapons
- Instagib Modifier Available On Most Game Modes.
The Game Modes included are :
Trepidation:
A Team based game where the object is to destroy the other team’s power core Various defensive structures can be built to protect your base and achieve your goal. While this game employs strategy it is extremely fast paced and teamwork is a must.
Deathmatch:
You see them, you kill them.
Team Deathmatch:
Same as Deathmatch but your not solo.
CTF
Classic capture the flag action with the ability to build gun turrets (if enabled) to help defend your base.
Survival:
A last man standing game mode similar to Elite Force’s Gladiator.
Arsenal:
You get some select weapons, don’t lose them or your out.
iPhone App: FTP Server
There are a few different apps in the app store that turns your iPhone into a storage device. I find this one pretty convenient.

Sick of carrying around a memory stick to transport your files? This could be a simple solution. If you'd like to take advantage of all of the space on your iPod touch or iPhone, and don't usually carry your cable around with you this app may be for you. This app turns your iPhone into a simple FTP server that you can anonymously login to over WiFi and transfer files to and from your phone. There isn't a lot to this app, there are no options, just a simple ftp server with no authentication. When you run the server you are given a console screen that will display the IP address that you will use to login with your favorite ftp client.
On a security note, be sure to use this app on WiFi networks that you trust and don't leave the server running when you don't need it, as there is no authentication and diddyftpserver has some known Ddos vulnerabilities.
Check it out @ http://itunes.apple.com/us/app/ftp-server/id356055128?mt=8
TweetDisplaying a subversion commit log with PHP

I was recently tasked with a small project that had to pull commit logs from various subversion servers and repositorys and display them on a web page.
The process was a lot simplier than I first anticipated. Hopefully someone else will find this useful. This php code snippet requires that the server have SHELL_EXEC() enabled and subversion must be installed. We'll use the SHELL_EXEC() function to actually use the subversion cli to grab the commit log from a remote server and store it in an xml file.
I'll break down the code a bit. This first bit, is a simple helper function that will help us read the XML file itself. We call the function xml_atrribute().
function xml_attribute($object, $attribute)
{
if(isset($object[$attribute]))
return (string) $object[$attribute];
}
Next up is to actually run the subversion CLI client with all of the correct parameters to generate an xml file of the commit log. You will want to adjust the server, username, password, repository name and output path to meet your needs.
$test = shell_exec("svn log --xml --verbose svn://svn.mydomain.com/reponame --username USERNAME --password PASSWORD > /home/html/svnlog/reponame.xml ") ;
Alright, at this point we should have a nicely formatted XML file that we can read, loop through and display information from. Here is a simple bit that loops through the various XML elements and displays them. As commented we go one step further than just reading the commit comments, we actually display the files and what action was performed on them.
foreach ($xml->logentry as $logentry)
{
$date = date('m/d/Y', strtotime((string) $logentry->date));
foreach ($logentry->paths as $paths)
{
echo ' <BR><B>Revision: ' . xml_attribute($logentry, 'revision') . '</B>';
echo ' <BR>Date: ' . $date;
echo ' <BR>Message: ' . $logentry->msg;
echo ' <BR>Commited By: ' . $logentry->author;
echo ' <BR> ' ;
/* Now lets loop through and get a
list of files that have changed
in this commit */
echo '<UL>';
foreach ($paths->path as $path)
{
echo "
<li>" . $path['action'] . " " . $path . "</l1>";
}
echo '</UL>';
}
}
Here is the entire script all put together and commented:
<?php
/* This is a helper function
to aid in reading our XML
file we are going to create */
function xml_attribute($object, $attribute)
{
if(isset($object[$attribute]))
return (string) $object[$attribute];
}
/* Run SVN to get an xml file
of the commit log.
SHELL_EXEC() must be enabled
on the server.
*/
$test = shell_exec("svn log --xml --verbose svn://svn.mydomain.com/reponame --username USERNAME --password PASSWORD > /home/html/svnlog/reponame.xml ") ;
/* Pull the XML file in */
$xml = simplexml_load_file(dirname(__FILE__).'/reponame.xml');
/* now lets roll through the XML and display the results */
foreach ($xml->logentry as $logentry)
{
$date = date('m/d/Y', strtotime((string) $logentry->date)); // format the date
foreach ($logentry->paths as $paths)
{
echo ' <BR><B>Revision: ' . xml_attribute($logentry, 'revision') . '</B>';
echo ' <BR>Date: ' . $date;
echo ' <BR>Message: ' . $logentry->msg;
echo ' <BR>Commited By: ' . $logentry->author;
echo ' <BR> ' ;
/* Now lets loop through and get a
list of files that have changed
in this commit */
echo '<UL>';
foreach ($paths->path as $path)
{
echo "
<li>" . $path['action'] . " " . $path . "</l1>";
}
echo '</UL>';
}
}
?>
It's worth noting that when we read in the XML file we assume it lives in the same directory as the script reading it does. You can adjust this as needed. I Hope this is helpful to anyone out there needing to do something similar. The full source is here: svnsample.zip.
12 Tips To Help You Communicate With Your Developers
I Don't usually blog just to reproduce another thing I already saw, hense the slowness in new post. But I keep going back to this one.. It could be because I haven't slept in two days or maybe I keep going back because it's perfect...
The article is here: http://blogs.sitepoint.com/12-tips-for-better-developer-communication/
I'll Feel bad for reprinting it all but here is the best of it:
As an internet business owner you’ll need to face your developers. Yes, it’s scary — they probably look odd and speak a weird language. But you can’t avoid it. Here are my 12 tips to help you communicate with your development team…
1. Know Your Requirements…
How can you explain your requirements if you don’t know what they are? Developers are often faced with vague, wishy-washy briefs such as “it needs to be just like Facebook, only — er — like, different”.A good developer will immediately begin to analyze your idea. They’ll ask questions. They’ll pose “what-if” scenarios. No one will expect you to have all the answers, but you should be able to discuss the majority of problems. If you can’t, you haven’t thought the project through. It’ll fail.
2. …and Document Them
Putting your requirements on paper may not be fun, but it’s necessary. Interface sketches and flowcharts will help you identify functionality, understand the technicalities and explain issues.Consider hiring a systems analyst if you can’t do this yourself. They’ll ask identical questions, though.
3. Don’t Use Pseudo Code
If you’re not a programmer, please, please don’t attempt to write pseudo code — it won’t help. You’ll almost certainly over-complicate the easy stuff and gloss over the complexities. Your developer will need to reverse engineer your ‘code’ to determine what you actually wanted to achieve.Pseudo code is useful when developers discuss algorithms with each other. There are few other reasons to use it.
4. Agile Programming is Not an Excuse for Poor Planning
Don’t think that rapid, agile software development excuses requirements analysis. It may reduce some of the up-front planning, but you’ll still need to make just as many decisions — if not more.5. Be Clear and Decisive
Programmers make thousands of decisions on your behalf. However, they will inevitably have questions during the development process and failing to providing a definitive answer will halt progress.As good manager, you’ll take responsibility, make a prompt decision, stick with it, and face the consequences if it’s wrong. Bad managers are unavailable, avoid answering the question, seek opinions from 57 other (disinterested) colleagues, then blame the developer for delays or bad decisions.
6. Stay Ahead of Your Developers
Good programming teams will have a development plan — components and features will be implemented in order. Understand that plan and prepare accordingly:
know what decisions need to be made prior to implementation
prepare dummy data or test cases
organize the production of content, graphics, videos or other media.7. Avoid Scope Changes
Changing scope can destroy a project and put a deadline at risk. You may have seen a cool feature elsewhere, but it doesn’t need to be implemented immediately.
By all means, have an informal discussion with your developer. State it’s something you’re considering for a later version — don’t distract them from the agreed tasks or demand immediate attention.8. Don’t Assume Anything
One of the worst statements made by non-developers is: “Hey, we should implement feature X. It’s easy, right — it’ll only take a few hours.”
It might take a few minutes. It might take months. It might be impractical. It might be technically impossible. You don’t know — if you did, you wouldn’t require a developer to implement it for you.9. Set Realistic Deadlines
Like anyone, developers work best when they have an agreed deadline. However, those deadlines should be set by the developer themselves or someone with programming abilities and in-depth technical knowledge of the system. Setting an arbitrary or unrealistic deadline will result in a bug-ridden monstrosity which takes far longer to fix.10. Alter Your Schedule When Necessary
Application development is complex. Development estimates are just that — estimates. Programmers will encounter unforeseen problems and changes to the project scope (no matter how hard you try to avoid them).The schedule will inevitably change as the project progresses. Do not be afraid to modify the completion date accordingly.
11. Test Your Own Application
Don’t rely on your developers or other people to test your application. It’s your vision: test it yourself at every opportunity.That said, be aware you may be running unfinished code and check progress against the development schedule. Don’t send emails ranting about feature Y not working when that code hasn’t been started.
12. Stay Involved and Keep Communicating
Most people lose interest in their own projects as time goes on. If you can’t remain enthusiastic, don’t expect it from others.Contact your developers on a regular basis. You don’t necessarily need to organize formal progress meetings — just show your face and ask how things are going.
That said, avoid pestering them. Your project won’t be completed quicker if you call your developer every 10 minutes to ask “are we there yet?” Let your developer do their job.
Ok maybe that is all of it but it is awesome, and you should read all of Craig Buckler's other stuff...
::Awaiting DMCA takedown notices::
TweetThe Commodore 64 is Back!
Thats right, the machine that made home computer history in 1982 is coming back. Commodore had quite a history starting back in 1954, but never really hit it big until the early 80s when they managed to bring affordable personal computers into peoples living rooms. Personally my very first computer was a Commodore Vic 20, released in 1980. It had a full 5kb of Ram (The machine I'm writing this on now has 5242880kb of Ram. This was my first computer sending me into the world I live in today.
A few years later in 1982 Commodore released the Commodore 64 featuring a full 64k of ram for under $600. The price alone led it to be one of the top selling personal computers of the decade.
Commodore remained top of their game for for a good 5 or 6 years until IBM Clones and Apple machines took over the consumer space. Finally in 1994, Commodore was forced to declare bankruptcy.
The Commodore brand changed hands a multitude of times after their liquidation and various reboots of the brand as well as the Amiga where attempted with varying levels of success. In April, 2010, Barry Altman founded Comodore USA, LLC. Oddly, Barry's background isn't in Tech, but in furniture. Which has to make me wonder if this reboot is going to be like many of the other Commodore reboots and fizzle before it gains any momentum.
The company's about us page says "We are Commodore and AMIGA fanatics, just like many of you. We ask ourselves what could have been, and we are appalled by Apple revisionism. Commodore is back, and we're determined to bring the much loved brand back to the mainstream and restore its prominence in the tech industry to that which it richly deserves. It ain't over 'till we say so." which sounds promising, but only time will tell.
The new Commodore 64 is a modern day PC in a modified C64 Shell, with a handful of modifications. While it can run windows, the machine comes with the Commodore OS which is a custom blend of Ubuntu Linux. Apparently you are offered a boot menu that allows you to boot into the original C64 Basic 2.0 operating system. The machine comes with a lot of your standard PC components tucked away where you might have originally found the machine's I/O ports. The Commodore website claims the machine has 4gb RAM a far cry from the 64kb of the original as well as an Intel® Atom D525 1.80GHz processor. The full specs from the site read:
BACK PANEL CONNECTORS:
1 12V DC Jack
1 PS2 KB/Mouse connectors
1 HDMI
1 DVI-D
1 VGA
4 USB 2.0
1 RJ45 LAN (10/100/1000)
3 3.5mm Audio with S/PDIF out
MODEL: Commodore 64x
PROCESSOR: Intel® Atom D525 1.80GHz (Formerly Pineview-D)
CHIPSET: Intel NM10 (Formerly Tiger Point)
Next-Generation NVIDIA ION Graphics (ION2)
MEMORY: 2 x DDR2 667/800 Single Channel DIMM slots (up to 4 GB)
GRAPHICS: Next-Generation NVIDIA ION Graphics Processor
AUDIO: Realtek ALC662 6-CH HD Audio
Nvidia L-PCM digital audio (HDMI 1.3) can support 7.1 output with external decoder
LAN: Realtek RTL8111DL PCI-E Gigabit Ethernet
STORAGE: Intel NM10
2 SATA2 3Gb/s ports
JMicron® JMB362 SATA controller
2 Internal SATA2 3.0Gb/s port with RAID 0, 1, JBOD.
FEATURES:
- ACPI S3 Compliant
- ECO-design for EuP Standard
- 12 VDC jack on back panel for external power supply
- Dedicated DDR3 512MB Graphics Memory Onboard
- Premium DirectX 10 graphics with advanced digital display connectivity
- PureVideo™ Full 1080p HD video and Blu-ray playback
- NVIDIA® CUDA™ technology to accelerate the most demanding applications
- Premium Windows experience with Windows Vista and Windows 7
ONBOARD I/O
CONNECTORS:
1 mini PCI Express x1 Slot
1 Serial header (RS232)
4 SATA2 3Gb/s Connectors with RAID 0, 1, JBOD functions (SATA#3,#4)
2 USB Pin Headers for up to 3 additional USB 2.0 Ports
1 8 bit GPIO header
1 CIR header
1 9-pin Audio Connector
1 Front Panel Connector
3 Fan Headers
1 4-pin Power Connector
See more pictures and read more about the new C64 at the Commodore website @ http://www.commodoreusa.net/CUSA_C64.aspx.
If your suddenly feeling nostalgic and would to go back down memory lane -- you may want to have a look at Vice, an emulator for most all commodore models.








