It’s been kinda slow making Unicorn Shoppe lately, I’ve been “busy” playing Batman Arkham Asylum (amazing game by the way) and work.
I did however manage to work on buttons a little bit. I added the extra space require for them not to overlap with the background of the game and I added some functionality, so they actually do something.
Originally I wanted the buttons to be pictures. There’d be one for just a regular button and then another picture for the pressed version. So when you’d click the button the game would just swap out the base button and switch it for the pressed button. And when you’d let go it would switch back to the default button.
I like this idea at first because I thought it would yield nicer looking buttons and “animation” but today I realized that I wanted to have disabled buttons. I could have easily requested a third button from my artist, or hell, I could just opened up Photoshop and add in a transparent grey layer over the base button.
But, I decided to just use Java’s drawing capabilities. This one I don’t need any other images and I can change the colours very easily, or even randomize them on startup or something.
Things left to Do:
- Get timers working during game and when game is closed.
- Replace placeholder items
- Get a background for the button layer of the game
- Tutorial/First time launch mode
Well I’m almost finished. I have the game running outside a development environment, it saves and loads on starting and quitting and each item has it’s own timer for updating.
Things left to do:
- Make the buttons actually do something
- Test if input is behaving properly (already a couple of issues)
- Get an icon
- Remove placeholder images
- Expand size of game so the buttons don’t take up room
- Balance game, tweak numbers for intended pacing times
I was hoping to post a little more frequently with smaller updates but I have this project spread out through three computers. So the images I do save tend to lose relevance as soon as a switch computers.
Anyways, I’ve got a template button in place now. You can’t see it in the image but when you click on a button it changes colours; in the final version it’ll hopefully just look like it’s being pressed.
Since I’m making a throttling game (or a game that forces you to pace yourself) it’s pretty crucial that I have some kinda of saving system so I started working on that. It’s almost finished actually, I just need to “hook” everything together.
I want to start off by saying that I’ve never really looked at the actual design pattern before writing
this piece. I’ve used a couple of factories in my days (unknowingly) but I’ve never really bothered looking into how they actually work, what they’re for or when to actually use one. Again, I wrote this before knowing the “official” factory pattern. This is just what I came up with, and I’m sure it’s been done before so please don’t troll me.
The Problem
So I started making a game, I figured I’ll write this game in Java using some basic SWT stuff and then port it to OpenGL using LWJGL. Cool. My game has stuff in it and I like making nice polymorphic hierarchies. Naturally my first solution was to make an abstract class and then to sub class all of my desired items. Something like this:
ReplaceableHorn < Item Brush < Item Food < Item
Well that works pretty well and this is how we’ve done it both our games. I started writing an abstract class called item, got that finished pretty quickly, made some instanced variables and some methods. Bam, done. Then I went on to make my first item, the “replaceable horn.” It was then I realized that the only differences between an abstract Item class and something that was extending Item were different values for the variables. I literally just needed these objects to have different values but behave in the exact same way. I didn’t actually need polymorphism.
The Solution: Make a Factory
As I’ve mentioned earlier, I’ve never actually used the factory pattern before but since first idea that popped into my head was, “Hmm I need some kinda item factory.” I figured I’d give it a shot.
The Factory
I made a class called ItemFactory which would have static function and variables and the information about the all of the item variables.
The Items
Next I made private nested class (within ItemFactory.java) called ItemTemplate (I’ll probably end up changing it to something more meaningful). Making a private class adds some security so that if someone else were to use my code they would never make their own item; they would have to go through the factory.
The Interface
Using a private and nested class meant that I couldn’t really use this outside of ItemFactory.java. No big deal, we just need an interface. This is where Item.java comes in. Item is an interface that has all of the methods I need from ItemTemplate. Now ItemTemplate will implement Item and bam we have a pretty robust design from a software engineering perspective.
Here’s the verbose version of what it looks like:
ItemFactory.java
Public class ItemFactory {
// Static stuff…
// Variables
public static Item createSpecificItem() {
return createItem(ID_SPECIFIC_ITEM);
}
private static Item createItem(int id) {
return new ItemTemplate(id, STAT1[id], STAT2[id], STAT3[id]);
}
// …
private class ItemTemplate {
// Variables
Public ItemTemplate(int id, int stat1, int stat2, int stat3) {
// …
}
Public void method1 { // … }
Public void method2 { // … }
// …
}
}
Item.java
Public interface Item {
Public void method1();
Public void method2();
// ...
}
Cleaning up the Factory
I decided to make arrays for the different items that I wanted. This makes accessing them a lot easier and cleaner. I also avoid an if-tree by simply using an “id.”
Forgot to put this up a while ago. We finally managed to get this game “presentable.” Took a while but we finally did it!
Instructions: download the zip file and run the .exe. That’s it. If you want to get fancy you can put the folder to wherever you usually install games and then make a shortcut.
This game does not install anything, it runs from the folder. So you can delete it whenever without having to actually uninstall anything.
And sorry but windows only. You also need a bunch of run times so if you have at least one DirectX game installed it should be able to run.
As mentioned in some of my previous posts, Mike and I might stop updating due to school work. Well now we’re back! Well at least I am.
Over the passed couple of months Mike, our friend Eric and myself have been working on a more “professional” game. Where we have documentation, diagrams and an actual playable prototype. The game itself was written in C++ using DirectX so unfortunately it will on be for Windows at the moment.
We’re pretty close to releasing a version that we can feel comfortable about distributing, we just need to hammer out one serious glitch and then put that final layer of polish on. It’s still going to be a pretty rough game, but at least we can say we have a finished product.


