Archive for September, 2010

F1 2010 lockup solution

September 27, 2010 2 comments

After playing my F1 2010 over the weekend and loving it, I was ready to spend my day off playing it today. However when I woke up I found that my game would no longer load, my PS3 would freeze constantly during startup.
After contacting Codemasters it appears it is my saved data that is corrupt, which apparently happens when performing a R&D test during practice. They gave me some tips to fix the issue and I wanted to share that email for those of you experiencing the same issues.

We have now identified that this only occurs if, after completing the objective, you…

– Retire to the paddock via the Engineer (in the garage).
– Terminally damage your car and select retire to paddock.
– Get disqualified and select retire to paddock.

As long as you progress to the qualifying session before quitting the game this problem will not occur.

They are working on a update that will fix this issues. They worked quickly to find the problem, when I originally emailed them I was told they couldn’t reproduce it however little over two hours later they had found how it was happening and responded with the aforementioned email. Hope this helps others out until the next update.

Categories: F1, Games, Support

Mud Engine + GUI = Mud Designer

September 27, 2010 Leave a comment

Yesterday i put together a quick UI for creating Rooms using the Mud Engine and liked how easy it was to access & use the engine. It’s come a long ways since my last GUI was developed on. I’ll spend today working on implementing a full UI for the designer & see about getting networking up and running within it as well. Shouldn’t take to much to get it done right.

Consoles vs PC’s

September 18, 2010 3 comments

I don’t know about you, but I love my game consoles. I don’t care if it’s my Playstation 3 or my GameCube, I can take refuge in the fact that even though the games I have sitting on my shelves are 6-10 years old, they’ll still work perfectly when I plug them in. Not so true with my PC.

Today I attempted to play Civilizations IV on my laptop that I had purchased several years back. I bought them on Direct2Drive & so when I tried to activate it I was given a nice little error message saying activation failed due to lack of Internet. Yeah. No duh. I just moved & haven’t managed to get Internet up & running. So I tried my CD of Galactic Civilization and found that stupid Windows Explorer would freeze each time auto-run tried to execute. Then I tried Playing my Half-Life 2 but ran into the lack of Internet issue for the Steam client. I gave up & returned to my PS3. It’s sad that even my PS3 can play my 15 year old PS1 games with out any issues but games on Windows suffer with compatibility issues after less than 5 or 6 years along with forcing Internet connectivity to even get certain games (singleplayer mind you) activated for play. This is why console sales are up and PC game sales are down. Go figure.

Time away = Delayed Updates

September 12, 2010 1 comment

Starting tomorrow I will be pretty busy for the next two months and those of you following the development of the Mud Designer engine won’t see any updates to the engine for a little while.

Tomorrow I begin moving into a new place and the earliest I see myself having internet is close to the beginning of October at which point I will be getting married as my wedding is on the 9th of October. I will spend some time working on the engine over the next couple of months, albeit not as much as I have been lately, but I won’t be able to upload any changes or releases until the internet is setup and my personal life has freed up some. The good side to this is that I will have plenty of time to write up some solid documentation for the new features coming in Alpha 2.0 and will also have a solid real-time world creation script set built and polished.

Thanks to my iPhone, I will be able to post updates via Twitter and here on my blog so keep an eye on them both if you’re wanting to track what changes are being made.
If Alpha 2.0 is finished and I have some free time, I might start work on a GUI based world editor to ship with it. We’ll have to wait and see how things go with the project before any GUI work begins.

Categories: Programming

Editable Environment Objects

September 12, 2010 2 comments

Prior to today, admin’s would need to re-enter a edit command (such as EditRoom) each time they changed a property on the object. If they changed a Realm’s description, the command would save and the editor would close, restoring the admin to the game world. That approach really made it annoying and time consuming when you wanted to build a bunch of Rooms, so I wanted to make it easier to use the editor without having to exit after each property value was updated.
The latest commitment to the source code repo now has a menu that does not close when the user changes properties on a object. The editor returns the user to the main menu for the editor, allowing them to continue on editing the object. When they are finished, they may choose menu option #9 which will close the editor and return the admin to the game.
On a side-note, I will need to look into addressing the fact that chat messages and character movement messages will still be printed to the admin, even while editing. While it’s not a critical thing to fix, it’s something I’ll look at over the next week. All of these commands will be scripted, so developers can modify their scripts if they want in some way to prevent the un-wanted messages.

