January 16, 2013

The boring side of game mechanics

by Jon

I’m at the stage where I’m coding the basics of the core mechanics. I’ve moved away from the more interesting world of 3D and am using good old fashioned buttons and labels as my primary UI as I actually fit some gameplay into the game as only part of it will need to have fancy graphics. The rest is good old fashioned turn based fun and so I can afford to not have it looking very sexy while I make it actually be fun.

It’s far from that at the moment of course, although I am close to making it possible to win the game. I consider this to be an important step because of my experiences with coding non-game projects. To my mind it is vitally important to have your project working at the most basic possible level at the first possible opportunity so it can be used, tested and critiqued with client feedback. The game I’m working on is yet another 4x space game, mainly because I’m really disappointing by most of what is currently available for iOS in the genre and so my current victory condition will be to send ships to capture the entire universe. In this case the universe will be two systems and you will start with a ship to do it. There will be no resistance on the other planet. I didn’t say the game was fun yet.

It’s important to say that at the moment the actual game logic only has a few hours work as I’m doing this in my free time and I only see needing a couple more before I’ll hit this stage. The goal is to have a nice set of unit tests for the logic and so I’m going at the core C++ code with full TDD and letting the UI be a bit more fast and loose.

My priorities are probably really off but the idea of having something that is playable also extends to things like the icons, splash image on iOS and the like. The more it feels like an actual full game the better and so my next stage after the win condition is to go through and make the UI a bit more graphical. Part of this whole experiment is to find out if my experiences as a software engineer for many years apply well enough to game development, or if they just make me spend time working on the wrong bits too early.

 

 

 

Posted in 4x, Game Progress | Leave a Comment »

Tags:
January 7, 2013

The state of OpenGL

by Jon

It’s odd, but I don’t think that OpenGL is in a very good state at the moment. There’s been a massive change away from the fixed pipeline but the quality of resources out there to help you are rather thin on the ground. The latest red book that covers just the new way of doing things is still months away, and the old 3.x version of the book spends a lot of time explaining deprecated features.

It’s even worse online with the majority of tutorials being out of date and lots of unhelpful people on forums saying things like learn the fixed pipeline first because it’s easier. This is patently untrue as learning the fixed pipeline first makes learning the current versions even harder.

Basic shaders aren’t hard and vertex buffers can be explained very simply, it’s just that the first tutorial needs to be quite a bit longer in order to get something on the screen than before. Not enough books or tutorials are confident to say “this is the code you need, I’ll explain it later” and so too many hide the initial steps behind proprietary libraries that don’t help anybody understand what’s actually happening until far too far into the process.

Just my 2c.

Posted in Game Progress, OpenGL | Leave a Comment »

Tags:
January 5, 2013

That time at the start when anything is possible

by Jon

The plan this year is to make a non-zero amount by selling a game. You’ll notice the victory condition is extremely vague and doesn’t need any real form of success, just a single sale.

This isn’t about money, it’s about finally putting together all the bits and actually making a game and, more importantly, finally getting my head around OpenGL. I got quite far a few years ago but that was back in the fixed pipeline days and as even before shaders so that’s not very useful now.

I do have a couple of restrictions I’ve given myself. Anything I write has to be multi-platform because experience says that when you’re ignoring provided UIs it’s always a better idea to build this in from the start rather than try and shoehorn it in at a later date. It just seems daft to ignore the potential of several app stores to sell through rather than just limiting myself to, say, iOS. To start with this means I’ll be going to iOS and MacOS as the primary platforms, and Windows as a secondary option in case the Windows 8 app store actually ever takes off.

The general rules of multi-platform are easy. Have a set of platform specific windows that aren’t shared, then have the whole logic of the game be the same between platforms while the rendering/sound/controls and the like get to be hidden behind interfaces so they can again be platform or technology specific. No OpenGL typedefs or functions can appear in the generic code. This is all basic stuff, and nothing that hasn’t been done thousands of times before. It’s also good programming practice so I would still be doing it even if I wasn’t eyeing up the possibility of multi platform.

I’m well aware as well that the biggest mistake people make is to make an engine first and forget the game, but that’s not my intention. I believe in heavy refactoring when needed and only writing the minimum that’s needed in order to get the current goal done and so I have an object model that just meets my goals at the moment. By keeping an eye on reuse and the requirements for MacOS and iOS game features that I suspect (and hope) it’ll naturally end up that way.

So far this year I’ve written the code to get everything up and running and load untextured 3D objects into memory. The next step is rendering them under both OpenGL3.2 and OpenGL ES 2. In fact it’s this step that caused me to add in the two separate renderers today and allow the graphics framework to be switched out.

My big concern this early on is my lack of unit tests, but I know that they will mostly cover the actual game logic itself so that should resolve itself once I’ve written some of that.

Posted in Game Progress, iOS, MacOS, OpenGL | Leave a Comment »

Tags: , ,
December 24, 2012

OpenGL 3.2 on MacOS

by Jon

A reminder to myself the next time I have to look it up: In order to get NSOpenGLView to use 3.2 core then you just need to add the following code:

-(void)awakeFromNib
{
    NSOpenGLPixelFormatAttribute attrs[] =
    {
        NSOpenGLPFADoubleBuffer,
        NSOpenGLPFADepthSize, 24,
        // Must specify the 3.2 Core Profile to use OpenGL 3.2
        NSOpenGLPFAOpenGLProfile,
        NSOpenGLProfileVersion3_2Core,
        0
    };
    
    NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs];
    
    if (!pf)
    {
        NSLog(@"No OpenGL pixel format");
    }
    
    NSOpenGLContext* context = [[NSOpenGLContext alloc] initWithFormat:pf shareContext:nil];
    
    [self setPixelFormat:pf];
    
    [self setOpenGLContext:context];
}

 

Posted in Uncategorized | Leave a Comment »

  |  
Follow

Get every new post delivered to your Inbox.

%d bloggers like this: