Most of my time has been going into paying work.  But I’ve been getting some things done in MT2 around the edges.  Most notably, I’ve hooked up a new system for generating roads and paths.  I’m pretty happy with it.  I’ll show some screenshots in the next few days.  Basic idea is that it now carves the roads into the terrain, basically overwriting the themed terrain type.  You can continue building terrain underneath the road;  the road just floats over the terrain surface (carved down into it).

I’ve been spending a lot of my time looking into AI bugs in the simulation.  I finally tracked down a problem which caused AI developers to occasionally slow down a lot when approaching a work site.  It was extreme enough that in my usual AI testbed level, the developer which was given the job of building the Inn would usually take so long to reach the building site that all the other AI developers would complete at least two queued jobs before the Inn-building developer even arrived to start constructing the building.  I fixed the bug (it was to do with the path variation code which causes entities to not precisely follow the “shortest possible path” to their destination.  The developer ended up in a version of Zeno’s Paradox, infinitely choosing to travel just 30% of the way to the target, and taking forever to actually reach the destination).  Fixing that bug also seems to have fixed another problem I’ve seen a few times;  AI players who eventually stop moving, while in the middle of questing.  If a monster comes up to them they’ll fight it, but otherwise they just stand still and don’t do anything.  Haven’t seen that again since fixing the bug, so I’m guessing that they were being affected by the same bug.

Regardless, I’m getting back into AI refactoring.  There’s still some awkward bits in the AI code, particularly around quest handling.  And things appear to go catastrophically wrong (ie: crashy) when someone completes all available quests in the game and wants to do another quest.  A little code cleanup should set that right, I hope.

A big concern I have right now is the terrain rendering.  The new infinite-zoom terrain system (which I love, and can’t imagine why I didn’t implement it in the first place) is fantastic, but the terrains don’t look so great from above — the visual style was kind of designed to be seen from a forward-view, not a down-view;  it was intended to consist of color-only, with textures used to add edge detail, while still maintaining the smooth color appearance.  And it just doesn’t read well from a top view.

I’m intending to build a MS3 demo in the near future.  My goal for it is to actually accomplish what I’d intended for the MS2 demo — a fully playable vertical slice of the game, similar to what would be in perhaps the second or third tutorial level of the full game.  I should really set a date for that.

In other news, I’m reducing my hours at paying-work, so I can dedicate a full day per week to MT2.  That starts in about a month.  We’ll see how much that boosts development speeds.

The post Updates appeared first on VectorStorm.

DESIGN:

• Need to decide what to do RE: buildings.  Should buildings just be procedurally generated (or artist-created?), or should I be building a system which allows players to create their own structures within the game itself?  Need to make a call on this ASAP;  I’ve been procrastinating about starting either approach of this for far, far too long.
• Related to the above, what precisely is the visual functionality of raising/lowering the “level” of buildings/roads?  If they’re procedurally generated or artist-created, then this might just mean “make them taller” or “make them more ornate”, but if these structures are player-built, then I don’t really want to touch them, and maybe there should be no visible changes when a structure has “level-up” or “level-down” used on it.
• Also related to the above, how should the player be editing the world map?  Should he be using the “paint on” system which I’ve been playing with so far?  Or what about building oddly-sized “cells” inside each region, and changes to the map are made by assigning the changes to each “cell”?  (This isn’t far off from what most Tycoon games do).  This has the benefit of making things a little more regular and simple;  no grabbing a single vertex and extending it up into a 500 meter tall spike, for example.  On the other hand, the player couldn’t grab a single vertex and extend it up into a 500 meter tall spike if he wanted to.
• All three of these points are basically the same point:  Is this game a game in which the player places pre-built structures and assembles pre-built ground, or is this a game in which the player constructs the structures and designs the ground?  I very much want it to be the latter, but the UI for giving a player that sort of ability is not trivial at all.   Need to pick one option, and kill the other.  Stop wasting time by kicking this decision down the road.

Core simulation systems:

