Wednesday, August 17, 2016

Ooh, is that the OSGG launcher for Windows? YES!

So, figured out how to get the launcher to... launch with reasonable default settings, and also compiled it for Windows.

See for more info and downloads!

Monday, August 15, 2016

OSGG v 1.0 Released!

So, finally, I decided to give OSGG a slight round of hacking.
I added glorious instructions on both the editor and the game.

And I also got it compiled for Windows computers (but only the game, not the launcher, so windows users will have to start it from a command-prompt if they want to use non-default parameters).

I'll likely add some more levels in the future, maybe during a twitch session :)

Anyway, builds are available on and in contigrator.
Grab the .tar.bz2 for source+linux and, the .zip for windows.


Friday, April 29, 2016

Samsung and/or Google: Do it better!

I got a Samsung Note 4 phone, I'm pretty happy with it. Good display, reasonable performance, software is rather stable (thought I'd have preferred if they'd ship it with stock Android).
However, yesterday I noticed something strange, my girlfriend called me and instead of showing the call as a contact, it showed just her number. Indeed, the contact was gone. Today, 2016-04-29, I digged into it, and found that my phone had a different set of contacts than my gmail (I use for managing my contacts). This is a rather critical thing, in my opinion, I'm trusting my device with remembering phone numbers and email addresses of people whom I may need to contact in urgent situations, so having them randomly disappear seems critically wrong to me. So I spent the better part of a day frustrated, trying all tricks in the book to get them to sync up. I followed the troubleshooting tips from Google, disabling/enabling sync, removing and adding the gmail account, rebooting the phone, all to no avail. What I was left with in each case, was the "sync" icon stuck next to "Contacts" in my gmail account. Everything else worked perfectly for that gmail account (calendar, apps, etc), except for the most important (to me) thing; Contacts. I looked in the marked for a different "Contacts" app, until I realized that this was an issue with whichever component is responsible for actually integrating with gmail, I suspect it is part of the operating system itself, and not something I can do much about. More frustrating is having to search for "sync icon stuck", it's humiliating and reminds me of something you'd have to do with an "I product", not with glorious Android. No error message to help, except for the universally unhelpful "There was a problem with synchronizing, it will be fixed in a moment" which I was shown through several hours of hair pulling frustration. At last, maybe by luck, I stumbled upon a post which helped me, a post more than half a year old (meaning that both Google and Samsung has known and ignored this problem for as long, choosing not to supply a patch). That post, from 2015-07-15, is here:!topic/gmail/OzUCbeu_jfk

While the first thing I tried, was wiping all caches and application data, on all programs I could imagine being relevant (…Google and contacts), since there might be some kind of issue with a newer version of contacts attempting to access an older version of its own database (inexcusable to begin with, when the default behavior is "discard information"), I did not have the imagination that the actual "contacts database" was stored in a whole different program, which is "Contacts Storage", except, it is a system component, not showing the Contacts icon (making it difficult to find) and even though it is a system program, some genius decided to name it (in Danish) "Lagerplacering af kontakter" meaning that it is not in any way close to the "Kontakter" app in the list, meaning I'd never have thought to look for it if not for one comment in the thread I linked to, which instructed to clear app-data not only for a "Contacts" app, but also for a "Contact Storage" app.. Nice.

So, in short, what's wrong here is:
  • Erroneously and silently discarding data on the device.
  • Not fixing the problem via automatic update for more than 6 months.
  • Not providing a meaningful error message to the end user about a critical data-access/corruption/migration error, but "playing stupid" and lying about the issue going away by itself (which it gawk-damn never would!)
  • Not contacting or otherwise informing users that their contacts are silently being deleted.
  • Not providing the actual fix in the official trouble shooting documents.

Monday, March 28, 2016

Making games as a single developer (pt. 2)

