Game Details Have moved

Because I have set up the game at Indie DB, I have decided to use it as the place for writing about Small Galaxy Greedy Station. When I start writing about my next project, I will return to this blog to write about it, but in the mean time, this blog will be used for other things.

So, if you are wanting to track the progress of Greed Station, head over to IndieDB.

We will talk again soon I hope, just not about the game I am making... at least not directly :)

Making Menus Meaningful

During my career as a software developer, I was always wanting to be a UI (User Interface) designer, and while a good portion of my web applications experience has been with developing better UI, the limitations of the tools and the frameworks I was using left me wanting. So it has come as no surprise to myself that the aspect of this project that I have sunk the most time into has been experimenting with different UI design options... mind you, I have argued that all a video game amounts to is just a complex GUI (Graphical User Interface), but that argument would be better served in a blog post of its own.

Today I want to share a little bit about menus... and at the same time, reveal a little bit about how the Cards work in the game.

The games "Action Menus" are context driven. For instance, a planet with all 3 types of resources will allow the user to [Mine] > [Ore], [Gel] or [Crystal], sending a mining ship from the station to the planet to collect that resource. Selecting an Ice Field will limit you to [Crystal], and Space Bubbles will limit you to [Gel].

This is true with the expanding of your abilities as well. While initially you are not able to construct anything in space, once that ability is made available, you will be able to choose between [Mine], [Build], and what ever other actions the selection will alow.

The options begin to open up quickly, but each action will continue to change as you progress...

That's all for now, but feel free to ask me questions, and send me ideas.

Thanks,
- fidgetwidget

The big reveal (Title is not yet final)

Just to get it out of the way... because I hope to have the game (in an unfinished state) up on indie games for play testing early next month. I might as well reveal the working title and main menu screen.

As for what the game is about... the title of the game is fairly indicative of the gameplay. You manage a Space Station in the Small Galaxy 'Universe' (the IP I have been working on that will  connect multiple projects), where you are greedily gather up resources from planets and other things... in order to survive.

There are more details to come... but basically this came about as I was trying to design a game that supported a non-violent world view (NOT an easy task let me tell you). So suffice it to say, there is no 'combat' per say in the game...

More details will come. Be Patient.

Theres a Card Game in my Board game Videogame.

So I have been playing around with the way the player performs actions in the game, and been incorporating a sort of Card Game look to the way they select their actions.

Given the fact that the game is displayed on a Hexagonal Grid Map, using cards just seems to fit. 

So if you want to go and perform a given action on a space in the Grid, you can select the space, bringing up a context card menu for that space (given what you have available at that time), and then you select the card that represents the action you want to perform.

Alternatively, you can bring up your card menu, select the action you want to perform, and then select the space you want to perform it.

The Game is real time, but this board game concept fits well with the style and feel of the game mechanics. Hopefully it will help to express the core ideas behind the game clearly to the player.

Here are some images of the cards (keep in mind that the art isn't necessarily final)

First Rule of Optimization... Broken

There is a saying among the computer programmer types... It's that when optimizing your code, always follow these two simple rules. Rule Number 1 : Don't. And Rule Number 2 : Don't yet.

The thinking behind it is that if you are going to continue to work on the code, optimizing it now isn't really going to give you the most bang for your buck (or as the case may be, improved performance for your time). The trouble is, many of us learning coder types are writing very sloppy code that brings an otherwise smoothly running game to a broken slide show of unplayableness. And a game you can't play, you can't test... and a game you can't test, you can't improve.

So, for about 2 days this week (I only managed to get 4 days of work in this week) I attempted to improve my code to make it playable on the Xbox. And in the process, learned a lot about prioritizing updates of game objects/systems.

If it doesn't have to be updated 60 times a second, then don't update it 60 times a second.

So for a game like the one I am creating, there are a good number of things that I was updating when I didn't need to, and costing valuable CPU time... CPU time that was needed for other things.

Its been a good week, and progress has been made.

Now if I can just figure out what you are supposed to be doing in the game (I am only half joking), then everything would be set.

... I am having trouble deciding what way to present the objectives, and how the player should go about achieving said objectives... NOT A GOOD SIGN.

But I will work it out soon enough. It really is just a matter of picking between a half dozen options, trying it out, and if it doesn't work, trying something else... simple enough right?

Sigh.

Wish me luck.

Snap Shots of the Progress So Far

Here are a few images from my current project... you may notice the differences between these and the previous project shots I posted. This is a different type of game.

Hope you like where it is going... because I had to learn a lot of math in order to get it working :)

Reinventing the Rougelike

Or at least the algorithms that generate their worlds.

The project is trucking along at a steady pace, building content, defining the rules, and all that fun stuff!

Right now however, I am wrestling with the decision I made to build the world with a hexmap instead of a square grid.

As I dig through the forums and wiki pages for the way rougelikes build out there worlds, I am having some trouble applying the procedural generation of a square grid for dungeon adventures with generating a map of space for a time management strategy game.

My real trouble has been handling the ways that certain aspects of my world are to look. Planets take up as many as twenty one hex spaces, and not wanting anything to overlap.

There are sure to be some algorithms and tools already created for what I am trying to make, but I haven't found it.

So, it seems like I am going to spend a few more days searching through heaps and mounds of text before I can create the world generator that I feel this game will need.

Work continues!

fidgetwidget out