• Open passes which allow PCs to move from one region into another, through the impassable mountains.  (These probably get implemented as “buildings”, which appear on both sides of the mountains.  That is, treat them as tunnels through the mountains)
• Method for setting property values on a region.  Most critically, level range.
• MMORPG tech tree.
• Inventory, for limited-use collectable build actions (awards).
• Add “point of interest” building type.  No particular in-game function, but PCs — particularly exploration types — will occasionally travel to visit them.
• Consider spending some time tuning random generation of class/monster powers.  Right now, the randomly generated powers are the same, which means that a PC and a monster of equal level, both starting at full health, will each win a fight about 50% of the time.  This doesn’t seem right, compared against real MMOs, where the player should win most of the time.

AI:

• PCs store memories about recent events.
• PCs group into parties to go adventuring.
• Once a PC has gained too many levels for its current region, try to find a path to a new, correct-level region.
• CONSIDER:  PCs form guilds.  PCs form attachment to their guilds in a similar way to how they form attachment to the MMO now;  having guild support in your MMO and a strong guild presence will tend to keep guild-affiliated subscribers even if they’re not in love with the MMO.  Downside is that if you’re relying on guilds to keep subscribers present, then a guild collapse may result in many of its players leaving.  I like this idea, but is it interesting for a game?  Can players influence this in any meaningful way?  To be considered.
• If a PC wants to do a quest, but doesn’t know of a quest giver with an available quest for their experience level, generate a bad memory and cheat to find a new quest giver of an appropriate level.  (Imagine that the PC has access to something like Wowhead)
• PCs, as a group, evolve popular attack strategies over time.  (Imagine that they have access to something like Elitist Jerks)

Metagame:

• Scenarios: Series of pre-set game scenarios with objectives for the player to meet in order to progress.  Ref: Roller Coaster Tycoon.   These should be considered as “tutorials”, to teach the player how to play the game.  Each of these scenarios are confined within a single region of a larger MMO (although many of them may exist within different regions of a single MMO), and each should probably be focused on a different facet of the game.  (For example, Scenario 1 may be entirely based on terrain shaping, Scenario 2 be about building placement, etc)
• Free Play: The player gets full control of an MMO.  Probably want to give the player a set of starting MMOs to select from, here;  a WoW-style one, a sci-fi one, etc.  Which then can be modified to the player’s tastes.  Player should also be given an option about how large they want their MMO to be.  A full WoW-sized MMO takes up a LOT of memory/CPU!  Most players will be happier with a much smaller one, but I’d like to keep the option open for folks who want the whole thing.
• Add optional missions for the player, which give bonuses if completed.  Lots of the development time is going to go into creating these missions, and the system for when they’re presented to the player.  (See UI for the missions, see Core systems for the bonuses)

UI:

• Chat interface for PCs and system messages.
• Interface for presenting the player with their current missions, and available ones to accept (see “Metagame”, above)
• Inventory interface for MMO building awards (see “Core simulation systems”, above)

Graphics:

• Pick whether PCs, NPCs, and monsters should be representational or iconic, and set up proper graphics for them, one way or the other.
• Implement several more terrain types.
• Make the ground clutter system work for more than one terrain type.
• Need to replace current “umbrella” trees with nicer (and less polygon-expensive!) trees.
• Spruce up paths/roads.
• Nicer procedurally generated buildings.
• If rendering performance becomes a big issue, spend some time working on graphics batching some more;  there should be some big savings to be made here!

The post What remains appeared first on VectorStorm.

In today’s screenshot, you can see (some of) the individual building blocks of the MMORPG Tycoon 2 terrain.  I don’t know whether they will be visible in the final version of the game, but I thought you might like to see them now.

In essence, the MMORPG Tycoon 2 map is constructed from the cells of a Voronoi Diagram, with each game “region” composed of a single Voronoi cell.  Each of these regions is itself filled with more Voronoi cells, and these central cells become very important to the underlying structure of the game.

