So, we were sitting around in the lunchroom talking, and came up with something that we think could be a really valuable change to a key method in the .NET framework (as well as in just about every other language). The name IsNumeric is misleading, because you would expect it to return true only if the value was truly a number, but as many know this is not really the case. As such, I have created a couple of other methods that may be suitable to replace it.

Public Function MostLikelyNumeric(ByVal Expression As Object) As Boolean
     Return IsNumeric(Expression)
End Function

Public Function PossiblyNumeric(ByVal Expression As Object) As Boolean
     Return IsNumeric(Expression)
End Function

Either of those seem like they are more descriptive….

To wrap up the day, the 5 “presenters” sat at the front of the room and allowed us to ask some questions (both stupid and not as stupid) to which they would have to try to provide answers to without looking stupid.

Rory graced us with his presence, and then proceeded to interrupt the introductions with his question. Once his question was answered, he promptly packed his bags and walked out. All the pressure of being famous I guess.

Most of the questions seemed to revolve around how to make money from game development, and most of the answers seemed to be “good luck, loser”. The panel did a good job of explaining that the game-dev market is very hard to break in to, and its quite difficult to publish your own games these days without a substantial chunk of cash. It was mentioned that the shareware model is still quite viable though, and can bring in a little bit of cash now and then.

The best thing is that there is one other person that seems to play Guild Wars. I think he may in fact be the only person that I have met face to face that plays this game. What a shame.

This session was a fun way to end the day.

Andy is a very interesting individual. He recently quit his job at Microsoft, and has decided to live on savings for a year while he tries to break into the gaming industry. Furthermore, if this doesn’t work out, he seems fairly confident that he can get re-hired by Microsoft. He must be good.

I was late to the after-lunch session yet again, due to the a bit of slow restaurant service. When I walked in Andy was knee deep in some stuff that was clearly over my head, and I was barely grasping at some of the concepts. I was relieved only by the fact that when he asked questions, everyone else was silent too.

Most of the presentation was getting down and dirty with HLSL. It was indeed impressive how little HLSL code could be written to insert lights, textures, etc into shader that could then be used to affect a scene. Andy stepped through re-creating the fixed function pipeline functionality of the graphics card (at least I think so, he kept saying things and then appending “…of course” onto the statement, making me feel a bit ignorant). In the end, he made it look rather simple, though I don’t think I could go and do it again on my own.

While the subject was a bit over my head, the presentation was excellent and enjoyable. Off to the Game Dev Panel.

This talk was one I was really looking forward to, as I find AI in games really fascinating. Chris certainly did not disappoint in another concept-based talk.

Much of the presentation focused on the different components of AI (Fear, Hunger, Morale, Loyalty, Greed, etc) and how they are created in reaction to stimuli around the creature. He explained how many more components may be thrown into AI to make it more interesting, such as contention between races, and how to calculate certain reactions based on different AI characteristics.

Chris has authored his own ASCII based RPG, Heroic Adventure using VB.NET. After some bad luck with his intended demo (which he warned us was not working as intended before unleashing it on us), he demonstrated some AI that was worked into his own game (after dying several times without leaving the first room).

This talk led to lunch and made for a very informative and fun morning.

I arrived promptly at 8:55 for this first Sunday session. There were now 3 of us in the room, and one of us was the presenter. Well, that’s what you get for being the first speaker after the “Nerd Crawl” that surely kept people out way later than the “I want to be up for Jason’s talk at 9:00 tomorrow” time. By the time we started the talk 5 minutes late, there were probably half a dozen people in the room. Lucky for me, I was one of the 2 that didn’t have David Weller’s book “Beginning .NET game programming in VB.NET”, so I received one of the 2 copies that were to be given away for that session.

This was probably my favorite talk. Jason has taken a unique approach to keeping separate components of his game informed of what other components are doing by using a central message processor. It was revealed that he hates using .NET events, and prefers his self-rolled message processing approach.

