Looking for help/suggestions on a game...

Java 2D
#1

(This isn’t entirely GFX related, but I can’t seem to find a forum this would fit into…)

Its an overhead 2D game, tile based. It takes place in individual screens, like the older Zeldas did.
Right now, I have it so it reads levels in from files, allowing me to implement a level editor and maybe in the future allow players to add their own levels. (The game knows how to load them and when based on the file number). This works all fine and well until i get to ingame “events”.

Currently, the level files look like this:

Beta Zone
nnnnnnnnnnnnnnnnnnnnnnnnn
dgggggggggdgggggggggggggd
ggggggggggdgggggggggggggg
ggggggggggdgggggggggggggg
ggggggggggdgggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
ggggggggggggggggggggggggg
dgggggggggggggggggggggggd
NULL LINE. EVENTS NEXT
nnnnnnnnnnnnnnnnnnnnnnnnn
xxxxxxxxxxtxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxx
1

(It doesnt format perfectly here, but I’m sure you’ll get the drift)

I read it in using basic dataInputStream stuff, and it works very nicely. It gets and draws the level, and reads that there is a “teleport” event tile at t in the 2nd grid. (The 2nd grid kind of “overlays” the first grid so to speak, as an event layer. That is how it appears in the editor too). Now the 1 at the end is supposed to show the destination zone for the teleport event. However, when I try to read the 1 in using .readInt(), it gives me an end of file exception, and gets some insane number instead of 1. I’m using notepad, so i dont THINK there are any hidden formatting things screwing up the .readInt()…if anyone knows why this is happening, it would be greatly appreciated.

Also, I’m looking for any tips/advice you have on implementing the events system…thanks for your time :slight_smile:

Feel free to move this post if there is a forum section more suited for it…

#2

you’re using the wrong way of reading in an int.

from the javadoc for readInt();

You are representing int’s using their string representation in your input - not as 4-byte integers encoded as a string (big difference).

Why are you using a DataInputStream exactally? What’s wrong with a InputStreamReader (possibly using a BufferedReader with it as well)?

Will.

#3

Ah thank you :slight_smile: I was not aware of such classes, i guess my book is a bit outdated :slight_smile:

Do you think this is an appropriate way of getting it to work?


String buffer = bufferedRead.readLine();
StringTokenizer st = new StringTokenizer(buffer);
eventData[q][i].destinationZone = Integer.parseInt(st.nextToken());

oh yes, and one minor question…when I am done with the buffered and input stream readers, should i .close() both of them? Or do I just need to close one? Don’t want this file stuck open or something :stuck_out_tongue:

#4

[quote]Do you think this is an appropriate way of getting it to work?
[/quote]
No. StringTokenizer wont wark because you need a set of delimiters to seperate tokens. But your data have none, since they are all stuck together.

You could try something like this (off the top of my head):


String buffer = bufferedRead.readLine(); 
for (int i=0; i<buffer.length(); i++) {
   eventData[q][i].destinationZone = buffer.charAt(i);
}
#5

odd since it worked perfectly, even when i stuck 3 ints together (1 250 250)

it read all 3 separately…I’m pretty sure tokenizer uses space as a default separator.

charAt wont work if theres more than 1 place to the integer btw, and it returns a char, not an int.

#6

Your original post didn’t have any delimiters in it ??? (apart from the obvious character returns ;))

U should be using the javadocs when u need API method details, not a book :S

#7

You’re welcome.

The BufferedReader/BufferedWriter classes are very useful and good design choices IMHO. You can read just about anything - URL’s, File’s Strings, Resources from a Jar file, Different Character sets (eg. Japanese) all nicly abstracted for you (especially in a util class that you make, accepting a BR is great for reusability).

I would use tom’s suggestion as a way of reading your data.

The API docs are like a dictionary - they are pretty useless if you don’t know how to spell the word (i.e. if you don’t know what class you are looking for) but very useful if you do. Always code with the Javadocs open in a browser next along side your programming tools so that you can lookup a class if it is behaving funny - but in terms of learning new and better ways of doing thigs a new book (or tute) would be in order :slight_smile:

Coherent and complete API documentation IMHO is one of the many great advantages that Java has over several other languages. That and the fact the HTML pages are no more complicated than need be (think - the MSDN web site - yuk)

Will.

#8

sorry missed a point.

regarding close() - it is not critical to do it. It’s probably a good idea at least for output (since it will flush the stream and write the data to disk if it is buffered). The JVM will do it for you as part of the GC process I believe. My advice is do it since it’s good practice but don’t fret too much if you forget.

[edit]
Ok well I just proved myself wrong. I wrote a program (for work) which had to parse nine thousand html files extracting some information out of them (using regex). I didn’t use close() and sure enough it hit the wall.

However, it only hit the wall after I had opened and processed the first four thousand files (in about a minute). The problem was that I was creating BufferedReader objects faster than the GC could destroy them so close() wasn’t being called.

However normally you should get away with it.

Incidentally my program was able to read nine thousand files off a networked drive, extract the guts out of them (strip all HTML) using regex and write them into 20 output files in approximatally two minutes. Now that’s fast.
[/edit]

It’s nothing like C/C++ in that respect (shudders and the memory of wasting coutless hours debugging a C program which was behaving strangly only to find out it was because about 1 out of ever 100 files I opened I had missed the fclose statement…)

Also you seem to suggest you have both a BufferedReader and an Input stream reader - there is no need for two objects, just create the buffered reader like so:

BufferedReader br = new BufferedReader(new InputStreamReader… etc

Then if you br.close() - everything will be handled nicely for you.

Will.

#9

[quote]odd since it worked perfectly, even when i stuck 3 ints together (1 250 250)
[/quote]
Sorry, I misunderstood. I thought you were looking for a way to parse the whole level file. Not just the last “1” at the end.