For me, the “maybe somebody else has already solved this problem” probably should have been two years ago, when I first set up this system.  I wrote all of this geometry code myself, and while most of it worked really well, there was one bit of which which didn’t;  clipping the embedded Voronoi cells inside each region, to maintain the region boundaries.  I struggled with that code for many days, trying to make it work reliably.

Don’t get me wrong;  the code mostly worked.  It worked about 99.9% of the time.  There were only a few really awkward situations which would cause it to fail.  But as you can see from the screenshot, there are actually a lot of Voronoi cells in a map — even a small one, like this.  My code would tend to fail about one time per five maps.  I’ve spent many, many days trying to make the system work consistently, over the years.

Then today, after spending almost another full day debugging the problem, I finally thought, “I bet someone else has already solved this problem”.  Fifteen minutes later, the problem is solved, simply by adding some source from The Clipper Library.  It’s much more powerful than what I actually need, but it handles my simple clipping problem without breaking a sweat.  Big kudos to its author!

So for future reference:  When stumped, particularly on something geometry or physics-based, go looking for a library.  They can save a huge amount of your time, and get you back to working on the things that you’re actually good at working on.

The post Development lesson for the day appeared first on VectorStorm.

I’ve been working on MMORPG Tycoon 2′s procedural terrain generation, today.

Issues fixed today:

• Beaches are wider.
• Beaches are no longer jagged when not oriented precisely north/south or east/west.  (Related to this, lake borders are no longer blocky).  They also are no longer precise straight lines along the region boundary — the beach actually occurs about a hundred meters inside the region boundaries.
• When mountain borders extend out into the water, they no longer extend grass through the ‘beach’ zone bordering the water.
• When mountain borders extend out into the water, they no longer have a “wedge” cut into them (pictured in this screenshot).  The mountain border now ends more naturally.  Or at least, as natural as you can get when you’re talking about something which intended to appear as a blatantly artificial mountain border.  :)
• Beaches now smoothly rise from the water, instead of “stepping up” by a meter or so from the water level.
• Removed three ‘if’ statements from the edit-mode camera code, resulting in a much smoother camera motion while zooming in and out.

Useful tip for anyone writing camera code:  Removing ‘if’ statements (or other forms of conditionals where sometimes the camera will do one thing, and other times the camera will do something else) will almost always improve the overall camera behaviour, from a user’s perspective.

The post Terrain crafting appeared first on VectorStorm.

I’d like to talk for a bit about the Game in a Week process;  about what it was intended for, and about how it has worked out, and maybe about what I want to do with it in the future.

From the start, Game in a Week was supposed to be a game design exercise, not a game making exercise.  Yes, I was supposed to produce something playable by the end, but the real goal of the exercise was to get more practice at designing games — particularly unconventional, experimental games;  I already have heaps of experience implementing games, it’s breaking out of the box that I need practice at.  What’s more, it was supposed to be a low-stress activity and have low-impact on my other development;  the idea was that I’d do what I could do for a week, and then stop.  No matter what state the game was in at the end of the week, I would release it in that state and never spend time working on it or maintaining it again.

One of my unstated goals from the start was that each design for a Game in a Week should be interesting and unconventional in some way.  I didn’t want to just create a variation on somebody else’s game design.  I definitely didn’t want to make (for example) a fancier version of Asteroids.

With that said, let’s run down the list and talk about each game I’ve made as a “Game in a Week” project.

Ill-Timed Petition Damsel

In many ways, Ill-Timed Petition Damsel is my favourite of the Game in a Weeks.  It definitely had the best theme statement to select from, and it turned into a really interesting, unconventional game design.

The design here was that you were attempting to get signatures for your petition about road safety.  The trick was that each copy of your petition was somewhat cursed — after a certain period of time, an out-of-control car would smash through it and anyone nearby.  So your goal was to get the petition close to as many people as possible within the time limit (thus gaining lots of signatures), and then get rid of it again in such a way as to avoid any people being hurt by the out-of-control car.  If people did get hit by the car, police would appear and try to apprehend you, one police for each person hit by a car.  The game ran until the player was caught by a member of the police.