This approach allows each component to send messages to the message processor, which will in turn send them to all components that have subscribed to that particular type of message. By using this de-coupled architecture, it would be very easy to add additional components into the game, and allow them to hear the messages of the other components, without touching a single line of code in any of the other components. None of the components need to know what other components may be listening to its messages.

Jason concluded by showing us his own creation, tanks 0.0.3 very beta. He also talked briefly about hooking into a 3rd party physics engine to provide the physics for his project, and about using baretail for logging.

I think this was my favorite talk due to my general noobishness with DirectX, and the focus on concepts rather than specific examples. A great way to start the morning.

We were a few minutes late coming back from lunch, so I missed the first few minutes of this talk. Naturally I didn’t know what to expect here. As we ate lunch, there was quite a lot of speculation as to what type of talk this may be, and in fact what color the balls may be.

Jason’s talk mostly focused on physics and collision detection. His application consisted of a surface with some pool/striped balls that would drop from the sky at the whim of the user, and as they collided, cause a chain reaction which would send balls in all directions. Jason pointed out some of the roadblocks he had run into when trying to do collision detection in 3 dimensions, and how using a single axis partitioning scheme would reduce the collision detection load exponentially.

At one point, Jason started playing with the window with his mouse (as probably most geeks do…. we must have some sort of interaction with the computer at all times.) , and they noticed that the balls seems to react to window movements. Very, very cool. Well, it turns out this is a bug. the longer you hold down the mouse, the more the balls gain downward force (due to gravity) and the more they “bounce” upward when you let go. I blame Windows, for not processing messages while dragging a window.

All in all this was a very cool talk. The demo was very flashy, and demonstrated the point well.

So, a bit bewildered from the first session, I make my way back to the lecture hall for Chris’s talk. I’m not really sure what to expect here, 2D gaming is pretty broad.

He starts out showing a demo of exactly what he has done, which is the main focus of his talk. Chris, it turns out, has written a program called Warplanner that allows multiple people to play this game with each other over the net.

Chris had a demo of some basic 2D DirectX work using DirectDraw. As Jason pointed out, this is a deprecated namespace, but the demo was still worthwhile. The next item on his agenda was how his network play worked. He made the mistake of asking Jason about some terminology for a “lounge” in DirectPlay to which he got a “I don’t know, I don’t use deprecated namespaces” answer. Ouch, heckled again.

Throughout the presentation Chris showed a really slick replay feature that would allow you to go back to any point in the game, and replay some or all of the moves. I have to say watching it was pretty impressive.

All in all this was a good talk, and made even better by Chris’ enthusiasm for his project.

OK, so here we are in our first session of code camp. Fresh from *not* winning the X-Box (if they could have told me I wouldn’t win before I got there, I could have slept another few minutes…), I knew we were surely not going to hear a standard Microsoft marketing presentation, because they told us specifically in the “Welcome to Code Camp” that we would not be hearing any of this at this Non-Microsoft-sponsored-but-payed-for-by-Microsoft-non-Microsoft-code-camp event.

Hmm, it seems that our friend David here missed that part. A good part of his talk was very marketingy (if that’s not a word, then it should be, because there is not a good word to describe “something that is marketing like”). One of the “students” had to call him on it, and get him rolling through his slides.

The major gem in this talk was his demo of PIX. If you don’t know what it is, use Google. I’m too lazy to do the search for you and provide a link to some useful material. I will, however, explain it in my own words. PIX is kind of like a DirectX debugger. You can record all of the DirectX information about an entire length of a scene, a single frame, etc. The really cool part is what you can do with that information. For each frame, you can step through each of the DirectX API calls, and see what is happening on the screen. You can watch as it draws the background, textures it, and then proceeds to draw each layer on top of it. Essentially you get to step through the minute steps of rendering a single frame and see whats going on in the guts of DirectX. Man, it’s like PIX just oozes geekiness…

The next best thing about this talk was that he told us that he wrote a book……45 times….

Have you ever had the situation where you needed to return a Method’s name? An example of this might be in an error routine, or for logging. The following function will do just that, with no need to hard code the method’s name.