Before I continue my rant about how everything was better in the olden days.. err about creating a completed computer game as only one person. I want to take a moment to define a few concepts as I see them in relation to games created by only one developer. The concepts that require refinement, are in no particular order; complete, game, successful and good. Starting with successful, you usually think of a game as being successful if you and your friends have heard about it, it sold well for its time or some other less obvious metric. Those metrics will not work well for you if you apply them to your own one-man games. Surely, there are several examples of games made by a single developer that fit those criteria, but for each of those, there will be hundreds that do not. So, unless you can reasonably expect to create the next Minecraft, I offer a another, and softer definition of success, which I believe work well for the hobby developer. Success is when your game is picked up by others, when it is distributed by magazines, mentioned on blogs and forums and, if it is open-source, is included in third-party or official software repositories for popular and less well-known Linux distributions. Further criteria are mentions/pages on wikis or archive sites such as moby games, is being ported to new platforms by other people without your knowing or consent, or is being distributed by a platform such as portableapps. I realize that a single developer could achieve some of these things by themselves, but if other people are doing it, it shows that others like your creation enough to do work to spread it, and in my opinion that is a great honor. I must admit that these criteria comes from how my own games have fared, I've not put a large amount of work into spreading the word myself, and I've been so greatly positively surprised when I Google my stuff and find it spread throughout the Internet, for me, personally, that is a great motivation to try to do good stuff which brings me to the next definition that I would like to make; Good, what is it? It is highly subjective, and it is a requirement for any worthwhile game to be it. I've read a definition elsewhere with which I agree and shall repeat here. A game is good when it meets or surpasses the expectations of the player. Simple as that. If you're like me, the type who sometimes go to MC. Donald's, you know what I'm talking about. I'm so very rarely disappointed at Mc.D, not because the food is amazing, but because my expectations are usually met, a warm slob of fat, just like the last one I got, with the correct amount of ketchup, served fast and relatively inexpensive. Thanks. Expectations met, happy fat guy who will say, "the food was good" without meaning great. You can make the MC. Donald's burger of computer games, if you adjust not only your own but also your players expectations. You're trying to make something that feels finished, complete and, for what it is, good, which, in turn brings me to the last definition: Complete. When is something complete ? As a developer, and especially programmer, nothing is ever complete. Games are large enough that there will forever be something to improve upon, be it some algorithm which is less than elegant, a pixel that's definitely wrongly placed on a sprite, or the way difficulty increases. So again, with no other credentials than the wish to write something down, I give you a definition of done that I'm struggling to accept myself. A single-developer game is complete when there are no placeholders, no dead-ends and nothing missing from the menus. When you can start the game without knowing any of the command-line parameters, configure the game and have the settings be saved in a configuration file, have a way to store and retrieve progress so that the player does not have to start over each time, and when the game is long enough that anyone would actually want to be able to continue. This of course, depends on the type of game you're making, and the type of audience you're trying to entertain, but making load/save functionality is great fun, and shows that you've got at least some idea of the state of your game. Your game should not only start and exit flawlessly, it should be packaged in such a way that players can download and play it. That means that the game is either web-based and hosted somewhere, or that it can be downloaded for Linux and Windows without the need to compile from source-code. But a game is not really complete before users can add their own stuff to it, and change the existing stuff, if your game is loading levels from files, are those levels going to be created in a specialized tool ? If so, that tool will likely need the same rendering routines as your game, and it will need to be able to load the data the same way as your game, so, how would it be less than obvious to build the level-editor right into the game, design and implement it already from the beginning, with the idea that someone else is also going to see/use it, this way, you also get a nicer level-creation tool and a more enjoyable time creating levels yourself. The last thing I want to touch on, is game. To the purist, a game is a set of rules, or laws, under which the player must complete a specific task or set of tasks. To the holist, a game is the whole system. So, to make your own game, you first need to go to the beach and dig sand for the transistors you will use to build your CPU. Okay, that's taking it too far, let's skip the CPU architecture and also the operating system (if you're making a game on a platform which has one, which I'm going to assume). So, the game is the whole executable and all the linked libraries. It's the OpenGL library and audio driver, it's the joysticks, mice, keyboards and monitors, and it's also about defining entertaining rules and enforcing them in an entertaining manner, because, entertain. The reason I include the whole executable program in the definition of game, is that every choice is going to affect the finished product, the things that limit you will have you find alternative solutions, the things that are easy will have you sink way too much time into trying to come up with the right shade of pink for your invisible unicorn. To the player, the game is the executable they start up, the whole thing. Your players won't distinguish between the graphics library, your drawing routine or the reason behind there being entirely too little ammo on level 2. The experience is holistic, how files are handled will affect your decisions on level sizes and loading screens. The input latency will affect (along with the genre, and intended audience, surely) the tightness of the controls. Rendering methods will affect not only how the game looks to the player, but how moving and looking around "feels". In some games, such as Quake3, vsync on makes me feel "weird", and I always notice it, even if the game is stuck on 60 fps, it's just "weird".

With that rant out of the way, maybe next time, I will talk about my thoughts on creating a complete RTS game.

Making games as a single developer (pt. 1)

You can create a whole, entertaining, complete and polised game as a single developer. I mean games that are good enough that people who are not your friends or even know you will play them, and share them with their friends. This is my personal observations and opinions as someone who is not (and has no wish to be) a professional game developer, someone who is not a professional gamer or reviewer, someone who just find playing and creating games entertaining.