Stripped of the theme, the game was really a “push your luck” sort of game, where you want to get into a high concentration of pedestrians for as long as possible, and then get far, far away from them before the consequences hit.  As pedestrians (inevitably) get hit, you also have to evade chasers, which threaten to end the game.  It’s actually a very simple design, but not one that we see used often.  I can’t think of another game I’ve played which is structured this way.

I’m very proud of this one.

The Muncher’s Labyrinth

The second game went just as well as the first — maybe better.

The Muncher’s Labyrinth, at its core (although I wasn’t thinking about this), is a reversal of Pac-Man.  It’s a game in which the player must defend the dots in a maze from invaders.

My original design for this game was completely different;  it was almost a variant on pachinko;  you were attacking an enemy castle by using a cannon to fling a Muncher over the castle walls.  The trick was that the user had no control over the cannon’s angle or power.  Instead, the player needed to position a series of panels for the muncher to ‘bounce off’ from in mid-air, in the hopes of getting it to land inside the castle walls.

But partway through the week, that ‘pachinko’ approach just wasn’t feeling fun to me.  So I switched the design.  And this was much better.

One element I really love in this game is the ability to break down walls, which provides a short-term benefit (catch a fleeing thief), but long-term penalty (thieves can move around the maze more freely).  The charge mechanic feels really solid to me as well;  the time it has to build up before activating just makes it really satisfying when you manage to time a charge right.

The one little issue I have with this game was that while I was developing it, it felt like it dragged on for far too long if you played until every gem was stolen.  So I put a five minute time limit on it, and scored the player based on how many gems were left at the end of five minutes.  Now, I intensely dislike that choice.

In retrospect, I should have had a positive goal for the player, instead of only negative ones.  That is, in addition to “stop the thieves from achieving their objectives”, there should have been an objective for the player to achieve.  This probably would have been to visit some number of points within the maze (my instincts say four), and once those four points were visited, the invasions would stop and the game would end.  This would have made a much more sensible duration on the game, and put another interesting choice into the player’s hands:  charge off to hit his own objectives, or stop the thieves from achieving theirs?  This would have been much better.

Trivia:

• Each thief has a 1/256 chance of spawning using the Petition Damsel graphics, instead of the usual thief graphics.
• This was the first VectorStorm game to render a filled triangle, which was used to give the impression of bright light flooding in from the entrances to the maze.

Overall, I’m extremely pleased with how this game went.  The Muncher is still the unofficial mascot for VectorStorm games, often showing up in credit scrolls and elsewhere.

ThunderStorm

This was an interesting one.

The big design question I was playing around with in this one was about whether an arcade game could be made in which a player controlled a process, rather than controlling a specific character.

In the game, the player starts out with one angry storm cloud.  In his rage, the player shoots thunderbolts at happy clouds.  If a happy cloud is hit by a thunderbolt, it turns into an angry storm cloud.  The players controls affect all storm clouds simultaneously.  That is, they all shoot at once, in the same direction, and they all move at once, in the same direction.

Happy clouds, controlled by AI, attempt to merely touch the storm clouds, which would calm them down and take them back away from player control.

There were lots of variations of this game.  I had versions where hitting a stormcloud with a thunderbolt would destroy the stormcloud, I had versions where you could use mouse control so that all stormclouds would fire at a single position, instead of all firing in the same direction, etc.  In the end, I really like the zero-sum, closed-circle feel to the game.  There’s always the same number of clouds, and at the title screen they’re all happy clouds.  Starting the game just makes one angry, and then there’s a brief swirl of activity of clouds making other clouds angry, until finally everyone calms down again, and then we’re back at the title screen again, where we can start another game.  This wasn’t consciously my goal going into it, but I think there are some interesting messages in here about the nature of many modern social interactions.

And there were lots of different reactions from different people about how easily they were able to cope with the rapidly shifting “which clouds do I control right now, and how do I develop a strategy to cope with that?” challenges.  I call this game a huge success, in terms of being an interesting game.

Trivia:

