Posts Tagged ‘ctyr’

Java CTYR, Now in the browser…

April 14, 2012

I get it now.

I really, really get it now.

After figuring out the stuff in LWJGL to make it work in a browser and show a black rectangle, I finally figured out how get a Slick2D app to do the same thing.

And here it is.

So now, from exactly the same code base, I can generate both the stand alone runnable jar and the web browser app.

The deployment is different, but that’s fine.

I can do it.

Yay for me.

PDG Common: Configuration Class

March 6, 2012

This is one of those things that I wind up making for whatever game I happen to be working on, and when I’m smart, I make it once, put it into another assembly/package/other reusable unit, and make use of it evermore in whatever language/platform/ide I happen to be using.

It is a configuration class.

package com.pdg.common.managers;

import java.io.InputStream;
import java.util.HashMap;
import java.util.Map;
import org.newdawn.slick.SlickException;
import org.newdawn.slick.util.ResourceLoader;
import org.newdawn.slick.util.xml.XMLElement;
import org.newdawn.slick.util.xml.XMLElementList;
import org.newdawn.slick.util.xml.XMLParser;

import com.pdg.common.managers.names.TagNames;

public class Configuration {
	private Map managers = new HashMap();
	public Configuration(String ref) throws ConfigurationLoadException{
		if(!loadFromXml(ref)){
			throw new ConfigurationLoadException();
		}
	}
	@SuppressWarnings("unchecked")
	public  T get(String theName){
		try{
			return (T)managers.get(theName);//pesky unchecked warning... fix it one day
		} catch(ClassCastException e){
			return null;
		}
	}
	private boolean loadFromXml(String ref) {
		XMLParser parser = new XMLParser();
		try {
			InputStream stream = ResourceLoader.getResourceAsStream(ref);
			XMLElement root = parser.parse(ref,stream);
			XMLElementList children = root.getChildren();
			for(int index=0;index<children.size();++index){
				XMLElement child = children.get(index);
				String theType = child.getAttribute(TagNames.TYPE);
				LoadableFromXMLElement manager = (LoadableFromXMLElement)Class.forName(theType).newInstance();
				manager.loadFromXMLElement(child);
				managers.put(child.getName(), manager);
			}
			return true;
		} catch (SlickException e) {
			e.printStackTrace();
		} catch (InstantiationException e) {
			e.printStackTrace();
		} catch (IllegalAccessException e) {
			e.printStackTrace();
		} catch (ClassNotFoundException e) {
			e.printStackTrace();
		}
		return false;
	}
}

And this works for however many managers I have to load.

For CTYR, I have the following managers:

<configuration>
	<image-manager type="com.pdg.common.managers.ImageManager">cfg/images.xml</image-manager>
	<sound-manager type="com.pdg.common.managers.SoundManager">cfg/sounds.xml</sound-manager>
	<widget-manager type="com.pdg.common.managers.WidgetManager">cfg/widgets.xml</widget-manager>
	<constant-manager type="com.pdg.common.managers.ConstantManager">cfg/constants.xml</constant-manager>
</configuration>

The “type” attribute conveniently tells me what class I need to load, and the contents of the tag tells me the file name.

I like to have different files for this, because things like images and sounds become rather large (as do constants), and so it gets quite hairy to have to manage the same file for everything.

When using an instance of Configuration, the line typically looks something like:

getConfiguration()<ConstantManager>get(ManagerNames.CONSTANT).<Integer>get(ConstantNames.DISPLAY_WIDTH);

Which gets rather lengthy, but this sort of flexibility comes at that cost.

I also wind up with a number of XXXXNames classes, for example ManagerNames and ConstantNames. These will have a number of string constants (or, in the case of Java, a bunch of public static final String lines). This is to centralize the use of magic strings.

How to just trust @cokeandcode, and thus not be an idiot

March 3, 2012

I mentioned something like this before:

THE AUTHOR OF SLICK2D ALREADY THOUGHT OF ALMOST EVERYTHING FOR YOU. YOU DON’T HAVE TO WORRY ABOUT STUFF. SO DON’T. WORRY ABOUT STUFF.

After my various struggles with getting CTYR working on linux and mac, I did a brief pre-prototype of JetLag (which means: an application that has an ASCII grid that randomly changes once per frame)