First off, what you've been told everywhere else, so I will keep it short; Adjust your expectations. You're not going to create Doom, if you're good, you can create wolfenstein as a single guy, but don't get your hopes up. If you want to create a 3d MMORPG (not a tech-demo, but an actual, finish product that people will like), this article is likely not for you.

Now that your expectations are low enough to be realistic, think about games through time, was space-invaders a complete, polished game ? Yes, it was, and it made someone filthy rich. Space-invaders is a technically, conceptually and graphically simple game, which runs on simple hardware, which creates consistency. Everything presented to the player is consistent with the players expectations, of the game, of the hardware, of the "system". This is important, and I'm not sure if anyone has stressed it before, but I will, because to me, an important parameter in what makes a game "finished" or "good" is a percieved (subjective) consistency between the game implementation and its engine. If you take an engine with UDK5 capabilities, throw in assets of Quake1 resolution/density/quality, and mix it with amazing shading and accurate physics, you get a freak. Maybe the concept in your game IS to be a freak (Voxelstein3D for example), then great, that's not the kind of game I'm talking about here, I think it's really cool, but in my opinion, it stays well within the realm of the tech-demo. Now, let's take the actual Quake1, you can think what you will about the visual graphics, but they are consistent, it feels like "this is what I'm going to get, this is my life now" it helps the player immerse themselves, to believe the environment. My opinion is that it looks "real" in a sense, because the fidelity and content are aligned and consistent with everything else within the game. It avoids such comments as "Oh! I know it's possible for ABC to happen right here! I've just done that before! Someone made the choice to disable that feature here, just so I have to play the game differently!" That's annoying as hell. The build games did not have real destructible environments, but they had movable ceilings and floors, and the level designer could trigger something that looked like environment destruction, it usually worked by inserting a few special sprites to tell the engine "Before activated, these floors should have full height" and then place a sprite looking like a crack in the wall, to hint the player "here's a place where you can destroy the environment". Consistent. Games like Red Faction, which did allow almost fully destructible environments, used different materials to hint to the player where the environment could be destroyed. This should sound a lot like game-design, and less about technical consistency, but they are conneceted, because the more feature-rich an engine you have available for your game, the more features you want to pick from, and, if you chose to use a feature once, you must keep it in mind for every single decision you're making in your entire game, something which even many AAA titles get wrong (and I know they're trying hard), but you're just one developer, you can't make AAA graphics and AAA physics and AAA everything. But the A's go together, if a game has AAA graphics, we, the players, expect AAA everything else too, and you can't deliver! So think hard about your choice of technology.

Depending on the type of developer you are, you may be more interested in graphics, or in level-design or in programming. Pick a genre that presents interesting challenges in the field you enjoy, but is more forgiving in the fields that are not your primary interest. A first person shooter may be one of the worst types of games to implement as a lone developer, so as someone who's only ever thought of making one, I'll give my opinion on where it can go wrong, and what could be done to make it go right. An FPS is heavy in programming, assets and level design. It can be pretty forgiving in story and puzzle (and by that, I mean that making interesting puzzles for an FPS can be pretty easy). If you chose 3D models over sprites, you're doomed, because, try modelling and rigging one 3D character, unless you're a savant, that's already a few days work, just drop it! Afterwards you'll spend half a life on character animation code, and then you'll be dead. I'd go with a low-resolution friendly technology for an fps, either a raycaster or a 3D engine with limitations in place to keep you from making something too technically inconsistent, like smoothed wall textures and sprites. Upon seeing a smoothed wall texture, the player will expect 3D models, and you're doomed. If you want to create and finish a FPS as a single developer, go lowres, no filtering and use sprites. This also helps a lot with the math if you're limited in that aspect (as I am), as 2D math is usually a bit easier to understand and implement (go write a raytracer if you want to practice 3D, but don't call it a game). Player expectations to raycasted games are usually easier to fulfill, because you can concentrate on the things they let you do well, like interesting puzzles, textures (lowres textures can look great, and they are easier to maken repeat in a nice way, and they are better okay!?). A raycasted game frees you from rigging character models, to do interesting and creative stuff with the story, weapons, design and gameplay, so go exploit that. Now you might ask, who's going to play a raycaster in 2016 ? Well, me for once, and while I'm definitely odd, I'm not the only one, and I'd rather play a packed and rich raycaster than a barren and incomplete fully 3D game. As for tools and tech, that's up to you, I think I'd personally (because 2016) implement a raycaster in the GLSL shading language, but other options are to use an existing engine, such as Build (which was opensourced iirc) or use a lot of dicipline with UDK or Unity. I know at least one studio is making a build game in 2016.

Next time (if I continue this), I will write about RTS games from the point of view of someone with a lot of opinions and no real experience to back them up.