• This was the first VectorStorm game to use Box2D physics.  The VectorStorm library’s Box2D bindings would later be set up based upon the code that I wrote for this game.
• This was the first VectorStorm game to render with no glow shader.
• This is the only non-testbed VectorStorm game in which the player can “shoot”.

The Incomparable Deductions of Police Constable Sir Nicholas Spratt

This was an intriguing idea.  I still love the concept.  Murder mysteries are good fun, and nobody really makes them any more.

But I made a mistake in doing this as a Game in a Week.  See, I’d already been thinking about making a murder mystery game at the time.  And so when the theme quote “In the first room of Mystery House, seven people are initially seen.” came up, I decided to use it to make the game I’d already been thinking about — the murder mystery game.  Which was too big, too complex a game to actually be designed and implemented in a week.  And I think that really showed in what was released at the end of the week.

The core idea — that I could run a simulation of the events of a murder mystery, rewrite the memories of one participant, and that the result would be a compelling game.. well.. I think that simply doesn’t work.  And this game really demonstrated how murder mysteries which were constructed this way would often not actually be solveable.

The thing I need to remember is that a “Game in a Week” is not about implementing a game within a week (although that’s part of it), but that at its core, it’s about designing a game within that week.  When I use a quote to justify making a game which I had already been designing in my head, I’ve completely missed the point of the exercise.

With that said, I’d still like to make a real game like this someday.  Make it properly, in a way that each mystery is solvable.  I have about 10% of such a game implemented at the moment, but it’s run into the same problems that this GiaW did;  how to construct the murder events in a way which makes the puzzle solvable.

Robot Finds Ice Cream

Oddly enough, this was probably the best design of all the games I’ve done for Game in a Week.  And one of the ugliest implementations.

The design is simple and clean and elegant; you control one character on a strict tile grid;  that one character must remain adjacent to a second character.  If you directly away from the second character, you will move one step in that direction.  If you move directly toward the second character, you and that second character will move until the second character hits an obstruction.  The goal is to get the second character onto a particular tile.  (Within the terms of the theme, this is getting the robot to the ice cream machine)

But yikes, this game was visually ugly.  Even by my standards.  I don’t know what I was thinking, trying to make an isometric view game when I needed a human and a robot, and with my art skills, and using vector graphics which involved typing vertex positions into a text file by hand, with no art tools involved whatsoever.  This really, really ought to have been implemented from an overhead view.  And honestly, it needed textures.  Which didn’t exist in the VectorStorm library at this time.

Of all the Game in a Week games, this is the one which could most easily be turned into a mobile phone game.  Just hire an artist and make a lot more levels, and it could actually be quite a clever little game.  That would be worth doing someday, now that I think about it.  And I dearly love having names and messages attached to levels, as I did in this game.  Named levels are a fantastic thing;  a direct, explicit communication between author and player, without any attempt at all to filter it through an in-world mechanism.  If you are a game developer, name your rooms and/or levels.  Just do it.  You’ll be amazed at the difference it makes to how people relate to you and to your game.

Lord, Save Us From This Horrible Land

This is where things really started to go seriously bad for Game in a Week.

I had recently added support for 3D to the VectorStorm library, and so I thought “what better way to stress-test the 3D rendering than to do a Game in a Week game?”  Which was me completely missing the point — “Game in a Week” isn’t for testing technology;  it’s for practicing game design.

As those who were reading this blog at the time know, it turned out that VectorStorm’s 3D rendering wasn’t actually ready to be used.  I had huge problems just getting a 3D planet rendering properly.

The design I came up with was a five-phase thing;  in essence, five games in one.  The game began with a meteor crashing into the planet and the player working to contain a spreading extraterrestrial plant species.  Each subsequent phase added a new game mechanic, with the flora slipping through the successful defense the player had mounted in the previous phase, and eventually resulting in the flora creating a new seed pod which would fire another ‘meteor’ off to some other planet.

Have you noticed that many of my game designs work in circles?  I like games which end where they begin.