And, just for a lark, went through the following procedure:

  1. export my common library (pdgcommon) into pdgcommon.jar
  2. export my game (jetlag) into jetlag.jar
  3. Fire up jarsplice
  4. add pdgcommon.jar and jetlag.jar
  5. also add slick.jar, lwjgl.jar, and the jogg and jorbis jar
  6. *IMPORTANT* add the natives-(operatingsystem).jar files
  7. DON’T BOTHER ADDING ANY NATIVES, THEY ARE IN THE JAR FILES FROM STEP 6
  8. Set the correct mainclass (in my case, com.pdg.jetlag.Program)
  9. make the fat jar
  10. Put it in my dropbox public folder
  11. download on linux and mac

What I had been doing before was adding the natives I downloaded from lwjgl. *FACEPALM*. I needed NOTHING outside of the slick/lib folder. IT WAS ALL JUST THERE ALL ALONG!

So now, a couple of links:

CTYR that works on windows, mac, and linux.

JetLag pre-prototype that also works on windows, mac, and linux.

And now some screenshots, in the spirit of the internet being the refrigerator upon which we affix all of our proud works with magnets.

Both working on the mac:

And CTYR working on ubuntu

And jetlag working on ubuntu

I have the fps counter working on the JetLag pre-prototype.

On my windows machine (not shown), I am getting 43 FPS.

On the mac machine, I am getting 44 FPS.

On the linux machine, I am getting 10 FPS, which isn’t bad for a Dell Inspiron B120.

In other events leading up to this iteration of JetLag:

I had a version I was doing last year in C#.

For this version, I decided to make a small PNG for each of the characters in each of the colors.

I generated these programmatically.

For the Java version, I decided to import them and make use of them.

4096 16x16px images are about 670K, which isn’t bad, but I don’t actually need them.

Slick2D has a nifty colorizing function that will take the white one and shade it whatever color I want.

It also has a way provided that I can use a single PNG and split it into a tilesest which I haven’t investigated.

For anyone’s perusal, I have the flash version of jetlag stripped down to its bare essentials (I was in a weird minimalist phase, and sucked most of the campy fun right out of jetlag) available.

Stuff I Need To Do

March 2, 2012

Writing this down in one spot, so that I can measure progress against it.

  1. Learn to make a stand-alone JAR for CTYR that works on my mac, and do it.
  2. Learn to make a stand-alone JAR for CTYR that works on my linux box, and do it.
  3. Learn to make an applet for CTYR that works on my windows machine, my mac, and my linux machine, and do it.
  4. Learn how to sign my JARs, and do it
  5. Learn how to make an Android version of CTYR that works on my phone, and do it.
  6. Learn how to get a free version of CTYR in the Android marketplace, and do it.
  7. Make JetLag, complete with ASCII graphics, JetLag theme, and all the lucky charms, for desktop windows/mac/linux and Android.

Old Flash Version, for Comparison

March 2, 2012

I also put up my old flash version of CTYR. The high score stuff no longer works, naturally, but you can see the game itself, which is surprisingly almost identical to the new Java version.

Which of course brings up a good question: why in the world am I rewriting CTYR?  Does the world need another version? Are there new features?

As you will have surmised, CTYR is my sandbox game.

As a result of CTYR’s new version, I now have a nice little Java library of stuff I need in various games.

I even figured out how to put it in a separate project in Eclipse. Yay for me!

Next step, after figuring out how to get CTYR’s java version into an Applet, is another swell game: JetLag!

Difficult, Not Difficult, and @cokeandcode

March 1, 2012

First, here’s a link to a stand-alone Click the Yellow Rhombus JAR file that works on my 32 Bit Windows 7 machine. No guarantees. Your mileage may vary.  I’ll be trying it out on my mac and linux machines shortly.

All the cool kids share their stuff on dropbox, I’m told.

Second, the tale of coming up with this JAR was harrowing.

Granted I am pretty much a Java n00b (although less and less as time goes on), I didn’t know some things.

One, resources (like PNGs and OGGs) need to be in the source tree. Handy tip.

Second, don’t export as a runnable jar and expect to jarsplice it into a big runnable jar that works.

Third, I’m still missing something important regarding making Applets.  I’ll be tackling this next.

And now we know.

 

Next, some stuff that has worked our marvelously.