I am thinking about launching the editors immediately after the create command has finished. Allowing the admin to start editing the object without having to enter a new command. For editing Rooms, this would help admins out quiet a bit, as typing out the fully qualified path of a Room (RealmName>ZoneName>RoomName) can get tedious and is prone to possible typo’s requiring the command to be re-entered. Creating the Room and then pragmatically invoking the edit command for that object would be a nice feature.

It’s pretty easy to pragmatically invoke a command during runtime. The easiest way to do so would be by accessing the player reference included in the Execute method parameter, but that takes over the players console, and can have some visual oddities. If the player is in the middle of typing something, and you hijack the player to invoke a command, the command will begin printing it’s results out to the player, beginning at the end of their current line of text like such:


BAD - Don't invoke commands directly by the player
as it causes issues for them client-side. Always invoke the command internally, passing
a reference to the player instead.


The ideal solution is to instance a reference to a existing command object located within the engines command system, and invoke it’s execute command, supplying the player as a parameter. This does not take over the player in any way, and invokes the command in a much better manor.


Good - Correct way of invoking commands automatically
for the player. The command will be executed for which ever player
is passed as a reference.
CommandLook look = new CommandLook(); look.Execute("look", player);


The last approach shown below is the best way to do it however.  Using the previous one relies on the fact that the script will always  exist. What happens if it doesn’t? The script will cause an exception due to CommandLook being non-existent. Using the following approach will provide a safe way to pragmatically invoke a command for the player due to IGameCommand being a internal part of the engine, thus it will always exist and is not dependent on any scripts existing.


IGameCommand look = CommandEngine.GetCommand("CommandLook");
if (look != null)
    look.Execute("look", player);


Note that any scripted command name must begin with Command and so you will need to supply that when using the static GetCommand method. If the command does not exist in the CommandEngine’s collection of commands, then the command is never invoked and no error is generated.

Categories: Programming

Managing a Open Source Team

September 6, 2010 4 comments

Over the years I’ve been part of several teams that had banded together to build various projects. Several short months later the projects were dead and the team was gone. What happened?

One of the more common issues that I have noticed is of people joining the project & then not understanding the technology. Not the internal team technology, but rather the development frameworks and languages used. In most cases, the team members would become frustrated that they couldn’t learn the language or framework at a fast enough pace to keep up with the rest of the development, or they just lacked interest in learning something new.

Another common pitfall is that team members assuming they could develop at their own pace, when they get a craving to crunch on some code they would go ahead and code, otherwise they would contribute nothing. This would leave the team hanging however, as people would let their workload pile up or pass it on to other people when it was asked of them to try and meet a deadline.

Lastly, my biggest pet-peeve and by far the most common, has been people joining a project and then going silent. They never respond to your emails nor do they contribute to the project in any way.

I’m retrospect, there were several things I should have done that would have prevented this from happening. When you advertise for positions within your open source team, it’s important to remember you’re not going to be paying these people, typically speaking. They’re not required to fulfill any part of their role in the team, but there are things you can do during the selection process that will help weed out some of the un-wanted members.

1: Make sure they understand their role and the tools your team is using.
2: give new members a simple task at first to help get them settled in.
3: Ask them how many hours they can contribute, realistically.
4: find out what they’ve done in the past and give them work that resembles their past experiences. Letting them start out in familiar ground will help keep their interests.
5: use a Project Management solution like Fellowstream to help give your team members some direction.
6: hold team conferences via a forum or chat system at least once a week to toss around ideas and keep peoples blood pumping.

Getting a team built using free help is often difficult, but the fact of the matter is that keeping the team together is the truly difficult part. If you can maintain a team on your project, you’ll make a good project manager.

Saving memories

September 5, 2010 Leave a comment

I spent some time looking at some of the projects I had worked on in the past and found myself wishing I had blogged more on them as I built them. It was cool going back and seeing how I had done certain things, the people I worked with and the content created.

The lack of blogging and lack of saved content created a void in my memory when I tried to remember various things about the project. It made me realize that even now, with all the note keeping tools I have available, I don’t keep a proper amount of notes, if for anything else, nostalgic purposes.

I have a iPhone app called Awesome Note that works great and I’ve used it in the past. It syncs with my Evernote account so I can save all of my notes in one place, across multiple platforms. I think it’d be cool to have a annual blog post devoted to what happened over the course of the year, and keeping better track of my work and daily events will help make that annual post idea a reality.

Categories: Blogging, History, Programming