Anyway.  In practice, if I had been thinking, I would have realised that no, I couldn’t implement five different games in a single week.  I couldn’t even implement five terrible games in a single week, much less five good ones.  And especially not when I couldn’t even make my 3D camera point at the planet successfully.

To make matters worse, rather than actually end the Game in a Week after a week and just post what I had, and get on with my life, I felt that I could salvage things;  if I just spent a little more time on it, I could actually make the game that I had wanted to make…

In the end, I released a substantially cut-down version of Lord after seven weeks, rather than seven days.  It wasn’t the game I wanted to have made, it was still very buggy, and it was extremely not fun.  And it completely killed my confidence and my motivation for a very long time.

It was more than two years before I’d try another Game in a Week.

GoGoGo!

Steven Lavelle challenged me to create a game before 2011.  He sent me the challenge about ten hours from the end of 2010.  This wasn’t really a “Game in a Week” by any normal perspective, but I decided to treat it as one, just because I didn’t have anywhere else obvious to put it on the site.  And it was implemented in under a week, so that sort of counted, right?

Well.. the more I’ve thought about it, the more I’ve felt that it sort of shouldn’t have been counted this way.  It was really a very different beast.

In practice, I just decided to make an infinite racer.  One game I’ve always wanted to write is a home computer version of Virtual World Entertainment’s Red Planet;  a location-based racing game.  In practice, that’s not actually what I made here, but it’s where the inspiration about zooming down a corridor at breakneck speeds, with solid rocket boosters which make you fly even faster, but with less control.  (I dearly love that “solid rocket booster” idea from Red Planet.  It’s something that shows up frequently in my games, since it’s such a perfect risk/reward mechanic that can be dropped into almost any sort of speed/distance-based game)

I don’t have a whole lot to say about this game;  it really is very simple.

Trivia:

• The game’s level geometry is all built by the same technology that was creating buildings, trees, and other geometry for MMORPG Tycoon 2 at the time, just turned inside-out.  The tunnel exists for about 2km in front of the player, and about 200 meters behind the player (I assumed the player wouldn’t be able to turn around without crashing, and so they wouldn’t notice the tunnel vanishing behind them)
• I was originally planning for the game to be played from a third-person viewpoint, behind a procedurally generated vehicle.  Silly me, I only had ten hours.  What was I thinking?

C4 Ten-Four

I have conflicted feelings about C4 Ten-Four.  On the one hand, this was my first real, proper Game in a Week game in many years, and it was fantastic to get back to what the process was really supposed to be about.

This particular design, though.. while I really like it, it turns out that it wasn’t as original as I thought it was.  Turns out that there’s a whole genre of games (mostly written in Flash) which involve transporting a fragile load on the back of a flatbed truck, and I never found out them about until shortly before the end of the week.  So.. in terms of design, there isn’t really a lot to talk about here;  it had all been done before.  The only really interesting bit which I added to the already-common design was that I used the rocket booster idea again (here expressed as a turbo charge).

Trivia:

• This is the only Game in a Week game (so far) which uses VectorStorm’s built-in Box2D bindings.
• This is the only Game in a Week game which my mother has mentioned to me in conversation.

Atop

And I’ve done it again — I completely ignored the point of the Game in a Week process and made a pre-designed game, instead of using the week to design a new game.

I don’t have a whole lot to say, here.  The code was mostly an adaptation of MMORPG Tycoon 2.  Almost everything visible in the game was taken and modified from the MMORPG Tycoon 2 codebase, apart from the terrain itself.  The sky and clouds are exactly the same, the water is only slightly modified, all the objects in the games use the MMORPG Tycoon 2 geometry generation code.. and the design came from an existing game design.

And the design was definitely a ‘cover’ of somebody else’s design.  I’m uncomfortable about the wholesale copying of other people’s designs.  I think in the case of The Sentinel it’s kind of reasonable since it’s such a historically important design, and since there’s no official version of the game available these days.  But.. definitely not as a Game in a Week.

And honestly, I have more useful things I could be doing with my time than re-implementing other people’s designs.