‘Returns a methods name, based on the current stacktrace
Friend Shared Function ReturnSource() As String
       Dim aStack As New System.Diagnostics.StackTrace
       Dim aMethod As System.Reflection.MethodBase
       ‘Use Frame 1, as Frame 0 is this Method
       aMethod = System.Reflection.MethodInfo.GetMethodFromHandle(aStack.GetFrame(1).GetMethod.MethodHandle)
       Return aMethod.ReflectedType.FullName + “.” + aMethod.Name
End Function

Here’s a useful little re-build and run macro the 4Guys came up with for the .NET IDE.

If you’ve been developing any ASP.NET applications, you may have run into the same frustration that we have with the Application cache. We’ve discovered that the Application cache is not cleared until you rebuild your application (which when you think about it is kind of what you should expect) so often when you are expecting the cache to be empty, it isn’t, leaving you scratching your head until you once again remember, Oh, that’s right I have to rebuild before I run to make sure the Application cache has been cleared.

So since no button exists to rebuild a solution and run in just one single click and we could not find anyone else out there who had already done this work, we created our own Macro in VB.NET and assigned it to a button on our toolbar.

Just add this code to a Macro Module and then add it to a button on the toolbar in .NET and enjoy the one button click to re-build and run a project!


Imports EnvDTE
Imports System.Diagnostics

Public Module UserCreated
    Public Sub ReBuildAndRun()
        ‘Add an event so that we can detect when the solution has completed the rebuild process
        AddHandler DTE.Events.BuildEvents.OnBuildDone, AddressOf AfterBuild
        ‘Rebuild the entire Solution
        DTE.ExecuteCommand(”Build.RebuildSolution”)
    End Sub

        ‘This sub is called once the solution has completed the rebuild process
    Public Sub AfterBuild(ByVal Scope As EnvDTE.vsBuildScope, ByVal Action As EnvDTE.vsBuildAction)
        ‘The Event Handler must be removed to prevent eternal looping since
        ‘the Debugger.Go call causes another build which would then raise the event again and again and again….
        RemoveHandler DTE.Events.BuildEvents.OnBuildDone, AddressOf MyMacros.UserCreated.AfterBuild
        ‘Run the project
        DTE.Debugger.Go(True)
    End Sub
End Module

So, in developing the architecture for a new Portal project that the 4 Guys are working on, we decided to be as nice to the future developers on the project as possible (aren’t we such sweethearts?) And part of being nice to a developer is giving him as much intellisense as possible in the code. Well, in trying to deliver this very nice feature to the developers, we decided that function parameters should have intellisense as well, whenever possible. And here is the method we came up with for providing this. Our question becomes, is there a better method out there?


‘An enumeration of the names of the various User Controls
Friend Enum UCName As Integer
    UCHeader = 1
    UCFooter = 2
    UCLogin = 3
    Temp = -99
End Enum

Friend Function GetUserControl(ByVal Name As UCName) As UserControl
‘Returns a UserControl based on the Name passed in to the function.
    Try
        Return CType(LoadControl(GetUCPath(Name)), UserControl)
    Catch ex As Exception
        Throw
    End Try
End Function

Friend Function GetUCPath(ByVal Name As UCName) As String
    Try
        Select Case Name
            Case UCName.Temp
                Return “~Temp.ascx”
            Case UCName.UCFooter
                Return“~BaseUserControlsUCFooter.ascx”
            Case UCName.UCHeader
                Return“~BaseUserControlsUCHeader.ascx”
            Case UCName.UCLogin
                Return “~BaseUserControlsUCLogin.ascx”
        End Select
    Catch ex As Exception
        Throw
    End Try
End Function

So, if a developer wishes to load a particular UserControl from anywhere else in the project, the can just call the function GetUserControl like this.

Dim lnkFooter As New UCFooter
lnkError = CType(GetUserControl(UCName.UCFooter), UCFooter)

No need for the developer to remember the path for every user control, (no need for the developer to even remember what user controls are available since they can just scroll thru the Enum to see what exists). So what do you think? Is this a good practice and worth the extra overhead and work to provide this intellisense or is there a better method out there?