A bit of a shorter post. Sort of a “progress” report on some of the personal stuff I’ve worked on recently.
I’ve come to form a love/hate relationship with BASeBlock. This is mostly because there are a lot of things I like about it’s design, and a lot of things I hate, and the things I dislike tend to be difficult to change. Some of the basic dislikes includes a lack of DPI support and how it won’t actually scale to larger sizes. On my monitor it is now tiny which is annoying and pretty much trash in the form of an action game. I’ve brainstormed a few solutions. The simplest would be to simply scale up the bitmap that get’s drawn to the screen. That is still a pain but is doable. Another would be to go a step further and actually scale everything in the game itself to larger sizes. That would be a rather large undertaking, to the point that I’m not even sure it would be worth the effort. I made a few minor revisions to try to get it to scale using the first method but ended up shelving that work for the moment. It’s rather disappointing to find such glaring problems with your old projects that you put so much time into, and almost painful to even consider just shelving the project entirely and just moving on. I certainly made a lot of mistakes with BASeBlock but I think it does well for a game using such basic capabilities (GDI+ drawing for a Game is rather unorthodox!).
3-D programming is incredibly annoying and uses math that is far beyond my abilities to actually comprehend. Viewmatrices, rotation matrices, dot products. It’s basically a case of Googling to find out how to do things, then hoping I can figure out how to get the math to work with OpenTK. Nonetheless, I have managed to make a bit of progress.
As with BASeBlock and realistically any game I make going forward most likely, it’s primary purpose is for learning stuff. BASeBlock is at this point “learning” how to refactor an old codebase to improve it, whereas originally it was for learning C#. Prehender is going to be both applying the design techniques I learned since creating BASeBlock as well as being my first 3-D game. With that in mind, it is a rather simple concept.
Originally, I was going to just create some sort of 3-D Block breaker. I have a rather unhealthy fetish with them or something. But I decided to change it up a bit. I decided to “steal” a bit of the design of the 2-D Game, “Spring-up Harmony” which effectively uses a physics engine, and you shoot coloured balls at coloured blocks. If you hit a matching block it will “loosen” from the static background and will interact with other blocks. Then you can catch them with your “bucket” at the bottom of the screen. I haven’t worked out all the details but right now I have it so you shoot coloured balls at an arrangement of cubes, and when a coloured ball touches a coloured block, the block loosens and will fall. I haven’t actually figured out the gameplay specifics, though. That does bring me to the title, though- 3-D programming is quite difficult. I haven’t used Unity before, I may give it a go at some point, however my interest in creating games is typically in what I can learn about actually making them- Unity seems to be more for people interested in making games, as it abstracts some of the parts I find interesting. But in my case, I’m using C# and OpenTK. Unfortunately this means I get the fun of dealing with concepts such as Projection and View Matrices, Dot Products, cross products, and the like. My math also fails me as I’m not able to determine the Camera position from the projection and view matrix, which is a bit goofy when I want to shoot the balls from the position of the camera.
On the bright side, this does make it (IMO) a more useful learning experience. I find it rather strange that I’ve had to resort to third party libraries (OpenTK and BASS.NET) for providing 3-D display and compressed audio capabilities into my C# Program. XNA has been rather left behind (Though still works) and it has a few omissions that I found frustrating when I was working on BCDodger. I would hope that .NET is given first-party support for creating games in the future that makes the task much easier but allows us to use the full power of .NET and C#. Sort of an XNA successor allowing us to also publish to XBox One. (Heck if such a library was made available even at cost I think I could justify an XBox One.)
BCSearch, my VB6 program works, but working on it is pretty much a non-starter these days. I am impressed with the patience I used to have working with Visual Basic 6 only 7 short years ago. Some features of the program will simply not be brought to completion.
Instead, I would like to create a modern WPF Windows Application that uses modern programming (and async await and such) for the same purpose. The effective goal is to create a rather straightforward on-demand search program. This differs from standard Start->Search and the search tool of Windows Explorer in that it is a full application oriented around searches and dealing with the results of those searches. I often find myself trying to find files based on rather specific criteria, and in that context I can see myself using an imagined BCSearch.NET that allows me to write a short C# method in a textbox for filtering each file. This would also allow me to rethink some of the weird architecture decisions I made with BCSearch, while also allowing me to work with WPF again (my work is almost exclusive Windows Forms, and the last time I really worked with WPF was with BCJobClock).
The “Video game” industry is interesting. It’s consumer base is often fickle, frugal, and judgmental. Often, reading about it- I’m glad I’m not trying to make a living writing Games.
It’s not that Games aren’t a great medium- they are. Personally, I suppose my “passion” is not so much games as it is programming. And, when you think about it- how many business consumers rely on games functioning properly? None. This is why Game consumers can be frugal- the software is not a necessity, it is a luxury- an excess. In contrast, “business” software can often have quite weighty contracts and a high price point. When software is required to do business, the costs are justified because they translate to a more efficient business. When it comes to games, many consumers will pay a low price point- perhaps 15-20 dollars at most- and then effectively “demand” updates to the game and new features to be added years later. I cannot wrap my head around the logic involved.
Within any consumer base, there is going to be technical illiteracy, particularly regarding the details of software construction. In the domain of Games, though- it seems that all the people who build PCs for the latest and greatest games become experts on how software works and how hard it is to implement new features. Typically, this leads to an inability to comprehend scope.
As a specific example- take Minecraft. One of the common criticisms of the game is that it runs “slower than it should”. This has the issue of being an assertion- on what basis do they know how it “should” run, after all? Furthermore, it is usually substantiated with “See, this Mod is just made by one guy and makes the game faster!”. Again- scope comprehension. When you develop a Mod, you can do whatever you want and typically you create a modification by focusing your scope; and as a mod author, you can ignore everything else, including hardware compatibility. The number of issues with “performance” mods in Minecraft is in the single digit percentage but that would be an insane number of people if the same sort of additions were integrated into the vanilla game.
Speaking in those terms, lately a “buzzword” has been “Mod API” or “Plugin API”; it is odd, in a way- since games did not typically advertise that they had any sort of an API until recently. And, even more curious, is that most of the people who want one, aren’t going to use it- they are effectively asking for it because they figure it means that other people will create good content for the game. But the reailtiy is that is going to happen regardless of whether there is an API. If you look at any older game you can find al ot of dedicated ROM hackers, modders, and expertise surrounding changing it or making modifications to the game. In reality a proper “API” surrounding a game really would just lower the barrier to entry and mean there is more shovelware and poorly written software.
Another issue is is that Games are more interesting. This might seem odd but what I mean is that it is often the “entry point” for new software developers who are getting interested. They will research programming and perhaps learn on their own, but too often one sees self-taught teenagers with no substantial experience or portfolio trying to criticize a game that has already earned unimaginable sums. This has a significant falloff as you move away from Game development and enter the world of business software. A game developer has to deal with the teenagers who complain about how the algorithm used to interpolate the rock items in the game is not entirely accurate and they should change it- that sort of thing doesn’t happen in business software, If you have to deal with anybody in such a capacity they are going to be an adult and they are going to be working in the interests of their company in terms of the business purpose, not for their own ego.
Naturally, there are exceptions. Developing games and even game modifications can be rewarding- But as you expand your portfolio of projects you find that you are, for lack of a better term, “Stretching yourself thin”. How do you find the time to maintain all of these different projects in your spare time without going absolutely bonkers? You don’t. YOu end up leaving projects alone for months, or even years; new ideas you had slowly drift away as you realize that you simply won’t have time to bring it to bear.
To summarize, the consumers of any Game Development are more finicky, frugal, picky, and critical than business software. It’s easy to evaluate if a piece of software suites a particular business purpose. It’s harder to evaluate if it is entertaining. With a lot of business software, the consumer has to choose something- so you only need to show how you are better than your competitors. This isn’t the case for games- you have to prove that your title is amusing, which is significantly harder.
A frequent- and aggravating- problem that I’ve had with games on my Windows machine is that many of them simply would not start. Inspecting Task manager would show a rundll32 process consuming the CPU and doing nothing useful. Terminating that would terminate the game process as well. This had become aggravating enough that when it happened an hour ago I got sick of putting up with it and decided to figure out what the heck was going on.
First, what do we know about it? the rundll32 process seems to invoke something within GameUX.dll. GameUX.dll is part of Windows Game Explorer library. Looking up what exactly that does online revealed that it is for managing, organizing, and keeping games up to date. That last one stuck out for me. See, my Windows machine has not had a Internet Connection for almost a year. And a LOT of software just assumes it can access the internet without proper error-handling. To test my suspicions, I decided to test something. I deregistered GameUX.dll using regsvr32 /u. Launched a game- and same problem. Interesting. After a bit more flopping around like a fish I realized that I don’t have one GameUX.dll, I have 2, since I’m running 64-bit Windows. so I unregistered the one in SysWOW64 as well. Started the game… and…
It worked, as did all my other old games that had stopped working mysteriously. Seemed the cause was simply that I no longer had a net connection. That seems a bit stupid, since these aren’t online games. Bit of a “woops” on the part of the Game Explorer. I imagine a quick fix could be added to actually handle the situation where there is no internet connection, rather than sit in a loop waiting for one to magically appear, while keeping the game from starting.
In the early days of networked gaming (I mean, the days of Doom- (not to things like imaginet)) connections were slow.
If a game or application tried to pump too much data over the connection- it would take time. Also, sometimes the architecture itself and the hardware involved introduced a sort of “time-delay” into the equation. This was called “network lag”- a doom game might not be enjoyable due to network lag, for instance.
As Online gaming has become more prevalent and requires less PC familiarity, the term has started to be used completely erroneously in all sorts of situations.
For example- if your PC is underpowered for a new game, or you set the detail to high and it runs slowly, it’s not “lag” because there is no actual lag between your actions and what you see on screen. the term “lag” was originally used to indicate the time difference between when you pressed a key and when the server acknowledged you pressing that key. since even with the lowest framerates your key presses are being sent to the buffer in your local machine immediately. The term practically redefined itself when games such as quake implemented client-side prediction- you could see another player moving forward, and, instead of stopping dead as your PC is awaiting game state information, the client continues to draw that character moving in that direction.
The short story is- “Lag” is completely unrelated to framerate. they are separate. You can have a high lag/ping and a low framerate, or vice versa, or both, but that doesn’t suddenly make them interchangable.
To further express what I mean:
While there is latency between the input and when you see that input on the screen (say, for example, if a program or game is only running at 1 fps; it could take a full second to see the effect). There is however no latency between when you press the button and when the game receives it.
So, for example, if your game is running at only a few frames per second, within the time between frames your actions are still being dealt with (if the game is written properly, anyway). For example, you could easily, say ,shoot an arrow or gun or whatever in the game, and because of the way the framerate is so low you could miss seeing that event at all.
With networked games, latency is a given, with 50 ms being something of a norm. Earlier online gaming dealt with much higher ping times- sometimes up to 500ms.
The way this is combat is to use client-side prediction. For example, if your friend billy is moving forward, and your game doesn’t receive packets from billy (or the server) for a while, it will just assume Billy kept moving forward. The other option is to have every single “gamestate” sent from the server shown separately, but then you only ‘see’ movement if the latency is extremely low; and this includes your own player; without client-side prediction, your game is really a “window” into another game running on a server, and it only shows what the server tells you you can see. With client side prediction, what it does is let you do what you will, send the packets for your movements, and hope the server keeps you updated. Sometimes this causes weirdness; for example, in quake, there might be a touchplate that controls a vat of lava, foolish individuals are supposed to try to run across, hit the touchplate, with opens up the hole and they die. Then you run across, and it doesn’t open… after you get to the other side, and a few moments later you suddenly find yourself already dead at the bottom of the vat of lava. this is because the button was controlled “on the server” so your game just let you do it’s thing, and sent your movements to the server, which obligingly allowed you to tread lava and then die for those few seconds while you thought you were still alive.
What most people refer to as lag are things that defy the client-side prediction; for example, it might show Billy walk off into the distance, and then when your game receives a update, the server is like “oh, actually billy turned and he’s over here now” at which point Billy’s “avatar” (character) suddenly plops over to that position. Usually, FPS doesn’t fit into this at all; you can have a high framerate and still get latency, of course; in fact, you are more likely to do so because a lower framerate helps hide the flaws in client-side prediction.