Ten(unnamed)

This is the game which I was working on last week.  And it was going badly.  And with stresses coming up in life, I realised that I simply wasn’t going to be able to present anything at the end of the week.  So for the first time ever, I out-and-out cancelled a Game in a Week project.  And given the option between this and what happened with Lord, I think it was completely the right choice.

See, I realised toward the end that not only would I have no time to implement my design, but also that my design wasn’t the sort of design I wanted to be dealing with for a Game in a Week, anyway.  It involved huge expanses of space,  it involved shooting, it involved enemies, and it involved having lots and lots of complicated AI.  It sounded like a traditional, mainstream game design.  Not like something experimental.

I’ll make another attempt at Ten sometime.  Maybe in a few weeks time.  But I need to get it into my head that I’m not trying to make a mainstream design that sort-of-fits into the random theme — I’m trying to use the random theme to force myself not to generate a mainstream design.

Somebody hit me if I forget that again, okay?  :)

The post Retrospective on Game in a Week appeared first on VectorStorm.

The post Calling a mulligan on #10 appeared first on VectorStorm.

Not sure why that is.  My plan for this game had been to basically do it using 2D objects, but in a 3D scene (to allow for easy starfield depth effect and etc).  Might spend an hour trying to sort this out tomorrow, but if it isn’t obvious how to fix it, I’ll just revert to doing 2D for everything, and I’ll figure out what’s going wrong after the Game in a Week.  Have lost so much time on these little issues, so far.  :/

The post More bugs appeared first on VectorStorm.

Completely forgot that the camera transform needs to be supplied to the rendering code, for these custom-rendering entities.  It’s not done for you automatically, the way it is with vsSprites and vsModels.  :)

I started out planning to steal the starfield from the old Asteroids testbed game.  But having looked at it again, it’s only six single-pixel dots.  So maybe that’s not ideal for use here.  I’m putting in a 3D starfield behind the 2D game, just because it looks nice.  :)

The post Yay, wasting time appeared first on VectorStorm.

I promised myself that I was going to make a smaller game — a game which I could have playable early in the week, instead of programming the basic features right up until the last minute, as I did for the last few Game in a Week.  Part of this was the decision that whatever my game was this week, that it would be a 2D game, and rendered entirely using simple vector graphics.  I really didn’t want to be spending all my time working on creating 3D artwork.

My mind kept returning to my Asteroids testbed.  As I mentioned yesterday, I’d been thinking about doing a little game like that and building a small epic space battle game out of it.  But honestly, making a game that’s about shooting things just doesn’t inspire me.  I spent years straining against that sort of game design while I was in the games industry, and doing it now would feel like giving in.

So as I was daydreaming about those sorts of games, I imagined an introductory sequence where the player flew his spaceship into the combat area, was immediately destroyed, and then took over control of a weapon-less space whale, which, in my mind, was like the space whales from Starglider 2, a game I remember well from my childhood.  The player would then “swim” the whale around through the fight, simply trying to survive by keeping out of the way.  Theme:  “I don’t know why I came” — the whale not knowing why it’s here.

Of course, that doesn’t seem like a particularly strong motivation.  And there’s no really obvious reason for the whale to not simply go arbitrarily far away.

And that’s when I thought about Farscape.  And Leviathan.  I can cast the player as the giant living spaceship, but give him a crew who don’t know what the spaceship is intending.

And so for the moment, this is the plan I’m going to follow for this Game in a Week:  The player is a giant space ship, and has an AI crew.  The player can go places and try to get his crew to do things, but the crew may or may not understand what the player wants.  Or be willing to help the player.  The theme, then, is still “I don’t know why I came”, but not regarding the ship;  instead it’s regarding the crew.

As always, this Game in a Week game design is subject to radical change on very short notice.  But thus far, this is the first idea for this theme with which I’ve been completely happy.

The post Here it is appeared first on VectorStorm.

So I shan’t be doing that.

Real update later tonight.  :)

The post It’s not. appeared first on VectorStorm.