Shafe Shifter Just another guy on the internet.

25Dec/110

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

Announcement From Website


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.

Tagged as: , , , No Comments
29Nov/110

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

Tagged as: , , , , , No Comments
9Nov/110

Time Tracking

A number of times clients ask how I track my time.  And each time I have to explain that I built some software specifically to meet my needs.    The software is a continual work in progress, the codebase is ancient and I hate working with it, although I still actively use it to track my time.   But, for those who are wondering here is a quick demo of what we use here at TNL Total Solutions.

I'm also going to make it available for download.  Just keep in mind, this was never intended for public consumption, some buttons don't do anything, there are annoying bugs that no one has gotten around to fixing and there is no documentation.  The demo above does explain how everything works (mostly).   Nonetheless, here is a copy of the current build for you to check out.

Download Link: Download TimeTrac v1.6

Cheers!
Brian

Tagged as: , , , , , No Comments
14Sep/110

Displaying a subversion commit log with PHP

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.

Tagged as: , , , , , No Comments
1Apr/110

12 Tips To Help You Communicate With Your Developers

This could be Your Developer

This could be your developer!

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::

Tagged as: , , , , , , , No Comments
   Older Entries »

Links

Latest Photos

Dog Halloween

Kennedy School

Dog Halloween

Oak Park Amusement Park

Haunted, Kennedy School

More Photos

Tag Cloud

80s animals apocalypse conspiracy customer service etc facebook favorites food g33k Gadgets gaming ghost town healthy homebrew home projects iPhone iPod Linux music Myspace oregon php programming relationships roller coasters sci-fi sex hair silly conservatives smoking social networking software time travel tnlsoft toys trepidation twitter Ubuntu vacations web development webseries

Categories

Stop SOPA