Most importantly, Slick2D.

Here is why I really like Kevin Glass, author of Slick2D (@cokeandcode on “the twitter”).

Y’know how most of the time in any framework dealing with graphics in a particular language, there are those things that the library provides, and those things that your have to build.

For me, these things are typically state machines and resource managers.

I didn’t have to build the state machine. There’s already the basis for one there.

And a master volume control? Its there.

And xml functions that don’t suck (unlike any other xml functions I’ve seen in Java, which all DO suck), somewhat like the ones in .NET that I am used to working with.

Basically, he thought to make 99% of the stuff I usually need to make when coming to a new platform.

I still had to build my resource managers, but so many other things were just already there that I don’t mind.

In short, I’m able to work on content, and not framework.

Thanks, Kev!

And a video with actual gameplay!

February 28, 2012

The basic rudiments of the game are there.

You can start a game.

You can complete a game.

You can start a new game.

And from here, I can start to flesh it out.

It has no sound. It needs some.

It has no high scores. It needs some.

It has no runnable jar that can be downloaded by someone and played on their machine. It needs one.

It has no applet on a web page anywhere. It needs one.

It has no help screen. While it doesn’t need one, the depths of mankind’s need for instruction is limitless.

Once sounds are in, it needs controls for muting/unmuting and volume.

It needs an icon other than the standard LWJGL icon.

Showing once again that even a small, trivial game like CTYR involves quite a bit of work to be polished.

CTYR Screenshots

February 27, 2012

Yes, at this point they are uninspiring splash screens and title screens, but they represent that some important pieces of the game have been built, chiefly the Image Manager class as well as the Button class (which the Play button uses)

It also represents that I’ve reacquainted myself with InkScape, as all of the graphics are drawn by me in it.  Occasionally I then have need to mess around with the graphics in Paint.net, but the actually drawing part is in InkScape.

CTYR Design Document Overview

February 22, 2012

Anymore, I simply cannot work without some sort of up-front design work, even for something as simplistic as CTYR.

Like most of my games, I need some common components:

  • Configuration – Loads from xml, contains information mainly about the images, sounds, and other constants in the game.
  • Image Manager – Images are referenced by alias, which are mapped into the image configuration xml file, which yield an actual resource name.  They are loaded when needed, not all at game start.
  • Sound Manager – Sounds are referenced by alias, which are mapped into the image configuration xml file, which yield an actual resource name.  They are loaded when needed, not all at game start.
  • Constants – Also loaded from xml in the form of strings and integers.
  • Game State Machine – Taken care of by a Slick2D class.
  • Game States – Derived from a Slick2D class made to work with the state machine.

Next, the state machine:

  • Splash – Shows something like “another fine product of PlayDeez Games” for 5 seconds, keyboard or click will cancel it
  • Main Menu – Has buttons for instructions, rankings, logging in/out, options, mute/unmute
  • Instructions – Shows instructions for the game
  • Rankings – Shows rankings for the player’s session(if not logged in) or for the player account (if logged in)
  • Options – Controls for sound volume and muting
  • Log In – User name and password, logs the player in. It will also support getting logged in from the web page and passed into the applet, and the ability to save the login information in some form.
  • Pre-Game – Does a 1.2.3. count up at the commencement of each game
  • Game – Does the main game handling
  • Post-Game – Shows the final score, and links to new game, rankings.

And the appearance:

The main game field is square

The rhombus has an aspect of 2:1.

The area around the field is sufficient to show stats and buttons (stats on the top, buttons on the bottom), as well as a little border on the left and right.

In order to support communication between web page and application, I need to come up with a way to put the data into a payload.  I typically choose some form of JSON strings with base64 encoding and then an “encryption” method.

This will need to be supported on both the client and the server, so it needs to be written both in java and php.

I will naturally need some database tables.

Yes, this means I need a new user system.

Again.

Sigh.

I’d like to use some form of openid, ideally the google id at least.

That’s a research point.

Once I have some sort of user system in place, there is only one table that I actually need that stores the following information:

  • User id (however that winds up working)
  • Number of games played
  • Total score
  • Highest score

From this, the average score can be calculated (total score/games played).

This is, at least, for the “all time” rankings.

For the “last 30 days”, “last week” and “last day” part of the system, I need:

  • User id
  • When
  • Score